🖥️ 👨🏽‍🔧 👩🏿‍🤝‍👨🏾 Keterampilan apa yang dapat dipompa pada proyek dengan basis kode yang besar 🕤 🕝 🔂

Bagaimana menjalani dan mengembangkan proyek dengan sejarah. Apa yang memberi pengembang pengalaman bekerja dengan basis kode yang besar, dan mengapa tidak perlu berusaha keras untuk menulis ulang semuanya dari awal, bahkan jika Anda benar-benar menginginkannya.

Kandungan

Saya Pavel Novikov, saya terlibat dalam pengembangan aplikasi seluler "MyOffice Documents" dan "MyOffice Mail". Ini adalah aplikasi untuk kolaborasi dengan dokumen dan klien email, yang mulai dibuat pada tahun 2013, sehingga bisa disebut proyek dengan basis kode besar, di mana ada tempat termasuk warisan.

Pengalaman yang dijelaskan di sini tidak hanya berlaku untuk bekerja pada aplikasi seluler dan skala pengembangan aplikasi secara umum.

Penafian untuk anak kecil

Dalam artikel ini, saya telah mengumpulkan refleksi tentang pekerjaan saya berdasarkan pengalaman yang saya miliki hingga saat ini. Setiap artikel semacam ini selalu sangat subjektif. Saya yakin ada orang dengan pengalaman yang bertentangan dengan pengamatan saya. Saya akan dengan senang hati membahas perbedaan ini di komentar.

Untuk siapa teks ini

Teks ini ditujukan baik bagi mereka yang menganggap diri mereka di tingkat Junior dan untuk mereka yang termasuk dalam kategori Menengah / Senior.

Ada banyak hal yang bisa dipelajari dari bekerja dengan proyek berumur panjang di semua tingkat perkembangan. Untuk memiliki pemahaman yang sama dalam memahami level, baca postingan Vastrika: Login dan K - Team . Saya suka kategorisasi tingkat pengembangnya, dan saya akan mematuhinya di masa mendatang.

Di blok berikutnya, kami akan menganalisis secara singkat apa yang digunakan untuk masing-masing level pada proyek panjang.

Muda

Tugas pengembang Junior adalah memaksimalkan pengembangan keterampilan teknis. Semuanya digunakan: bahasa, kerangka kerja, perpustakaan, pendekatan pengembangan, dll. Pada proyek apa pun dengan tim yang kuat, Anda dapat belajar memecahkan masalah yang berbeda.

Tetapi pada proyek yang matang, pertama, Anda akan memiliki kesempatan untuk menyelam lebih dalam ke area mana pun dan, kedua, Anda akan dapat mempelajari contoh keputusan yang berhasil dan tidak berhasil. Belajar dari kesalahan orang lain itu mahal. Apalagi jika ada rekan kerja yang lebih berpengalaman di dekatnya yang bisa menjelaskan kepada Anda secara detail arti dari kesalahan ini dan bagaimana Anda bisa menghindarinya.

Tengah

Tugas Pengembang Tengah adalah meningkatkan otonominya. Anda harus menjadi anggota tim yang dapat dipercaya dengan hampir semua tugas dalam proyek. Ini berarti semakin beragam tugas yang dimiliki sebuah proyek, semakin banyak area pertumbuhan potensial yang Anda miliki.

Senior

Tugas Pengembang Senior adalah memahami sepenuhnya bahwa Anda tidak dibayar untuk kode tersebut, tetapi untuk memecahkan masalah. Terkadang (sejauh ini masih lebih sering) melalui penulisan kode, terkadang melalui pengelolaan pengembang lain, terkadang melalui komunikasi dengan non-pengembang. Proyek yang matang hanyalah gudang tugas yang dapat dan harus diselesaikan.

Selanjutnya, saya akan membahas lebih detail tentang beberapa hal yang dapat Anda pelajari dari proyek yang ada.

Dan di sini Legacy?

Pertama, Anda perlu memahami terminologi. Konsep "warisan" telah memperoleh konotasi negatif sejak lama, tetapi untuk apa sebenarnya kode warisan itu buruk?

