Segera setelah Anda mulai takut dengan teknologi Anda, alasan baru untuk rasa takut akan segera muncul.

Lingkaran ketakutan mengencang seperti ini:

1. Suntingan kecil menyebabkan konsekuensi yang tidak terduga, menakutkan, atau mahal.
2. Kami mulai takut akan perubahan.
3. Kami mencoba membuat semua pengeditan sekecil dan sekecil mungkin.
4. Basis kode diisi dengan tambalan, pengecualian, dan case khusus.
5. Ketakutan meningkat.

Ketakutan dimulai ketika pengeditan yang tidak berbahaya tiba-tiba menyebabkan masalah. Downtime dalam produksi atau hanya bug yang mengganggu. Kesalahan dapat menarik perhatian manajemen. Tidak ada yang menginspirasi rasa takut seperti pertemuan direktur tentang cacat Anda dalam kode!

Ada kerumitan seperti itu, karena pengembang tidak dapat memprediksi semua konsekuensi dari perubahan tersebut. Mungkin test suite tidak cukup. Atau kasus khusus telah muncul yang hanya diamati dalam produksi. (Misalnya, satu klien yang pengaturan datanya berbeda dari orang lain). Apa pun alasan spesifiknya, hasilnya adalah: "Saya tidak tahu bahwa ini akan terjadi."

Beberapa peristiwa serupa - dan sekarang pengembang dan manajer proyek tidak ingin menyentuh apa pun di luar lingkup sempit mereka. Mereka menyembunyikan kepala mereka di pasir seperti burung unta.

Masalahnya adalah perilaku ini akan memiliki konsekuensi. Tidak dapat dihindari, basis kode akan mulai memburuk, kebutuhan untuk perubahan besar akan meningkat, dan volume refactoring dalam build tanpa rilis akan meningkat.

Lingkaran setan ditutup ketika salah satu burung unta ini menjadi biang keladi bug orang lain. Sejak saat ini, siklus rasa takut menjadi mandiri. Harga bahkan perubahan kecil terus tumbuh tanpa akhir. Waktu yang dibutuhkan untuk merilis perubahan juga meningkat.

Titik kritis

Ini dapat berakhir dengan tiga cara:

1. Refactoring kode utama (biasanya dengan tim yang berbeda) di bawah moto "sekarang kita akan melakukannya dengan benar !" Lihat juga: Sindrom sistem kedua dan "Apa yang tidak pernah bisa dilakukan, bagian I" .
2. Pengalihdayaan skala besar.
3. Menjual aset yang terpengaruh ke perusahaan lain.

Cara menghindari loop

Siklus rasa takut dimulai ketika orang menganggap masalah teknis sebagai masalah pribadi. Untuk pertama kalinya, ketika perubahan kode sederhana menyebabkan konsekuensi besar dan tidak terduga, Anda perlu memanggil "pasukan khusus teknis" - tim spesialis. Mereka akan menentukan mengapa sistem mengizinkan ini dan perubahan teknis apa yang akan membantu menghindari hal ini di masa depan.

Pengadilan adalah respons terburuk terhadap kegagalan.

Perbedaan antara "pasukan khusus teknis" dan pengadilan adalah bagaimana orang-orang tertentu mendekati masalah ini. Untuk menghindari lingkaran ketakutan, diperlukan bimbingan yang bijak. Carilah orang-orang dengan pengalaman di DevOps dan manajemen proyek teknis.

Cara memutus loop

Seperti banyak loop yang diperkuat, siklus ketakutan sangat sulit untuk diputus. Sejauh ini, saya belum melihat satu kasus pun yang berhasil keluar darinya. Jika itu dimulai di perusahaan Anda, saya akan senang mendengar tentang pengalaman Anda!