Kapan bisa TIDAK memperbaiki windows yang rusak?

Mengacu pada jendela yang rusak , adakah saat-saat di mana refactoring sebaiknya dibiarkan untuk kegiatan di masa mendatang?

Sebagai contoh, jika suatu proyek untuk menambahkan beberapa fitur baru ke sistem internal yang ada ditugaskan ke tim yang belum bekerja dengan sistem sampai sekarang, dan diberi garis waktu singkat untuk bekerja dengan - dapatkah itu dibenarkan untuk menunda refactoring utama ke kode yang ada demi membuat tenggat waktu dalam skenario ini?

Refactoring adalah - dan harus - proses yang berkelanjutan. Tidak cukup hanya memenuhi persyaratan dengan implementasi yang berjalan dan diuji yang masih sedikit tidak lengkap.

"Buat itu berfungsi, lalu buat itu bekerja lebih baik" .

Saya tidak ingat di mana saya membaca kutipan itu, tetapi ini adalah kunci untuk menerapkan refactoring dengan baik, dan saya menganggapnya tidak profesional untuk melakukan sebaliknya.

Refactoring berkelanjutan seperti menyeka tumpahan saat Anda memasak, dan membersihkan piring setelah makan. Refactoring yang ditargetkan seperti menemukan dapur kotor, tetapi hanya memiliki waktu untuk mencuci satu atau dua gelas kotor. Apakah Anda lebih suka hidup dengan dapur yang terus menerus kotor, atau apakah Anda lebih memilih untuk menjaga kebersihan saat berjalan?

Anda mendapatkan kode untuk bekerja, kemudian Anda refactor kode Anda untuk memastikan bahwa Anda memiliki implementasi terbaik yang dapat Anda gunakan. Jika Anda melakukan sesuatu yang familier, mungkin Anda menerapkan kode terbaik pertama kali, namun perlu waktu untuk memeriksa ulang pekerjaan Anda untuk memastikan. Jika sepertinya Anda dapat meningkatkan kode Anda, maka Anda mencoba untuk refactor untuk memastikan kode Anda setidaknya ramping dan bersih yang Anda bisa. Ini berarti Anda mengurangi jumlah utang teknis yang Anda tinggalkan, dan Anda membuatnya lebih mudah untuk membaca dan refactor saat kode berikutnya perlu ditangani. Ini adalah nilai inti di balik mantra TDD "Red-Green-Refactor", kecuali bahwa di mana di TDD Anda melakukan refactor terutama untuk menghapus duplikasi, ada baiknya juga meninjau item lain yang bisa dire-refoured, seperti kelas besar, metode panjang,

Jika Anda mendapati diri Anda menghadapi desain ulang besar, maka mungkin Anda bisa menundanya untuk sementara waktu, terutama jika Anda kehabisan waktu dalam jadwal Anda. Namun ini asalkan fungsionalitas kode Anda tidak akan dikompromikan, dan juga asalkan implementasi akan terus memenuhi persyaratan. Situasi semacam ini seharusnya merupakan kejadian yang jarang, dan Anda dapat membantu memastikannya semakin jarang terjadi jika Anda terus-menerus melakukan refactoring saat Anda melanjutkan. Namun yang lebih penting adalah bahwa Anda tidak dapat mengambil risiko meninggalkan perubahan besar terlalu lama, jika tidak, Anda akhirnya akan menciptakan beban kerja yang lebih besar nantinya yang bisa jauh lebih mahal untuk diperbaiki, atau dapat berakhir dengan menghasilkan lebih mahal lagi kegagalan proyek.

Saya mendapat kesan bahwa banyak orang cenderung membingungkan definisi untuk Refactoring dan rekayasa ulang . Kedua istilah tersebut menggambarkan strategi untuk mengelola situasi yang sangat berbeda. Jika Anda ingin merekayasa ulang, Anda membuat komitmen untuk membuat perubahan drastis yang akan mengubah perilaku sistem. Ini akan membatalkan beberapa tes, dan juga akan memerlukan tes baru. Ketika Anda Refactor, Anda memastikan sistem Anda terus berperilaku tepatsama seperti yang terjadi sebelum perubahan, namun Anda juga memastikan bahwa kode Anda akan memiliki umur panjang, dan bahwa hal itu akan lebih mudah untuk mempertahankan dari waktu ke waktu. Anda tidak "mucikari" kode untuk neraka itu, Anda berkomitmen untuk standar profesional kode yang bersih yang akan mengurangi risiko kegagalan, dan akan memastikan kode Anda tetap menyenangkan untuk bekerja dengan, dan standar profesional .