Michael Feathers, pendiri R7K Research & Conveyance, berpendapat bahwa kode warisan adalah kode yang tidak tercakup dalam pengujian. Keuntungan dari pendekatan ini adalah, pada pandangan pertama, ia mengaku objektif. Namun kenyataannya, ada dua skenario:

Ada tes, tetapi ditulis dengan buruk: membingungkan, rapuh, tidak jelas terstruktur.
Tidak ada tolok ukur, tetapi kodenya dirancang dengan sangat baik. Ini memungkinkan untuk mengubahnya secara relatif aman dan, dalam hal ini akan memungkinkan Anda untuk menulis tes dengan cepat di masa depan.

Lain melihat apa warisan adalah dari pengembang Dro Helper (Dror Helper): Tidak ada lagi rekayasa - continuedly ditambal dan hack ...

Pengembang web Nicolas Carlo percaya bahwa kode lama adalah kode yang tidak nyaman untuk digunakan.

Dari semua ini, kita dapat menyimpulkan bahwa warisan lebih merupakan karakteristik subjektif dari kode. Kode itu sendiri mungkin atau mungkin tidak berfungsi, tetapi akan menjadi warisan ketika pengembang muncul yang tidak dapat memodifikasinya secara efektif.

Karakteristik lain yang relatif obyektif untuk mengevaluasi Legacy adalah jawaban atas pertanyaan "apakah ada dependensi yang tidak didukung dalam proyek." Kode hanya dapat dibangun oleh beberapa versi kompilator usang tertentu. Atau penulis sendiri menambal beberapa perpustakaan eksternal, dan sekarang telah menjadi bagian dari proyek utama. Dalam hal ini memang proyek menjadi spesifik, dan diperlukan upaya tambahan untuk mendukungnya.

Secara umum, jika umur proyek lebih dari enam bulan, maka kemungkinan besar akan mengandung legacy.

Apa yang dapat Anda pelajari dari proyek cerita?

Jadi, Anda membuat keputusan dan mendapatkan pekerjaan di sebuah perusahaan di mana kode sudah ditulis sebelumnya dan banyak hal lain terjadi. Saya akan menambahkan bahwa Anda tidak perlu pergi ke tempat baru untuk meningkatkan profil Anda. Legacy kemungkinan besar ada di setiap proyek, Anda hanya perlu tahu cara mengevaluasinya. Dan apa yang saya bicarakan tentunya dapat diterapkan pada hal-hal yang sedang Anda kerjakan sekarang.

Di bidang apa pemompaan akan sama bermanfaatnya bagi Anda dan proyek? Di sini Anda perlu memahami bahwa situasi ketika Anda mengembangkan di mana proyek menyakitkan adalah lingkungan yang ideal untuk pertumbuhan bersama. Karena jika Anda berkembang dalam mengerjakan beberapa hal yang berhaluan kiri, maka ini bisa menjadi nilai tambah bagi Anda secara pribadi, tetapi akan sulit untuk menjelaskan mengapa perusahaan harus membantu Anda dalam hal ini.

Analisis proyeknya

Hal pertama yang dapat Anda pelajari dari sebuah proyek warisan adalah menganalisisnya. Katakanlah Anda datang ke sebuah proyek di mana ada celah dengan dokumentasi, atau tidak ada sama sekali. Dalam hal ini, Anda hanya akan memiliki kode sumber proyek, jadi sangat penting untuk dapat menganalisisnya dan dengan cepat memahami struktur dan esensinya. Ini penting karena semakin cepat Anda belajar menavigasi, semakin cepat Anda akan mulai mendapatkan manfaat dari proyek tersebut.

Hal terpenting yang dapat saya rekomendasikan untuk pemahaman yang lebih dalam tentang analisis proyek adalah membaca buku "Pekerjaan efektif dengan kode warisan" oleh Michael Feathers. Dia tua dan terkenal. Ini menjelaskan sejumlah besar praktik untuk bekerja dengan kode lama.

