Banyak proyek yang saya kerjakan, proyek besar, berubah menjadi warisan, janggut yang terurai, dan sebagai hasilnya, pengembangan menjadi sangat sulit. Ada saat-saat ketika proyek mati begitu saja karena kesulitan membuat perubahan. Hari ini saya akan memberi tahu Anda tentang pengalaman saya bekerja dengan proyek, dan mengapa saya menulis semua ini untuk Anda. Semuanya sangat subjektif, tentunya.
Jadi, saya bekerja, dan saya mencoba, seperti seorang pelaut yang ingin mengeruk air dan mencegah kapal tenggelam, tetapi kualitas proyek terus menurun, dan ada beberapa alasan.
Anda akan dengan mudah mengenali mereka, mereka adalah pasien biasa, saya hanya akan mengingatkan Anda tentang mereka:
- Arsitekturnya timpang, sulit untuk menerapkan solusi baru
- Kesalahan pengkodean
- Tidak ada pengujian otomatis
Alhasil, menurut hasil pengembangan proyek selama 1-2 tahun pertama, diperoleh campuran legacy, shitty code, terowongan kusut dengan lorong-lorong rahasia, dan lukisan batu ala "karya seperti ini, kenapa saya tidak tahu".
Saya tidak terlalu memikirkan ini, ini adalah topik # 1 dalam refactoring, jadi langsung ke kesimpulan yang saya buat.
Produk yang dikembangkan adalah keahlian kolektif
Jika tim memiliki 1 mega-developer, benar-benar bersemangat, bekerja dengan baik, maka dia tidak akan membersihkannya sendirian, karena tim tersebut terus-menerus membuat kesalahan dan akan selalu menyeret proyek ke bawah.
Anda dapat, tentu saja, mencoba memberi tim saat ini tugas refactoring, dan kemudian mereka yang mengelasnya akan mengulang hasil kerja mereka sendiri, dan akan memberikan hal yang sama, yah, mungkin sedikit lebih baik dari yang pertama kali.
Oleh karena itu, Anda tidak boleh mengharapkan peningkatan kualitas yang radikal tanpa peningkatan tim.
Ini adalah lingkaran setan nomor 1 - keahlian tim tidak cukup, tetapi refactoring dimulai, dan, perhatian, poson yang sama yang menulisnya melakukannya.
Sebagai alternatif, Anda dapat memberikan petunjuk yang baik siapa yang akan melakukan tinjauan dan membersihkan kesalahan ini (meskipun dia akan mencoba melakukannya), tetapi pada akhirnya akan membuat pusing bagi mereka yang bekerja dengan buruk, dan kemudian akan mengganti pengembang, atau mereka sendiri akan pergi, dan, lagi-lagi , Anda mendapatkan pengganti untuk pengembang.
Ini akan menjadi semacam seleksi alam pada proyek tersebut.
Orang takut untuk mengubah kode
Selamat datang, ini adalah sesi psikologi untuk programmer.
Pemrogram sangat takut untuk mengubah kode, dan mereka bisa mengerti:
- Tes tidak cukup atau tidak
- Bagaimana kode itu bekerja tidak jelas
- Tanggalnya pada
- Tidak ada sumber daya
- Manajemen tidak akan mengerti (normal, tetapi jika manajemen terbakar, semuanya akan baik-baik saja)
Akibatnya, kode warisan lama yang membingungkan yang menyeret proyek ke bawah dianggap sebagai "lebih baik tidak disentuh", dan akibatnya "jangan sentuh" ini berlangsung selamanya, dan, lebih buruk lagi, memaksa Anda untuk menulis kode dengan cara tertentu, sehingga menimbulkan masalah teknis lain yang lalu mereka juga menghentikan proyek tersebut.
Kami mengambil proyek, kode yang buruk, ketakutan tim, mengalikannya dengan waktu, dan kami mendapatkan hutang teknis yang sangat besar, yang meningkat secara langsung dan tidak memungkinkan tim untuk bergerak dan mengembangkan proyek secara normal dengan cepat.
Proyek mulai berantakan, tenggat waktu terganggu, fitur baru menjadi sangat mahal untuk proyek tersebut, pengembang mulai gugup, beberapa pergi, yang baru lebih sulit ditemukan, Anda mengerti ...
Jadi, saya pikir ini adalah masalah nomor 1, takut kode dan risiko.
Dari pengalaman, telah diketahui bahwa jika Anda meninggalkan hutang teknis, maka ini adalah bom potensial, atau setidaknya penggarukan. Biarkan mereka 100, 1000, dan Anda akan mendapatkan ladang ranjau, di mana tidak hanya pergi (mengembangkan proyek), Anda tidak akan bisa merangkak.
Oleh karena itu, satu-satunya cara untuk menghemat kecepatan rata-rata pengembangan proyek dan tidak menurunkan kualitas adalah, berkat tutupnya, memperhatikan kualitas, melakukan refactoring.
Council fire, semua orang tahu tentang itu, tapi nyatanya list diatas belum pergi kemana-mana, jadi kamu tidak bisa begitu saja mengambil dan refactornya, karena kamu akan mendapatkan project yang berantakan, dan kenapa?
Karena tidak ada tes, cara kerja kodenya tidak jelas, dan alhasil, alih-alih mengganti gambar dan perakitan mobil, ternyata Vasya dan Petya mengambil penggiling, menggergaji Solaris, dan memasangnya kembali ke Tavria, namun tidak kunjung pergi. Mengapa? - oh, tapi karena kami tidak tahu tentang pengaruh / perilaku / tugas
Ya, Anda dapat melakukan refactor tanpa tes, dan kemudian menstabilkan, tetapi banyak skrip pengguna atau skrip eksekusi kode yang diperlukan mungkin hilang, atau stabilisasi mungkin membutuhkan waktu yang sangat lama.
Oleh karena itu, satu lingkaran setan lagi - Anda tidak dapat membiarkan kodenya sendiri, tetapi Anda juga tidak dapat memfaktorkan ulangnya, karena ada risiko besar.
Ternyata kami tidak membutuhkan Legacy, tetapi menyingkirkannya menakutkan dan berbahaya, sehingga tim sering kali meninggalkan Legacy sebagai "opsi yang paling tidak berbahaya" untuk mendapatkan solusi yang lebih berbahaya untuk proyek tersebut nanti.
Tes adalah kuncinya
Ternyata untuk membuka kunci pemfaktoran ulang dan membuatnya aman, Anda harus terlebih dahulu menutup semua casing dengan tes, lalu saat kami memotong Solaris kami dan merakitnya ke Tavria, pengelasan akan berhenti dan berkata "Halo, kami membutuhkan Solaris, Anda mengacau di sini."
Tes memungkinkan Anda menghindari kesalahan saat melakukan refactoring, mis. untuk membuatnya aman, dan kemudian Anda dapat menghentikan proyek sesuai keinginan dan kebutuhan tanpa rasa takut bahwa risiko akan berhasil dan akan ada masalah.
Oleh karena itu, kami mendapatkan rantai:
Tes -> Refactoring -> Selamat tinggal jenggot dan warisan
Kedengarannya sederhana, indah, tetapi dalam praktiknya hanya ada beberapa tes. Atau itu tidak terjadi sama sekali, dan ada beberapa alasan untuk ini, seperti biasa:
- Pengembang menganggap tes sebagai topik terpisah dan tidak berinvestasi dalam penilaian; mereka menulis secara terpisah dari pengembangan. Akan lebih sulit jika manajemen proyek berpikir demikian dan ingin menghentikan tes untuk memenuhi tenggat waktu.
- Ujian adalah waktu, dan proyek perlu diserahkan sekarang, tidak ada waktu untuk menulis ujian untuk kita (secara teori, ini sama dengan poin nomor 1)
- Proyek / komponen itu sederhana, mengapa ada tes, semuanya sangat sederhana dan berfungsi di sana?
- Pertama, kita akan menulis kodenya, lalu kita akan menutupinya dengan tes. Tapi tidak, kami tidak mengerti, proyek tidak berhenti, tidak ada waktu. Jadi tugas ini berada di kotak hitam selamanya.
Sebenarnya ada sejuta alasan, tetapi faktanya hal itu menghalangi refactoring dan, akibatnya, tidak memungkinkan peningkatan kualitas.
Oleh karena itu, pengujian adalah tugas penting, dan tanpanya, pengembangan kualitas jangka panjang proyek akan sangat sulit jika bukan tidak mungkin.
Apa yang harus dilakukan, Houston?
Saya menulis artikel ini hanya karena tidak semua orang memahaminya, dan setidaknya ada seseorang yang akan membacanya dan ingin menulis tes, refactor, yang berarti saya menulis artikel ini karena suatu alasan.
Oleh karena itu, pekerjaan rumah setiap orang - ambil modul yang ditulis dengan buruk, komponen, sesuatu, temukan di sana yang ingin Anda refactor, tulis tes untuk modul atau komponen ini, dan refactor.
Hasilnya, Anda akan memahami bahwa tes adalah:
- Sebuah cara untuk mempelajari kode. Bahkan mungkin jauh lebih efisien daripada hanya membacanya.
- Stabilitas
- Kode lama benar-benar dapat difaktorisasi ulang dan kualitas proyek dapat ditingkatkan
Saya menulis semuanya dalam satu tarikan nafas, sangat subyektif, dan mungkin saya salah, ini hanya pengalaman saya. Mungkin saya baru saja menemukan proyek seperti itu, saya tidak tahu, tetapi informasinya masih berguna, dan jika Anda berpikir setelah membacanya, ini juga bagus.
Saya berharap semua orang mendapatkan kode, tes, dan peningkatan kualitas yang baik - itulah mengapa kita dipekerjakan, mari bekerja dengan baik.
NB Jika mau, tulis pengalaman refactoring Anda di kolom komentar, semua orang akan tertarik.