Akan kembali ke jendela analogi rusak, jika Anda memutuskan jendela Anda harus memperbaikinya segera. Jika Anda belum menyadari bahwa jendela rusak, maka Anda perlu memutuskan biaya untuk Anda jika Anda meninggalkan jendela rusak. Sekarang, ulangi dua kalimat sebelumnya, tapi pengganti Bug untuk jendela. Anda akhirnya membutuhkan strategi yang berbeda. Jika Anda telah membuat sebuah bug sebagai kode Anda, Anda memperbaikinya segera, atau Anda melihat apakah perubahan akan membutuhkan upaya re-engineering, dan Anda membuat keputusan komersial kapan itu akan menjadi yang terbaik untuk memilah masalah. Jadi Anda tidak refactor untuk memperbaiki masalah, Anda refactor untuk memastikan lebih mudah untuk menemukan dan masalah memperbaiki. Saya tidak peduli betapa menakjubkan Anda berpikir kode Anda, sistem yang kompleks akan selalu memiliki masalah yang perlu ditangani dengan waktu lebih. Inilah yang dimaksud dengan utang teknis, dan mengapa refactoring perlu menjadi proses yang berkelanjutan saat Anda menerapkan kode Anda , dan tidak pergi untuk waktu mendatang yang sewenang-wenang.

Jadi singkatnya, jawaban bahwa kadang-kadang jarang dapat diterima untuk menunda perubahan besar untuk membuat tenggat waktu, namun itu tidak boleh dianggap praktik biasa untuk memperlakukan refactoring sebagai latihan yang independen dari pekerjaan implementasi harian Anda, dan tentu saja tidak pernah digunakan sebagai alasan oleh tim terbiasa dengan kode dasar sebagai pilihan untuk menghindari memastikan bahwa pelaksanaannya adalah sebagai ramping dan bersih karena mereka mungkin dapat membuatnya dalam situasi.

Beberapa pengembang mengatakan mereka sedang "Memperbaiki jendela pecah" ketika benar-benar mereka "menata ulang kursi geladak di Titanic". Kode refactoring yang berfungsi tetapi menyinggung indra penciuman Anda relatif mudah. Jika Anda menemukan bahwa Anda terus kembali ke tugas semacam itu alih-alih menambahkan kemampuan baru untuk pengguna Anda, atau membuat aplikasi lebih bermanfaat bagi mereka (makna pengoptimalan membuat aplikasi berjalan lebih cepat adalah baik di sini, makna pengoptimalan membuat kode lebih mudah dibaca adalah berbeda) maka mungkin Anda merapikan terlalu banyak. Bukan karena merapikan itu buruk, tetapi karena perusahaan membayar pengembangan untuk mendapatkan sesuatu yang dikembangkan. Mereka tidak menginginkan solusi yang rapuh, sulit dibaca, dan tidak dirancang dengan baik, tetapi mereka juga tidak menginginkan solusi setengah dipoles dan indah.

Rapikan ketika Anda perlu melakukan sesuatu yang sederhana "untuk memulai", atau ketika Anda sedang menunggu tim lain untuk memberi tahu Anda apakah masalah Anda sebenarnya adalah kesalahan mereka, atau ketika Anda sedang menunggu keputusan. Akan ada banyak peluang. Jika Anda memiliki kesempatan untuk memajukan seluruh aplikasi, ambillah, kecuali Anda mulai merasa semuanya menjadi rapuh. Mungkin belum. Anda akan mendapatkan kesempatan untuk refactor - Anda tidak perlu khawatir tentang itu.

Untuk kembali ke bagian kedua dari pertanyaan Anda, sprint untuk menambahkan fitur yang menghadapi garis waktu pendek, akan salah untuk mengatakan "dan kami tidak akan melakukan refactoring, tidak ada waktu." Itu juga akan salah untuk mengatakan "Saya tahu ini sudah 6 minggu dan kelihatannya persis sama untuk pengguna, tetapi jendela yang rusak ini benar-benar perlu diperbaiki." Pasang refactoring ke dalam celah yang terjadi di proyek apa pun. Jangan berlindung dalam membereskan dengan mengorbankan memenuhi tujuan proyek.

Dari perspektif bisnis, refactoring adalah investasi spekulatif - menginvestasikan waktu dan upaya (uang) sekarang, dengan harapan hal itu akan menghemat lebih banyak waktu dan upaya (uang) di masa depan.

Tanpa masuk ke dalam perdebatan tentang berapa banyak upaya untuk refactor akan menghemat di masa depan (Ini tergantung pada terlalu banyak variabel untuk itu menjadi diskusi yang berarti di sini), jelas waktu untuk refactor adalah ketika "net present value" dari biaya meninggalkannya melebihi biaya lakukan sekarang.

