Jaga agar perubahan Anda tetap kecil

Sebagai seorang insinyur junior, saya menjadi produktif dalam membuat perubahan besar dan menyeluruh. Saya akan melihat suatu masalah dan kemudian mengatasinya secara langsung.

Ini biasanya berarti saya akan mengirimkan ulasan kode dalam jumlah besar. Saya akan menyentuh semuanya mulai dari UI hingga database — dalam satu perubahan.

Saya bangga dengan kemampuan saya mengingat keseluruhan sistem seperti itu. Saya bangga bekerja "cepat". Saya bangga dengan keberanian saya, keberanian saya, kemampuan saya untuk menghadapi masalah besar.

Suatu hari, seorang insinyur senior menarik saya ke samping dan memberi saya masukan tinjauan kode terbaik yang pernah saya terima sepanjang karier saya. Dia menyuruh saya untuk memecah tinjauan kode raksasa saya menjadi perubahan yang lebih kecil dan bertahap.

Reaksi langsung saya adalah merasa kesal. Saya tidak mengerti mengapa dia ingin saya menghentikan perubahan saya. Saya sangat bangga dengan kemampuan saya untuk berpikir besar! Kenapa dia memberitahuku bahwa pekerjaanku buruk?! Merencanakan langkah-langkah tambahan hanya akan memperlambat saya!

Saya belum memahami banyak manfaat dari perubahan kecil dan bertahap. Saya senang saya mendengarkan insinyur senior ini. Saya senang saya belajar membuat perubahan yang lebih kecil dan bertahap.

Sekarang ini adalah negara adidaya milikku.

Manfaat Membuat Perubahan Bertahap

Ada banyak manfaat melakukan perubahan bertahap.

  • Lebih sedikit konflik penggabungan. Semakin banyak file yang Anda ubah, semakin tinggi kemungkinan orang lain mengubah sebagian file tersebut pada saat yang bersamaan. Hindari konflik penggabungan dengan membuat perubahan kecil dan memeriksanya dengan cepat.
  • Peninjauan kode lebih cepat. Lebih mudah bagi manusia untuk meninjau lima file dibandingkan 50+ file. Lebih mudah untuk meninjau perubahan yang dapat dijelaskan dengan cepat — dibandingkan dengan perubahan yang memerlukan percakapan langsung selama 10 menit sebelum siapa pun mulai melihat kodenya. Insinyur bisa jadi malas — jika mereka melihat tinjauan kode dalam jumlah besar, mereka akan berharap orang lain yang melakukan pekerjaannya. Anda mungkin membutuhkan waktu lebih lama untuk menemukan seseorang yang akan meninjau perubahan besar kode Anda.
  • Koreksi arah sebelumnya. Peninjau kode Anda mungkin tidak setuju dengan arah yang Anda ambil. Mereka mungkin meminta Anda mengulangi semuanya. Ini bukan masalah besar jika Anda hanya menghabiskan beberapa jam untuk mengubahnya. Jauh lebih menyakitkan jika Anda membuang waktu dua hari atau lebih untuk menyempurnakan skenario end-to-end.
  • Pengujian lebih cepat. Jika Anda sudah menyentuh semuanya mulai dari UI hingga database, Anda mungkin perlu menguji ulang seluruh produk. Jika Anda membuat perubahan kecil, Anda mungkin hanya perlu menguji bagian yang Anda modifikasi. Manfaat ini terutama terasa jika Anda perlu menangani banyak umpan balik peninjauan kode, atau jika Anda perlu menggabungkan banyak kode sebelum melakukan check-in. Menguji ulang semuanya bisa memakan waktu lama — terutama jika beberapa pengujian dilakukan secara manual.
  • Lebih sedikit bug. Perubahan kecil berarti Anda tidak perlu memikirkan seluruh dunia secara bersamaan. Anda dapat fokus pada sudut kecil yang Anda tingkatkan, dan pastikan Anda melakukannya dengan baik. (Saya pernah melihat seorang insinyur yang begitu terbebani dengan perubahan besar yang dilakukannya sehingga ia mengadopsi kebiasaan hanya berharap yang terbaik, memeriksa, dan memperbaiki bug setelah perubahan tersebut terjadi. Jangan menjadi orang seperti itu. Sekalipun tidak ada pelanggan yang menyadarinya. , Anda akan mengganggu rekan teknisi Anda. Mereka akan berhenti mempercayai kode Anda.)
  • Pemecahan masalah yang lebih mudah. Jika Anda akhirnya merusak sesuatu, akan lebih mudah untuk menemukan akar masalahnya jika perubahan yang Anda lakukan kecil.
  • Penerapan tambahan. Jika Anda bertanya-tanya bagaimana Anda dapat menerapkan sesuatu tanpa waktu henti, perubahan kecil dan bertahap mungkin adalah jawaban Anda (namun hal tersebut mungkin bukan keseluruhan cerita).
  • Lebih mudah untuk mengembalikan perubahan Anda. Bug sering terjadi. Semakin kecil perubahan Anda, semakin mudah untuk mengembalikannya. Jika Anda memeriksa perubahan besar dan beberapa orang mengubah beberapa file yang sama setelahnya, Anda mungkin akan berada dalam situasi yang menyakitkan di mana Anda harus memilih antara mengembalikan banyakperubahan, atau memeriksa dengan cepat perbaiki (yang mungkin tidak benar-benar berfungsi). Jika lingkungan produksi Anda sedang kacau, stres bagi semua orang akan berkurang jika Anda dapat mengembalikan perubahan buruk yang asli.
  • Pembatalan penerapan yang lebih mudah. Jika satu penerapan memperbarui layanan web dansegera memperkenalkan fitur UI yang bergantung pada pembaruan layanan, Anda tidak dapat mengembalikan perubahan layanan tanpa menghapus fitur UI terlebih dahulu. Bergantung pada cara kerja penerapan Anda, mengembalikan kedua perubahan tanpa waktu henti mungkin bukan hal yang mudah. Akan lebih baik jika melakukan check-in dan menerapkan perubahan layanan web sendiri.
  • Risiko lebih rendah. Ini sebenarnya merupakan konsekuensi dari semua hal di atas.

Membayarnya ke Depan

Masukan tinjauan kode yang saya dapatkan dari teknisi senior hari itu telah terbukti menjadi masukan teknis terbaik yang pernah saya terima sepanjang karier saya sejauh ini.

Bertahun-tahun kemudian, saya bertemu dengan insinyur lain yang terus-menerus membuat perubahan besar dan menyeluruh. Saya berbagi tanggapan yang sama dengannya. Dia tampak kesal padaku, dan aku bisa mengerti alasannya. Saya meninggalkan pekerjaan itu sebelum saya menyaksikan adanya peningkatan dalam pekerjaannya. Saya berharap dia pada akhirnya merasakan manfaat dari perubahan kecil untuk dirinya sendiri.

Dia akan menjadi insinyur yang lebih baik.