Tip lainnya adalah mengunjungi situs web Understand Legacy Code .... Ini adalah blog yang didedikasikan untuk satu topik - bekerja dengan warisan. Penting bagi Anda untuk berlangganan buletin di sana. Saya yakin banyak developer Android yang tahu tentang email Android Weekly dan Kotlin Weekly. Buletin ULC juga sangat membantu. Ini tidak mengganggu, dengan artikel cara-cara tentang refactoring dan coding.

Refactor

Proyek lama adalah tempat yang tepat untuk melatih keterampilan refactoring Anda. Anda datang ke proyek yang kemungkinan besar memiliki masalah, dan Anda tidak hanya perlu mengubahnya, tetapi juga meningkatkan, memperluas, dan memotong fitur baru. Seberapa baik dan efisien Anda dapat melakukan refactor (dengan cepat dan dengan sedikit regresi) akan menentukan seberapa berguna dan baik pengembang Anda.

Dalam proyek yang matang dengan budaya teknik yang sehat, pemfaktoran ulang harus menjadi bagian pengembangan yang berkelanjutan.

Anda pasti menyukai produk yang sedang Anda kerjakan. Sempurna jika Anda bisa menggunakannya sendiri. Dalam hal ini, Anda akan memiliki motivasi internal untuk berupaya meningkatkan kualitasnya untuk waktu yang lama.

Mendesain dan membuat arsitektur

Poin ini mengikuti poin sebelumnya - Anda pasti perlu memompa dalam desain dan arsitektur perangkat lunak. Dengan budaya pengembangan yang tepat, Anda tidak perlu membuat keputusan arsitektural besar pada tenggat waktu yang ketat. Anda akan punya waktu untuk mendesain arsitektur dan itu akan menjadi tanggung jawab Anda untuk melakukannya dengan baik. Apa yang selalu saya rekomendasikan di sini? Membaca buku-buku.

Saya menemukan buku sama pentingnya dengan sumber informasi lainnya. Semakin banyak pengalaman yang Anda peroleh dari buku, semakin cepat Anda memahami cara memecahkan masalah umum. Selalu ada solusi tipikal untuk masalah tipikal / tipikal yang dapat ditemukan dalam buku. Bekerja dengan segala jenis warisan juga melibatkan pemecahan masalah yang khas.

(Robert C Martin). « », « »

(Martin Fowler). «. »

UML — .

PlantUML (PUML) — , UML-. git, , .

Ketika Anda bekerja dengan produk yang tidak sepenuhnya Anda pahami, Anda akan perlu mempelajari cara mengevaluasi pekerjaan yang harus diselesaikan. Dan Anda akan selalu memiliki sesuatu yang tidak Anda ketahui, beberapa jebakan.

Kemampuan untuk memecah tugas yang besar dan kompleks menjadi satu set potongan kecil yang saling berhubungan adalah keterampilan yang sangat berharga. Salah satu cara untuk mengembangkannya adalah dengan terus bekerja secara retrospektif pada kesalahan dekomposisi dan estimasi. Dalam proses analisis, Anda dapat membuat daftar periksa dari kesalahan umum. Di masa depan, dia akan dapat membantu Anda mencegah kesalahan ini lagi.

Otomatiskan dan dapat menerapkan CI / CD

Anda perlu memahami apa yang terjadi pada kode Anda dari saat Anda menulisnya hingga mencapai perangkat pengguna. Dan Anda akan memiliki kemampuan untuk mengotomatiskan dan CI / CD untuk menyesuaikan, memelihara, dan meningkatkan. Di perusahaan yang tidak memiliki tim infrastruktur khusus, operasi ini dapat dan harus (saya yakin akan hal ini) diputuskan oleh anggota tim pengembangan inti. Alat modern (cloud CI, Docker) tidak terlalu rumit, tetapi sangat menyederhanakan kehidupan tim. Anda akan dapat banyak melakukannya jika Anda menguasai keterampilan ini.

Untuk berkomunikasi