Itu mudah, kecuali Anda tidak tahu berapa biaya perawatannya. Anda juga perlu faktor dalam semua ide perencanaan keuangan normal seperti Pengembalian investasi, manajemen risiko (nilai merek, liabilty hukum, insurable vs risiko non insurable), biaya oppertuniy dll

Dalam kebanyakan kasus, memutuskan kapan untuk refactor sebaiknya diserahkan kepada orang-orang yang menjalankan bisnis. Terlepas dari apa yang banyak poster di forum ini vokal, manajer biasanya tahu lebih jauh tentang menjalankan bisnis daripada programmer. Mereka memiliki gambaran yang lebih besar dalam pikiran yang mencakup memaksimalkan pengembalian kepada pemegang saham. Jarang memperbaiki hal-hal yang tidak rusak berkontribusi terhadap hal ini, tidak terkecuali kode.

Sunting: Saya telah membaca artikel yang menarik tentang jadwal perawatan pada infrastruktur kritis. Intinya adalah bahwa gerakan ini jauh dari pemeliharaan rutin (refactor) untuk memperbaiki bila diperlukan (memperbaiki bug). Perbedaan utama adalah tingkat pemantauan - misalnya pembangkit listrik tenaga nuklir memantau dengan sangat rinci, dan memperbaiki ketika "rusak" tetapi jauh sebelum kegagalan. Apa yang ditemukan adalah bahwa memperbaiki scheule maintaince tidak hanya membutuhkan biaya lebih tinggi, tetapi juga kurang dapat diandalkan karena pemadaman yang disebabkan oleh program maintaince. Gagasan serupa diperlukan untuk perangkat lunak - refactor bit yang akan pecah - yang hanya dapat Anda ketahui dengan pengukuran.

Dapat diterima ketika kerusakan pada bisnis dengan memperbaikinya lebih besar daripada dengan tidak memperbaikinya.

Situasi di mana ini terjadi mungkin:

• di mana tenggat waktu atau peluang bisnis mungkin terlewatkan karena waktu yang diperlukan untuk memperbaikinya
• di mana sepotong kode (benar-benar) dijadwalkan akan pensiun dalam skala waktu yang sangat singkat sehingga hampir tidak ada manfaatnya untuk melakukan refactoring.

Dan situasi ini memang terjadi - situasi komersial sering kali membuat tenggat waktu buatan yang harus dipenuhi di mana kesempatan untuk menegosiasikannya telah berlalu, dan persyaratan yang memiliki komponen waktu - misalnya perubahan dalam undang-undang atau peraturan pajak yang mulai berlaku tanggal tertentu - memang ada.

Kuncinya adalah dalam mengidentifikasi situasi ini dan menilai mereka dengan benar. Kode yang dijadwalkan untuk pensiun akan sering bertahan selama bertahun-tahun. Tenggat waktu buatan mungkin perlu dipenuhi tetapi seringkali dapat dipenuhi dengan cara yang berbeda (misalnya perangkat lunak dapat disajikan, didemokan dan "diluncurkan" pada tanggal yang ditentukan tanpa versi rilis final harus diselesaikan sampai nanti).

Ketika dihadapkan dengan hal-hal semacam ini Anda perlu mendekatinya dengan pikiran terbuka tetapi selalu bertanya apakah itu yang muncul? Apakah asumsi yang terlibat realistis? Apakah ada cara lain untuk mencapai tujuan tanpa mengirim kode di bawah standar? Jika tidak ada cara terbaik saya menggunakan waktu yang saya miliki?

Dan jika tidak ada alternatif selalu baik-baik saja, tetapi kapan kita akan memperbaikinya?

Karena itu harus hampir, hampir, hampir selalu kapan , bukan jika .

Jika manajer memutuskan bahwa mereka ingin membangun utang teknis . Ini adalah keputusan yang adil untuk dibuat jika seseorang, misalnya, hanya ingin prototipe awal untuk beberapa pelanggan awal untuk mendapatkan umpan balik awal.

Anda dapat memikirkannya dengan cara yang sama seperti meminta kredit. Apakah boleh meminjam uang untuk berinvestasi dalam X dalam jangka pendek, dan membayarnya untuk jangka panjang? Tidak ada jawaban pasti, itu bisa menjadi kepentingan terbaik organisasi (misalnya untuk memenuhi harapan klien saat ini), atau bisa menjadi bencana jika dilakukan secara tidak bertanggung jawab.

