Bagaimana saya bisa dengan bijaksana menyarankan perbaikan kode yang dirancang buruk oleh orang lain selama peninjauan?

Saya sangat percaya pada kode bersih dan pembuatan kode, meskipun saat ini saya berada di pekerjaan di mana ini tidak dianggap sebagai prioritas utama. Saya kadang-kadang menemukan diri saya dalam situasi di mana kode rekan penuh dengan desain berantakan dan sangat sedikit perhatian untuk pemeliharaan di masa depan, meskipun itu fungsional dan mengandung sedikit atau tidak ada bug.

Bagaimana Anda menyarankan perbaikan dalam tinjauan kode ketika Anda yakin ada begitu banyak yang perlu diubah, dan ada tenggat waktu yang akan datang? Perlu diingat bahwa menyarankan perbaikan dilakukan setelah batas waktu dapat berarti mereka akan sama sekali diprioritaskan saat fitur baru dan perbaikan bug masuk.

1. Periksa kembali motivasi Anda. Jika Anda berpikir kode tersebut harus diubah, Anda harus dapat mengartikulasikan beberapa alasan mengapa Anda berpikir kode itu harus diubah. Dan alasan itu seharusnya lebih konkret daripada "Saya akan melakukannya secara berbeda" atau "itu jelek." Jika Anda tidak dapat menunjukkan beberapa manfaat yang berasal dari perubahan yang Anda usulkan, maka tidak ada gunanya menghabiskan waktu (alias uang) untuk mengubahnya.

2. Setiap baris kode dalam proyek adalah baris yang harus dipertahankan. Kode harus sepanjang perlu untuk menyelesaikan pekerjaan dan mudah dipahami, dan tidak lagi. Jika Anda dapat mempersingkat kode tanpa mengorbankan kejelasan, itu bagus. Jika Anda bisa melakukannya sambil meningkatkan kejernihan, itu jauh lebih baik.

3. Kode itu seperti beton: lebih sulit diubah setelah duduk beberapa lama. Sarankan perubahan Anda lebih awal jika Anda bisa, sehingga biaya dan risiko perubahan keduanya diminimalkan.

4. Setiap perubahan membutuhkan biaya. Menulis ulang kode yang berfungsi dan tidak mungkin perlu diubah bisa sia-sia. Fokuskan perhatian Anda pada bagian yang lebih mudah berubah atau yang paling penting bagi proyek.

5. Bentuk mengikuti fungsi, dan terkadang sebaliknya. Jika kode ini berantakan, ada kemungkinan lebih besar bahwa itu juga mengandung bug. Cari bug-bug itu dan kritik fungsi yang cacat daripada daya tarik estetika dari kode. Sarankan peningkatan yang membuat kode berfungsi lebih baik dan membuat pengoperasian kode lebih mudah diverifikasi.

6. Bedakan antara desain dan implementasi. Kelas penting dengan antarmuka jelek dapat menyebar melalui proyek seperti kanker. Ini tidak hanya akan mengurangi kualitas sisa proyek, tetapi juga meningkatkan kesulitan memperbaiki kerusakan. Di sisi lain, kelas dengan antarmuka yang dirancang dengan baik tetapi implementasi yang buruk seharusnya tidak menjadi masalah besar. Anda selalu dapat menerapkan kembali kelas untuk kinerja atau keandalan yang lebih baik. Atau, jika bekerja dengan benar dan cukup cepat, Anda dapat membiarkannya sendiri dan merasa aman karena mengetahui bahwa cruftnya dienkapsulasi dengan baik.

Untuk merangkum semua poin di atas: Pastikan bahwa perubahan yang Anda usulkan menambah nilai.

Ada sweet-spot untuk menambah nilai melalui refactoring. Perubahan perlu mencapai tiga hal:

• tingkatkan kode yang kemungkinan akan berubah
• meningkatkan kejelasan
• biaya paling sedikit usaha

Pertimbangan:

1. Kita tahu bahwa kode bersih lebih murah untuk ditulis dan dipelihara, dan lebih menyenangkan untuk dikerjakan. Tugas Anda adalah menjual ide itu kepada orang-orang di perusahaan Anda. Berpikirlah seperti wiraniaga, tidak seperti penggerutu yang sombong (mis. Tidak seperti saya)
2. Anda tidak bisa menang, Anda hanya bisa kalah lebih sedikit.
3. Fokus untuk menambah nilai nyata - bukan hanya keindahan. Saya suka kode saya terlihat bagus, tetapi kadang-kadang harus menerima hal-hal yang lebih murah.
4. Cara yang baik untuk menemukan sweet spot adalah dengan mengikuti Prinsip Pramuka - ketika Anda mengerjakan suatu bidang kode, selalu biarkan dalam kondisi yang lebih baik daripada yang Anda temukan.
5. Perbaikan kecil lebih baik daripada tidak ada perbaikan.
6. Manfaatkan alat otomatis. Misalnya, alat yang hanya membersihkan sedikit pemformatan dapat membuat dunia berbeda.
7. Jual ide lain yang secara tidak sengaja meningkatkan kejelasan kode. Misalnya, pengujian unit mendorong penguraian metode besar menjadi metode yang lebih kecil.

Jika kode berfungsi tanpa bug serius, dan tenggat waktu utama (seperti pada efek P&L atau PR perusahaan) sudah dekat, sudah terlambat untuk menyarankan perbaikan yang memerlukan perubahan besar. Bahkan perbaikan kode dapat membuat risiko penyebaran proyek. Waktu untuk perbaikan lebih awal dalam proyek, ketika ada lebih banyak waktu untuk berinvestasi dalam kekokohan basis kode di masa depan.

Ulasan kode melayani 3 tujuan:

1. Memeriksa bug

2. Memeriksa untuk melihat di mana kode dapat ditingkatkan

3. Alat pengajaran untuk siapa pun yang menulis kode.

Mengevaluasi kualitas desain / kode tentu saja tentang # 2 dan # 3.

Sejauh # 2:

• Buatlah SANGAT jelas manfaat dari perubahan yang diajukan vs biaya yang harus diperbaiki. Seperti halnya keputusan bisnis, ini harus tentang analisis biaya / manfaat.

  Misalnya, "pendekatan X untuk desain akan secara signifikan mengurangi kemungkinan bug Y dari terjadi ketika melakukan perubahan Z, dan kita tahu potongan kode ini mengalami perubahan tipe Z setiap 2 minggu. Biaya penanganan penghentian produksi dari bug Y + menemukan bug + memperbaiki dan melepaskan biaya perbaikan + peluang dari tidak memberikan set berikutnya dari fitur $A, sedangkan biaya pembersihan kode sekarang dan biaya peluang (misalnya harga pengiriman terlambat atau dengan fitur kurang) $Bsekarang, mengevaluasi - atau lebih tepatnya minta pemimpin / manajer tim Anda - evaluasi $Avs $Bdan putuskan.

  • Ini akan membantu tim pintar memimpin untuk mengelola ini secara efektif. Misalnya mereka akan membuat keputusan rasional menggunakan informasi LENGKAP

  • Ini akan (terutama jika Anda mengatakan ini dengan baik) meningkatkan status ANDA - misalnya Anda adalah seseorang yang cukup cerdas untuk melihat manfaat dari desain yang lebih baik, DAN cukup pintar untuk tidak secara religius menuntutnya tanpa mempertimbangkan pertimbangan bisnis.

  • DAN, jika bug Z terjadi, Anda mendapatkan lebih banyak pengaruh pada set saran berikutnya.

Sejauh # 3:

• SANGAT jelas menggambarkan "harus memperbaiki" bug / masalah dari "Ini adalah praktik terbaik dan benar-benar harus diperbaiki JIKA kita dapat menghemat sumber daya - lihat analisis pro / kontra terlampir" peningkatan desain (atase hal-hal yang dijelaskan untuk # 2 di atas) vs " Ini adalah panduan umum yang saya pikir akan membantu Anda meningkatkan kekokohan kode Anda sehingga Anda dapat lebih mudah mempertahankan kode "perubahan opsional. Harap perhatikan kata-katanya - ini bukan tentang "membuat kode Anda seperti yang saya inginkan" - ini adalah "jika Anda melakukan ini, ANDA mendapatkan manfaat a, b, c". Nada dan pendekatan itu penting.

Pilih pertempuran Anda, jika tenggat waktu datang maka jangan lakukan apa pun. Lain kali orang lain meninjau atau mempertahankan kode dan mereka terus mengalami masalah kemudian mendekati mereka dengan gagasan bahwa sebagai tim Anda harus lebih fokus pada kualitas kode ketika meninjau kode sehingga Anda tidak akan memiliki banyak masalah nanti.

Mereka harus melihat nilainya sebelum melakukan pekerjaan ekstra.

Saya selalu memulai komentar saya dengan "Saya akan", yang menandakan bahwa saya hanyalah salah satu dari banyak pandangan.

Saya juga selalu memasukkan alasan.

" Saya akan mengekstraksi blok ini menjadi metode karena mudah dibaca."

Saya mengomentari semuanya; besar dan kecil. Kadang-kadang saya membuat lebih dari seratus komentar tentang perubahan, dalam hal ini saya juga merekomendasikan pemrograman pasangan, dan menawarkan diri saya sebagai wing-man.

Saya mencoba membuat bahasa umum untuk alasan; keterbacaan, KERING, SRP, dll.

Saya juga membuat presentasi tentang Kode Bersih dan Refactoring menjelaskan mengapa dan menunjukkan bagaimana, yang saya pegang kepada rekan-rekan saya. Saya sudah memegangnya tiga kali sejauh ini, dan konsultasi yang kami gunakan meminta saya untuk memegangnya lagi untuk mereka.

Tetapi beberapa orang tidak akan mendengarkan. Lalu aku pergi dengan peringkat menarik. Saya yang memimpin desain. Kualitas kode adalah tanggung jawab saya. Perubahan ini tidak akan terjadi pada arloji saya dalam kondisi saat ini.

Harap dicatat bahwa saya lebih dari bersedia untuk mundur atas komentar yang saya buat; karena alasan teknis, tenggat waktu, prototipe, dll. Saya masih harus banyak belajar tentang pengkodean, dan akan selalu mendengarkan alasannya.

Oh, dan saya baru-baru ini menawarkan untuk membeli makan siang untuk yang pertama di tim saya yang mengajukan perubahan non-sepele yang saya tidak memiliki apapun komentar. (Hei, kamu juga harus bersenang-senang. :-)

Saya kadang-kadang menemukan diri saya dalam situasi di mana kode rekan penuh dengan desain berantakan dan sangat sedikit perhatian untuk pemeliharaan di masa depan, meskipun itu fungsional dan mengandung sedikit atau tidak ada bug.

Kode ini selesai. Pada titik tertentu, desain ulang menjadi terlalu mahal untuk dibenarkan. Jika kode sudah berfungsi dengan sedikit atau tanpa bug, maka ini tidak mungkin dijual. Sarankan beberapa cara untuk membersihkan ini di masa depan dan lanjutkan. Jika / ketika kode rusak di masa depan, nilai kembali nilai desain ulang. Mungkin tidak pernah rusak, yang akan menjadi luar biasa. Either way, Anda berada pada titik di mana masuk akal untuk bertaruh bahwa itu tidak akan rusak, karena biayanya akan sama sekarang atau nanti: ditarik keluar, desain ulang yang mengerikan.

Yang perlu Anda lakukan di masa depan adalah memiliki iterasi pengembangan yang lebih ketat. Jika Anda dapat meninjau kode ini sebelum semua pekerjaan menghilangkan bug telah diinvestasikan, masuk akal untuk menyarankan desain ulang. Menjelang akhir, tidak pernah masuk akal untuk melakukan refactoring besar kecuali kode tersebut ditulis dengan cara yang secara fundamental tidak dapat dipelihara dan Anda tahu pasti bahwa kode tersebut perlu diubah segera setelah dirilis.

Diberi pilihan antara dua opsi (refactor atau tanpa refactor), pikirkan yang terdengar seperti penjualan yang lebih cerdas:

Hei bos, kami sesuai jadwal dan semuanya berfungsi, tetapi sekarang kami akan membangun kembali banyak hal sehingga kami dapat menambahkan fitur X di masa mendatang.

atau

Hai bos, kami siap untuk melepaskan. Jika kita harus menambahkan fitur X, mungkin perlu beberapa hari bagi kita.

Jika Anda mengatakan salah satu dari itu, bos Anda kemungkinan akan mengatakan:

Siapa yang mengatakan sesuatu tentang fitur X?

Intinya adalah bahwa kadang-kadang sedikit utang teknis masuk akal, jika Anda tidak dapat memperbaiki kesalahan tertentu kembali ketika itu murah (iterasi awal). Memiliki desain kode berkualitas memiliki hasil yang semakin berkurang saat Anda semakin dekat dengan fitur yang selesai dan tenggat waktu.

[Jawaban ini sedikit lebih luas daripada pertanyaan yang diajukan sebelumnya, karena ini adalah pengalihan untuk begitu banyak pertanyaan lain pada ulasan kode.]

Berikut adalah beberapa prinsip yang menurut saya berguna:

Mengkritik secara pribadi, puji di depan umum. Beri tahu seseorang tentang bug dalam kode mereka satu-satu. Jika mereka melakukan sesuatu yang brilian atau melakukan tugas yang tidak diinginkan siapa pun, pujilah mereka di pertemuan kelompok atau dalam email yang diberikan kepada tim.

Bagikan kesalahan Anda sendiri. Saya berbagi kisah tinjauan kode pertama saya yang buruk (diterima) dengan siswa dan kolega junior. Saya juga memberi tahu siswa bahwa saya menangkap bug mereka dengan sangat cepat karena saya berhasil melakukannya sendiri. Dalam ulasan kode, ini mungkin keluar sebagai: "Saya pikir Anda salah variabel indeks di sini. Saya selalu memeriksa itu karena saat saya salah indeks dan menjatuhkan pusat data." [Ya, ini adalah kisah nyata.]

Ingatlah untuk membuat komentar positif. A singkat "bagus!" atau "trik rapi!" dapat membuat hari seorang programmer junior atau tidak aman.

Anggaplah orang lain itu cerdas tetapi terkadang ceroboh. Jangan katakan: "Bagaimana Anda mengharapkan penelepon mendapatkan nilai kembali jika Anda tidak benar-benar mengembalikannya ?!" Katakan: "Sepertinya Anda lupa pernyataan kembali." Ingatlah bahwa Anda menulis kode yang buruk di awal-awal Anda. Seperti seseorang pernah berkata, "Jika Anda tidak malu dengan kode Anda dari tahun lalu, Anda tidak belajar."

Simpan sarkasme / ejekan untuk teman yang tidak ada di tempat kerja Anda. Jika kode ini sangat buruk, bercanda tentang hal itu di tempat lain. (Saya merasa nyaman untuk menikah dengan sesama programmer.) Misalnya, saya tidak akan membagikan kartun berikut (atau yang ini ) dengan kolega saya.

Ketika sesendok gula membantu obat turun, dan apa yang salah dapat diungkapkan secara ringkas - tidak ada 20 hal yang salah - saya akan memimpin dengan bentuk yang menunjukkan bahwa saya tidak memiliki saham, tidak ada ego yang berinvestasi dalam apa yang saya inginkan untuk didengar. Biasanya itu seperti:

Aku ingin tahu apakah akan lebih baik untuk ...

atau

Apakah masuk akal untuk ...

Jika alasannya cukup jelas, saya tidak menyatakannya. Ini memberi orang lain kesempatan untuk mengasumsikan kepemilikan intelektual atas saran tersebut, seperti pada:

"Ya, itu ide yang bagus, karena < alasanmu yang jelas di sini >."

Jika peningkatannya cukup jelas, tetapi tidak terlalu membuat saya terlihat bodoh karena tidak memikirkannya, dan alasan untuk melakukannya mencerminkan nilai yang dibagikan kepada pendengar, maka kadang-kadang saya bahkan tidak menyarankannya, sebagai gantinya:

Saya ingin tahu apakah ada cara untuk ... <pernyataan nilai bersama di sini>

Ini hanya untuk berurusan dengan orang-orang yang sangat sensitif - dengan sebagian besar rekan saya, saya hanya membiarkan mereka memilikinya!

Ulasan kode tidak selalu bertujuan untuk melakukan peningkatan.

Sebuah ulasan di dekat akhir proyek yang tampaknya menjadi masalah di sini hanya agar semua orang tahu di mana harus mulai mencari ketika bug masuk (atau untuk proyek yang dirancang lebih baik apa yang mungkin tersedia untuk digunakan kembali nanti). Apa pun hasil ulasan, tidak ada waktu untuk mengubah apa pun.

Untuk benar-benar melakukan perubahan, Anda perlu mendiskusikan kode dan mendesain lebih awal dalam proyek - kode jauh lebih mudah untuk diubah ketika hanya ada sebagai pembicaraan tentang pendekatan yang mungkin.

Pertanyaan Anda adalah "Bagaimana cara meninjau kode kode yang dirancang dengan buruk?":

Jawabannya IMO sederhana. Bicara tentang DESAIN kode dan bagaimana desainnya cacat atau tidak memenuhi persyaratan. Jika Anda menunjukkan desain yang cacat atau "tidak memenuhi persyaratan" maka pengembang akan dipaksa untuk mengubah kodenya karena tidak melakukan apa yang perlu dilakukan.

Jika kode "cukup fungsional" dan / atau "memenuhi spesifikasi" dan / atau "memenuhi persyaratan":

Jika Anda seorang rekan pengembang ini, Anda tidak memiliki kekuatan langsung yang memungkinkan Anda "memberi tahu dia" untuk melakukan perubahan.

Ada beberapa opsi yang tersisa untuk Anda:

1. Anda harus menggunakan "pengaruh" pribadi Anda sendiri (suatu bentuk "kekuatan" yang tidak langsung) dan / atau kemampuan Anda untuk menjadi "persuasif"
2. terlibatlah dengan grup "proses kode" organisasi Anda dan mulailah menjadikan "pemeliharaan kode" sebagai prioritas yang lebih tinggi.
3. Menggigit peluru dan belajar cara membaca kode jelek lebih cepat / lebih lancar sehingga Anda tidak menutup telepon (sepertinya Anda terus digantung atau melambat ketika Anda menemukan kode jelek) pada kode jelek.
   • Ini juga akan membuat Anda seorang programmer yang lebih kuat.
   • Dan itu akan membiarkan Anda memperbaiki kode jelek ketika Anda bekerja pada kode jelek.
   • Dan ini juga akan memungkinkan Anda bekerja pada lebih banyak proyek karena banyak proyek memiliki kode jelek yang fungsional ... tetapi banyak kode jelek.
4. Menurut contoh. Jadikan kode Anda lebih baik ... tetapi jangan mencoba menjadi perfeksionis.
   • Karena dengan begitu Anda akan menjadi "lelaki lambat yang tidak dapat memenuhi tenggat waktu, selalu mengkritik, dan berpikir ia lebih baik daripada orang lain".

Saya menemukan tidak ada peluru perak. Anda harus menggunakan ketiganya dan Anda harus kreatif dalam penggunaan ketiganya.

Dalam hal desain yang sangat buruk, fokus Anda harus pada memaksimalkan enkapsulasi . Dengan begitu, menjadi lebih mudah untuk mengganti masing-masing kelas / file / subrutin dengan kelas yang dirancang lebih baik.

Fokus untuk memastikan bahwa antarmuka publik dari komponen dirancang dengan baik, dan bahwa cara kerja internal dirahasiakan. Juga, pembungkus Penyimpanan Data sangat penting. (Sejumlah besar data yang disimpan bisa sangat sulit untuk diubah, jadi jika Anda mendapatkan "implementasi berdarah" ke area lain dari sistem, Anda dalam masalah).

Setelah Anda mendapatkan penghalang di antara komponen, fokus pada komponen yang paling mungkin menyebabkan masalah besar.

Ulangi sampai batas waktu atau hingga sistem "sempurna".

Alih-alih langsung mengkritik kode seseorang, lebih baik bersikap kosntruktif dalam komentar kita selama peninjauan kode.

Salah satu cara yang saya ikuti adalah

1. itu akan optimal jika kita melakukannya dengan cara ini.
2. Menulisnya dengan cara ini akan membuatnya berjalan lebih cepat.
3. Kode Anda akan jauh lebih mudah dibaca jika Anda melakukan "ini" "ini" dan "ini"

Komentar seperti itu akan ditanggapi dengan serius meskipun tenggat waktu Anda datang. Dan mungkin akan diimplementasikan dalam siklus pengembangan selanjutnya.

Peninjauan kode harus diintegrasikan dengan budaya dan siklus pengembangan untuk bekerja. Sepertinya penjadwalan ulasan kode besar di akhir pengembangan fitur X tidak akan berhasil. Pertama-tama, membuat perubahan akan lebih sulit dan seseorang cenderung merasa malu - menciptakan perlawanan terhadap aktivitas tersebut.

Anda harus memiliki komitmen awal dan sering, ditambah dengan ulasan di tingkat komit. Dengan alat analisis kode, sebagian besar ulasan akan cepat. Alat analisis / tinjauan kode otomatis seperti FindBugs dan PMD akan membantu Anda keluar dari kesalahan desain kelas besar. Namun mereka tidak akan, membantu Anda memancing masalah tingkat arsitektur sehingga Anda harus memiliki desain yang solid di tempat dan menilai keseluruhan sistem terhadap desain itu.

Tingkatkan kualitas ulasan kode.

Terlepas dari kualitas kode yang sedang ditinjau, ada yang namanya kualitas dari tinjauan kode itu sendiri:

• Apakah perubahan yang diajukan benar-benar merupakan perbaikan dari yang ada?
• Atau hanya masalah pendapat?
• Kecuali sesuatu yang sangat jelas, sudahkah resensi menjelaskan dengan benar, mengapa ?
• Berapa lama waktu yang dibutuhkan? (Saya telah melihat ulasan berlangsung selama berbulan-bulan, dengan pengembang dalam peninjauan bertanggung jawab untuk menyelesaikan semua banyak konflik gabungan).
• Nada?

Adalah jauh lebih mudah untuk menerima ulasan kode berkualitas baik daripada beberapa perawatan ego yang sebagian besar dipertanyakan.

Ada dua masalah penting dalam pertanyaan, bagian yang bijaksana , dan batas waktu yang akan datang . Ini adalah masalah yang berbeda - yang pertama adalah masalah komunikasi dan dinamika tim, yang kedua adalah masalah perencanaan dan prioritas.

Tactfully . Saya berasumsi Anda ingin menghindari ego yang disikat dan pushback negatif terhadap ulasan. Beberapa saran:

• Memiliki pemahaman bersama tentang standar pengkodean dan prinsip-prinsip desain.
• Jangan pernah mengkritik atau meninjau pengembang , hanya kodenya . Hindari kata "Anda" atau "kode Anda", cukup bicarakan kode yang sedang ditinjau, terlepas dari pengembang mana pun.
• Masukkan kebanggaan Anda pada kualitas kode yang telah dilengkapi , sehingga komentar ulasan yang membantu meningkatkan hasil akhir dihargai.
• Sarankan peningkatan daripada permintaan. Selalu berdialog jika Anda tidak setuju. Cobalah untuk memahami sudut pandang lain saat Anda tidak setuju.
• Biarkan ulasan berjalan dua arah. Yaitu memiliki orang yang Anda tinjau meninjau kode Anda selanjutnya. Tidak memiliki ulasan "satu arah".

Bagian kedua adalah penentuan prioritas . Anda memiliki banyak saran untuk perbaikan, tetapi karena tenggat waktu semakin dekat, hanya ada waktu untuk menerapkan beberapa.

Yah, pertama-tama Anda ingin menghindari ini terjadi di tempat pertama! Anda melakukan ini dengan melakukan ulasan yang terus menerus dan bertahap. Jangan biarkan pengembang bekerja selama berminggu-minggu pada fitur dan kemudian meninjau semuanya pada saat terakhir. Kedua, ulasan kode dan waktu untuk menerapkan saran ulasan harus menjadi bagian dari perencanaan dan perkiraan rutin untuk tugas apa pun. Jika tidak ada cukup waktu untuk meninjau dengan benar, ada yang salah dalam perencanaan.

Tetapi mari kita asumsikan ada sesuatu yang salah dalam proses, dan Anda sekarang dihadapkan dengan sejumlah komentar ulasan, dan Anda tidak punya waktu untuk mengimplementasikan semuanya. Anda harus memprioritaskan. Lalu pilih perubahan yang paling sulit dan paling berisiko untuk diubah nanti jika Anda menunda.

Penamaan pengidentifikasi dalam kode sumber sangat penting untuk keterbacaan dan pemeliharaan, tetapi juga cukup mudah dan berisiko rendah untuk berubah di masa depan. Sama dengan pemformatan kode. Jadi jangan fokus pada hal-hal itu. Di sisi lain, kewarasan antarmuka publik harus menjadi prioritas tertinggi, karena mereka sangat sulit untuk berubah di masa depan. Data persisten sulit diubah - jika Anda pertama kali mulai menyimpan data yang tidak konsisten atau tidak lengkap dalam database, sangat sulit untuk memperbaikinya di masa mendatang.

Area yang dicakup oleh unit-test berisiko rendah. Anda selalu dapat memperbaikinya nanti. Area yang tidak, tetapi yang bisa diuji unit berisiko lebih rendah daripada area yang tidak bisa diuji unit.

Katakanlah Anda memiliki sejumlah besar kode tanpa uji unit dan semua jenis masalah kualitas kode termasuk ketergantungan hardcode pada layanan eksternal. Dengan menyuntikkan ketergantungan ini, Anda membuat potongan kode dapat diuji. Ini berarti Anda dapat menambahkan tes di kemudian hari dan memperbaiki masalah lainnya. Dengan dependensi hardcoded Anda bahkan tidak dapat menambahkan tes. Jadi lakukan perbaikan ini terlebih dahulu.

Tapi tolong coba untuk tidak berakhir dengan skenario ini sejak awal!