Semakin banyak tanggung jawab yang Anda miliki, semakin banyak orang yang harus Anda ajak berkomunikasi. Pengembangan perangkat lunak telah lama tidak lagi menjadi tugas individu: hampir semua proyek besar dilakukan oleh tim. Sekali lagi, semakin efektif Anda belajar berinteraksi dengan orang-orang di sekitar Anda, semakin banyak manfaat yang dapat Anda bawa.

Anda harus berkomunikasi dengan orang-orang yang lebih pintar dan lebih berpengalaman dari Anda. Dalam proyek besar, selalu ada "orang-orang tua" yang bisa Anda pelajari banyak dari mereka. Juga, Anda akan bertemu orang-orang yang lebih bodoh dari Anda. Kabar baiknya adalah kemungkinan besar Anda salah tentang kemampuan mental Anda - sangat berguna untuk dapat memperbaiki kesalahan persepsi semacam itu.

Saya percaya bahwa mengembangkan keterampilan komunikasi dapat direduksi menjadi pengembangan rasa empati. Semakin baik Anda belajar memahami motivasi dan tujuan orang-orang di sekitar Anda, semakin cepat Anda bisa berguna bagi mereka. Misalnya, saat menjelaskan kepada bisnis manfaat refactoring dan mengerjakan utang teknis, Anda harus menggunakan istilah bisnis, bukan istilah programmer. Ide yang tampak jelas, tetapi saya telah berulang kali melihat bagaimana beberapa orang pintar berkomunikasi dengan orang pintar lainnya dan tidak dapat memahami satu sama lain.

Pertanyaan apa yang harus diajukan dalam sebuah wawancara

Di sini saya akan mulai dari pertanyaan apa yang akan saya ajukan sebelum mengerjakan proyek yang tidak banyak saya ketahui.

Bagaimana alur kerja bekerja dan mengapa tepatnya

Biasanya sekarang mereka bekerja pada sistem Scrum atau Kanban. Tetapi pada saat yang sama mereka sering menyesuaikannya untuk diri mereka sendiri: "mereka mengambil yang terbaik, membuang yang tidak perlu." Pertanyaannya adalah: apa sebenarnya yang mereka buang dan apa yang mereka tinggalkan? Karena panduan Scrum, yang menjadi dasar proses pengembangan, memiliki beberapa praktik yang cukup menarik dan berguna.

Mereka masuk akal saat diterapkan, pertama, secara sadar, dan kedua, semuanya diterapkan. Karena mereka membentuk sistem yang mengontrol dirinya sendiri dan memungkinkan Anda untuk meningkatkan secara berulang tidak hanya proyek, tetapi juga proses Anda sendiri.

Misalnya, jika tim sedang mengerjakan Scrum, saya akan menanyakan apa yang dibahas dalam retrospektif terakhir. Seberapa aktif tim dalam rapat ini? Apakah masalah yang diangkat sedang ditangani?

Pertanyaan menarik lainnya bagi saya tentang proses internal: bagaimana peninjauan kode dilakukan dalam tim? Apakah ada aturan internal untuk melakukan tinjauan yang dapat membantu mengurangi waktunya? Apakah ada dasar pengetahuan umum di mana hasil holivar dimasukkan agar tidak memuaskan mereka setiap saat?

Bagaimana perencanaan bekerja, siapa yang terlibat dan seberapa aktif tim tersebut

Saya akan menanyakan pertanyaan ini untuk melihat seberapa kuat budaya teknik di dalam tim. Ada pilihan ketika hanya pemimpin tim yang merencanakan, dan tim ada di sisinya.

Pilihan lainnya adalah ketika seluruh tim berpartisipasi dalam perencanaan. Dan ketika sebuah tugas datang, itu dilakukan untuk melukisnya oleh seseorang yang memiliki keahlian yang cukup dalam hal ini. Dan kemudian mereka semua berdiskusi dan membuat keputusan. Ini membuat tim lebih terorganisir dan alur kerja lebih menyenangkan.