Semuanya tergantung pada prioritas, dan manajemen harus menyadari bahwa meskipun prioritas nomor satu adalah membuat "kode berfungsi", mengimplementasikan fitur-fitur baru, dan memenuhi harapan pelanggan, setiap kali Anda meninggalkan jendela yang rusak, Anda membuat prioritas nomor satu menjadi lebih lambat. , lebih sulit, dan membutuhkan lebih banyak investasi sumber daya. Juga, 99% dari waktu itu tidak layak untuk berhenti mengembangkan fitur baru dan memusatkan setiap upaya dalam "memperbaiki basis kode".

Kesimpulannya, ya kadang-kadang meninggalkan jendela yang rusak, seperti halnya meminta pinjaman ... ingat saja bahwa Anda benar-benar harus membayarnya di masa depan. Dan di masa depan, waktu untuk melakukannya kemungkinan besar tidak akan jauh lebih besar daripada waktu yang Anda miliki sekarang.

Biasanya, ketika Anda mampu, Anda harus memperbaikinya, Ini akan mencegah potensi waktu yang dihabiskan untuk pemeliharaan. Namun, beberapa praktik biadab non-gesit cenderung membiarkan status quo selama itu berfungsi. Beberapa manajer takut akan "dampak tak terduga" dari perubahan itu.

Yang saya ambil adalah meninggalkannya hanya jika berfungsi sebagaimana mestinya (hanya rusak oleh optimasi tetapi bukan fungsionalitas) dan Anda tidak punya waktu untuk mengujinya, jika Anda melakukan beberapa refactoring. Namun, Anda harus mencatat bahwa itu harus diperbaiki sesegera mungkin.

Jika itu rusak oleh fungsionalitas dan Anda fitur baru bergantung padanya, itu akan lebih baik untuk memperbaikinya secepatnya.

Sebagian besar programmer dalam bisnis menghasilkan uang untuk majikan mereka. Jadi kapan seharusnya refactoring terjadi: Ketika itu menghasilkan uang perusahaan Anda. Refactoring adalah waktu yang dihabiskan tidak dihabiskan untuk proyek lain dan menghemat waktu di masa depan pada proyek ini.

Apakah itu layak sebagian besar terserah manajer Anda.

Programer harus memberi tahu sisi bisnis seberapa besar hutang teknis, sehingga mereka dapat membuat keputusan. Jika kebutuhan untuk mendapatkan pasar lebih cepat daripada risiko kode Anda, Anda tidak punya banyak pilihan. Kurangnya arus kas akan menghasilkan banyak keputusan teknis.

Untuk menempatkan beberapa masalah ke dalam perspektif nonteknis, tunjukkan waktu yang diperpanjang untuk memperbaiki bug dan menambahkan fitur baru. Jika manajemen memiliki latar belakang penjualan dan pemasaran, mereka mungkin memahami hal ini. Mereka benci harus memberi tahu pelanggan hal-hal ini akan lebih lama.

Jika Anda berpikir untuk memperluas tim Anda, ini mungkin saat yang tepat untuk menyewa pengembang junior. Cakupan tes akan menjadi penyelamat besar dalam kasus ini. Mereka akan belajar lebih banyak dengan melakukan daripada membaca dokumentasi.

dapatkah dibenarkan untuk menunda refactoring utama terhadap kode yang ada demi membuat tenggat waktu dalam skenario ini?

• Jika ada yang rusak, maka kemungkinan besar tidak. Anda tidak akan mengendarai mobil dengan rem yang berfungsi sebagian, bukan? (Kecuali risiko tidak sampai ke suatu tempat tepat waktu lebih besar daripada risiko menabrak karena rem yang salah.) Jauh dari solusi ideal, tetapi sayangnya itu terjadi.

Namun, jika Anda berbicara tentang re-factoring kode kerja, maka saya akan mempertimbangkan yang berikut:

• Jika terserah pengembang senior atau direktur teknis kami maka kami tidak akan pernah merilis perangkat lunak apa pun. Kami selalu mempertimbangkan ulang faktor dan berusaha untuk perfeksionisme.

• Jika re-factoring akan berdampak negatif pada profitabilitas bisnis, maka harus dijadwalkan ulang.

• Jika bisnis Anda telah berjanji untuk memberikan fungsionalitas tertentu pada tanggal yang ditentukan, maka Anda akan refactor nanti. Pikirkan amal Red Nose Day - setiap tahun mereka dapat mengumpulkan sumbangan untuk jangka waktu 24 atau 48 jam. Tidak mungkin mereka akan memfaktorkan ulang basis kode mereka jika mereka pikir itu bisa menghentikan mereka dari mengambil sumbangan dalam jeda waktu itu. Selain itu, jika ada jendela yang rusak, tetapi itu tidak akan mempengaruhi kemampuan mereka untuk mengambil sumbangan, maka sangat mungkin bahwa mereka akan memilih untuk tidak mempertimbangkan ulang faktor.