Berapa banyak orang dalam tim yang memiliki gambaran keseluruhan

Dua hal ekstrem dimungkinkan di sini. Ekstrem pertama adalah ketika Anda datang ke tim yang telah mengerjakan produk selama 2-4 tahun terakhir. Jika pada saat yang sama tim tidak banyak berubah, tetapi hanya berkembang, maka ini sangat bagus, karena Anda akan selalu memiliki orang-orang yang dapat Anda minta bantuan. Mereka akan dapat menyarankan sesuatu, menjelaskan alasannya, menceritakan kisah proyek tersebut kepada Anda. Sangat penting untuk mengetahui konteksnya dan mengapa semuanya diatur seperti ini dan bukan sebaliknya.

Ekstrem kedua adalah ketika Anda datang ke tim yang tidak memiliki salah satu dari mereka yang berada di awal. Misalnya, proyek dibekukan, tidak dibekukan, dan basis kode yang besar tetap ada. Anda tidak dapat menulis ulang dari awal. Oleh karena itu, pembangunan perlu dipulihkan. Artinya, Anda mendapatkan proyek di mana Anda perlu menggali semuanya lagi.

Berdasarkan informasi ini, Anda akan dapat membuat keputusan yang lebih tepat tentang apakah Anda ingin pergi ke sana atau tidak, dan mungkin melebih-lebihkan beberapa persyaratan Anda untuk proposal yang perlu Anda tanggapi.

Bagaimana jaminan simpanan utang teknis dipertahankan

Ada masalah dalam setiap proyek, dan penting untuk memahami bagaimana tim bekerja dengan mereka. Saya menulis dengan sangat baik tentang bekerja dengan utang teknisalexanderlebedevdalam artikel “Lannisters Selalu Bayar Hutang! (dan teknis juga) " .

Jika tim tahu tentang masalahnya, tetapi tidak tahu bagaimana mengatasinya secara sistematis, maka ini pertanda buruk. Tetapi Anda dapat melihat ini dan sebagai kesempatan untuk menjadi orang yang akan membantu menyelesaikan masalah ini.

Kiat bagi mereka yang baru mulai bekerja dengan proyek lama

Tahan godaan untuk terburu-buru menulis ulang semuanya dari awal

Situasi umum: Anda mulai mengerjakan aplikasi yang ada dan melihat bahwa semuanya dilakukan "salah". Dan dengan "tidak begitu" ini Anda perlu bekerja lebih jauh. Dalam kasus ini, keinginan yang wajar - untuk mengambil dan menulis ulang semuanya lagi. Ini adalah reaksi yang normal.

Saya pikir itu didasarkan pada keengganan untuk menjawab kesalahan orang lain. Lagi pula, jika setelah modifikasi Anda muncul cacat baru, maka Anda harus mencari tahu. Lebih baik kemudian menulis ulang sepenuhnya, dan semuanya akan baik-baik saja.

Jika Anda menyadari bahwa Anda memiliki pemikiran seperti itu, tanyakan pada diri Anda beberapa pertanyaan:

Apakah benar-benar ada cukup masalah dalam kode, atau Anda belum memahaminya?

Apakah Anda yakin Anda benar-benar memahami semua titik integrasi dari kode yang ditulis ulang?

Apakah Anda mengetahui proyek tersebut dengan cukup baik untuk secara akurat memprediksi waktu kerja yang akan datang?

Sementara saya yakin bahwa niat untuk segera menulis ulang semuanya dari awal adalah ide yang buruk. Perbaikan harus berulang dan dapat dikelola.

Suatu ketika saya menyaksikan ketika tim mengatakan bahwa “Itu semua omong kosong, mari kita tulis ulang”, tulis ulang selama enam bulan dan tidak menulis ulang. Alhasil, situasi yang agak menarik berkembang ketika proyek harus dimulai dari awal lagi, untuk merekrut tim baru, karena tim lama terjatuh. Cobalah untuk memadamkan dorongan yang sepenuhnya alami ini untuk mengulang semuanya dari awal.

Memprediksi perubahan proyek