• Anda akan selalu menemukan cara yang lebih baik untuk melakukan sesuatu. Ini adalah proses alami dan sangat penting untuk dapat menarik garis.

Sebagai jawaban atas pertanyaan Anda tentang refactoring, saya akan mengatakan, "ya". Seperti orang lain tunjukkan dalam jawaban di atas, refactoring adalah proses yang berkelanjutan, dan beberapa kali ada keputusan taktis dan bisnis yang menggantikan kebutuhan untuk menulis ulang kode yang sudah berfungsi (walaupun mungkin dengan cara klugey).

Mengenai "broken windows": Saya pertama kali mendengar istilah ini dalam konteks pengembangan perangkat lunak, sekitar 10 tahun yang lalu. Tetapi pada saat itu, itu digunakan untuk menggambarkan memungkinkan tes unit yang rusak . Ini menggambarkan skenario di mana orang memiliki godaan untuk tidak memperbaiki tes unit yang rusak, karena tampaknya lebih bijaksana hanya untuk mengingat tes mana yang "oke untuk gagal", daripada memperbaiki tes yang rusak (yang rusak karena antarmuka atau persyaratan yang valid perubahan, misalnya).

Saya pikir menerapkan metafora jendela yang rusak untuk tes unit yang rusak lebih pas, dan lebih deskriptif tentang bahaya membiarkan "jendela pecah" di lingkungan perangkat lunak. Menurut pendapat saya, jika Anda berbicara tentang tes unit yang rusak (seperti jendela pecah), maka jawabannya adalah tidak pernah apa - apa. (Sejauh kita bisa mengatakan tidak pernah ...)

Jika benar-benar rusak maka itu harus diperbaiki.

Tetapi apakah itu benar-benar rusak? Apakah Anda yakin Anda tidak hanya menyamakan "tidak cantik" dengan rusak.

Anda perlu menerapkan perhitungan "sunk value" sebelum memasukkan kembali kode kerja karena Anda tidak menyukai gaya, atau, karena Anda pikir itu akan menyebabkan masalah di masa mendatang.

Untuk kode anjak ulang yang Anda tulis minggu lalu, Anda hangus biaya adalah waktu yang Anda habiskan untuk mengkodekannya minggu lalu, tidak benar-benar layak untuk diganggu jika kode tersebut secara substansial ditingkatkan.

Kode anjak piutang yang telah melalui unit test. Sekarang Anda tidak hanya perlu menulis ulang, Anda perlu mendefinisikan ulang dan menjalankan kembali semua pengujian yang dilakukan sejauh ini, ini mulai terlihat mahal.

Kode ulang anjak piutang yang telah diproduksi. Bahkan lebih banyak pengujian yang harus dilakukan, ditambah peluncuran kepada pengguna, dan, risiko memberikan sesuatu yang tidak berfungsi sebaik rilis lama. Anda perlu membenarkan ini dan membersihkannya dengan bos besar sebelum melanjutkan.

Kode Anjak Ulang yang telah diproduksi untuk sementara waktu dan telah melalui beberapa rilis dan perbaikan bug. Kecuali Anda tahu perangkat lunak akan berhenti bekerja bahkan tidak pergi ke sana!

Sudah pengalaman saya bahwa tenggat waktu adalah hal terpenting untuk bisnis. Itu benar-benar tergantung pada siapa yang akan menggunakan aplikasi Anda. Dalam kasus saya itu untuk perangkat lunak OS ponsel ... tenggat waktu yang terlewat berarti target penjualan yang terlewat dan harga saham yang kena.

Kami menemukan banyak momen WTF ketika melihat kode yang kami warisi dan jelas perlu diubah. Namun karena kode ini bekerja 'hampir' (asinkronisitas kurang dipahami), tidak ada insentif bagi manajemen untuk benar-benar mengizinkan refactoring sementara ada komitmen luar biasa yang harus diberikan. Tidak sampai bug terlihat 'di alam liar' kami diizinkan mengubah apa pun, meskipun kami bisa memecahkannya sendiri dengan mudah melalui kasing tepi yang tidak jelas. Saya pernah refactored sekitar 10r baris kode di waktu saya sendiri dan akhirnya harus membuangnya. Waktu yang dibutuhkan untuk pengujian dan yang lainnya meninjau dll tidak dapat dibenarkan.