Anda perlu belajar menjadi sedikit oracle. Bekerja dengan sebuah proyek untuk waktu yang lama, Anda akan belajar memahami komponen produknya, belajar memahami bisnis, bagaimana proyek ini menghasilkan, bagaimana kehidupannya. Ini akan memberikan kesempatan untuk menilai perspektif jangka panjang dari keputusan yang Anda buat.

Ini adalah keterampilan yang sangat berguna, karena ini adalah situasi yang buruk ketika pemilik produk mendatangi Anda dan meminta Anda melakukan sesuatu yang sederhana dari sudut pandangnya. Misalnya, tambahkan kriteria baru untuk mengurutkan daftar. Dan dari sisi Anda, ini berarti Anda perlu menulis ulang seluruh komponen ini. Ini tidak akan terjadi jika Anda telah berpikir sebelumnya bahwa berbagai cara mengurutkan daftar itu adalah fungsi logis yang sempurna. Meskipun dia tidak diminta untuk melakukannya sejak awal.

Hanya saja, jangan bertindak ekstrem dan mencoba selalu membuat keputusan paling universal. Ini adalah jalur langsung menuju peregangan waktu dan masalah dengan dukungan lebih lanjut untuk solusi semacam itu. Inti dari keterampilan ini tepatnya adalah menemukan keseimbangan.

Melakukan penelitian

Ketika Anda mengerjakan proyek yang panjang, seberapa besar bisnis mempercayai tim itu penting. Sebelum mengembangkan fitur utama apa pun, kami pasti melakukan penelitian menyeluruh tentang area subjek. Ini mungkin terdengar seperti kapten, tapi saya tahu kasus ketika orang segera bergegas ke pusaran dengan kepala mereka, dan tugas yang tampaknya sederhana berubah menjadi refactoring panjang yang bisa dihindari hanya dengan melakukan penelitian sebelum pengembangan.

Luangkan waktu untuk mendokumentasikan

Dokumentasikan apa yang Anda negosiasikan, proses dokumen, arsitektur dokumen. Di sini saya mencoba untuk mengikuti pendekatan bahwa jika mereka tidak menuliskannya, maka mereka tidak setuju. Karena dalam proyek yang memakan waktu lebih dari setengah tahun, belajar untuk tidak kehilangan informasi menjadi sangat penting.

Ketika Anda membuat keputusan arsitektural, itu tampak jelas bagi Anda. Mengapa menjelaskannya entah bagaimana? Enam bulan atau satu tahun kemudian, masalah muncul dalam solusi arsitektur ini. Dan Anda berpikir: “Mengapa saya menerimanya? Apa konteksnya? " Mempelajari cara menulis keputusan arsitektural ini adalah investasi yang bagus dan akan dimainkan di tangan Anda di masa depan.

Salah satu cara untuk memelihara record tersebut adalah Architecture Decision Records... Ide utamanya adalah untuk setiap solusi arsitektur non-sepele, Anda perlu membuat file dengan beberapa elemen: judul, tanggal, konteks, deskripsi solusi, konsekuensi yang diinginkan. File ini disimpan dengan kode dan tidak berubah setelah dibuat. Nilai utamanya adalah ketika saatnya tiba untuk mengubah solusi arsitektural ini, akan lebih mudah untuk memahami motivasi yang mengarah padanya.

Secara singkat

Sebuah proyek dengan sejarah adalah tempat yang baik bagi pengembang untuk tumbuh jika ia tertarik tidak hanya dalam menulis kode, tetapi juga pada tugas-tugas yang akan membantu berkembang tidak hanya sebagai seorang programmer.

Dalam proyek dengan latar belakang, masalahnya bukan dibuat oleh kode, tetapi oleh orang-orang, yaitu, manajemen seperti itu ketika mereka menuntut dari Anda sesuatu yang sangat cepat dan terus-menerus seperti dalam pengembangan game, misalnya.

. , , , .

GDG.

Keterampilan apa yang dapat dipompa pada proyek dengan basis kode yang besar