"Buku manual tidak mengizinkan saya mengubah kode warisan saya!" Situasi umum? Sangat menjengkelkan. Kebanyakan pengembang cepat atau lambat menghadapi manajer yang sama sekali tidak tertarik untuk meningkatkan apa yang sudah siap. Mereka juga perlu menerapkan sesuatu yang baru, atau segera memadamkan api, atau memperbaiki beberapa bug ... Secara umum, mereka akan selalu menemukan alasan untuk menunda pemfaktoran ulang basis kode yang sedang berjalan.
Dan bahkan ketika Anda mencoba menjelaskan kepada mereka manfaat memiliki kode yang rapi, mereka tidak mengerti atau tidak ingin mengerti. Mereka hanya memikirkan biaya dan waktu, dan tidak ada yang peduli dengan kualitas. Dan ternyata Anda sama sekali tidak berdaya untuk melakukan sesuatu tentang hutang teknis, yang masih menumpuk dan menumpuk. Programmer bekerja untuk prod, dan prod - untuk permintaan pengguna yang tidak sabar. Tidak ada yang akan membayar untuk refactoring. Situasinya terlihat tidak ada harapan.
Ketika dihadapkan pada situasi seperti itu, banyak pengembang yang cerdas hanya mengemas barang-barang mereka dan meninggalkan perusahaan. Dan segera, karena pergantian departemen, pintunya tidak lagi ditutup: beberapa pergi, yang lain datang ...
Manajer bukanlah programmer
Solusi untuk masalah ini adalah mengomunikasikan kepada manajer tentang dampak kualitas kode yang buruk pada bisnis. Pada akhirnya, aktivitas perusahaan ditujukan untuk menghasilkan uang. Tiba. Oleh karena itu, manajemen mencari cara terbaik untuk memangkas biaya dan meningkatkan pendapatan. Ini berarti bahwa untuk merehabilitasi refactoring di mata mereka, mereka harus berbicara dalam bahasa mereka.
Saya kebetulan bekerja sebagai pimpinan teknis dan konsultan, jadi saya memiliki banyak pengalaman dalam bisnis ini. Mari berbagi dengan Anda beberapa template.
Lima argumen yang bisa Anda berikan
1) "Refactoring akan membantu mengurangi volatilitas biaya marjinal per unit fungsionalitas perangkat lunak."
Ini adalah kutipan akurat dari pidato bagus JB Reinsberg di konferensi tentang "Ekonomi dalam Pengembangan Perangkat Lunak". Tunggu, jangan pergi! Segala sesuatu yang dikatakan di sini, Anda tahu betul, itu hanya dirumuskan dalam semangat abstrak dan musykil.
Mari mulai secara berurutan:
- "Refactoring akan membantu mengurangi ..." - sejauh ini, semuanya baik-baik saja
- "... volatilitas ..." - dengan kata lain, ketidakpastian
- "... biaya marjinal ..." - yaitu, berapa banyak sumber daya yang akan dibutuhkan untuk menghasilkan satu unit tambahan lagi
- “… Per unit fungsionalitas perangkat lunak” adalah fitur yang memiliki nilai untuk bisnis. Hore! Nilai bisnis persis seperti yang kita butuhkan.
Kelima argumen tersebut didasarkan pada gagasan umum yang sama tentang terjemahan dari satu bahasa ke bahasa lain, yang sering kali kita abaikan dalam menghadapi orang yang jauh dari ranah TI. Jangan gunakan bahasa gaul, bersandar pada konsep dari ekonomi dan bisnis - itulah bahan rahasianya. Ini akan membantu Anda membuat koneksi dengan manajemen Anda lebih cepat.
2) "Selama sebulan terakhir, 63% sumber daya pengembangan dihabiskan untuk memperbaiki masalah dengan kualitas produk"
Nah, gantikan nomor Anda di sini. Intinya adalah mendukung pesan dengan data kuantitatif. Hutang teknologi tidak dapat membantu tetapi memengaruhi proses kerja Anda sehari-hari. Bisakah kamu membuktikannya? Tentu saja!
Berikut beberapa metrik yang dapat Anda lihat:
- . ? ?
- -, , . , ? ?
- , . ? ?
Tunjukkan manajemen tepat di mana kualitas kode buruk diterjemahkan bagi mereka. Lebih baik lagi, temukan cara untuk mengubah angka-angka itu menjadi nilai uang.
Saya pernah mengunjungi bug post-mortem yang bisa dihindari jika pemeriksaan tipe data telah dilakukan. Kode itu ditulis dalam JavaScript. Saat itu, ada perdebatan di perusahaan tentang apakah akan beralih ke TypeScript.
Pengembang yang mengerti apa yang terjadi tidak terlalu malas untuk mengumpulkan data dan dapat menilai kerusakan yang disebabkan oleh bug tersebut pada bisnis. Ternyata dalam beberapa bulan keberadaannya, bug tersebut menyedot satu juta dolar Kanada dari perusahaan tersebut. Juta! Itu saja sudah cukup untuk mengimbangi biaya peralihan ke TypeScript.
Berdasarkan ini, diputuskan bahwa layanan baru akan diimplementasikan dalam TypeScript, dan untuk yang paling penting, perlu memeriksa tipe data secara retroaktif.
3) “Dari sudut pandang teknis, kami bekerja dengan kredit untuk mengeluarkan produk lebih cepat. Sekarang kami perlu melunasi sebagian utangnya agar waktu ke pasar tidak bertambah. ”
Sekali lagi: kami berbicara dengan bahasa lawan bicara. Metafora bisa sangat efektif ketika Anda perlu menyampaikan pesan: metafora menghubungkan konsep yang tidak biasa dengan konsep yang sudah dikenal oleh pendengar dan dengan demikian membantu untuk memahaminya. Konsep "kredit" sudah dikenal baik oleh manajer mana pun. Dan "utang teknis" itu sendiri juga merupakan metafora yang telah beredar luas.
Atau, katakanlah, bayangkan sebuah perusahaan sebagai restoran, dan basis kode sebagai area dapurnya. Saat piring kotor menumpuk, melayani semakin banyak pengunjung menjadi semakin sulit. Karyawan perlu memiliki waktu untuk mencuci piring di sela-sela waktu memasak.
4) "Jika Anda menginvestasikan 10% waktu Anda dalam kualitas kode, omset Anda akan turun secara signifikan."
Sejauh ini, kita telah membicarakan tentang konsekuensi nyata dari kualitas kode yang buruk. Tapi ada satu hal berbahaya yang mudah dilupakan: pergantian.
Perusahaan saat ini mengalami kesulitan mempertahankan pengembang, terutama yang berbakat, untuk tetap menggunakannya. Jika orang seperti itu berhenti menikmati pekerjaan, tidak akan sulit baginya untuk mendapatkan tawaran lain dan pergi begitu saja ke mana pun mereka memandang, jauh dari kekacauan abadi. Mengapa, mungkin Anda sendiri sudah mencari-cari sesuatu yang lebih baik ...
Dan sekarang mari kita tanyakan pada diri sendiri pertanyaan: berapa biaya perusahaan untuk menggantikan pengembang yang sudah pensiun? Seorang spesialis baru perlu ditemukan, menjalani proses perekrutan, mendapatkan informasi terkini. Butuh investasi, butuh waktu, dan memperlambat seluruh tim. Manajemen pasti memilih untuk tidak melakukan perombakan seperti ini setiap tahun. Oleh karena itu, mengurangi fluiditas bisa menjadi argumen yang serius. Dan fakta memiliki rencana untuk menghilangkan hutang teknis akan segera memberikan motivasi kepada seluruh tim +100.
5) "Jika Anda menginvestasikan 20% sumber daya dalam pemfaktoran ulang, FRT akan dikurangi setengahnya dan ROI akan positif untuk produktivitas pengembang"
FRT adalah waktu respons, metrik penting untuk dukungan pengguna. Bisnis berusaha keras untuk memastikan bahwa pelanggan puas dengan segalanya.
Di sini kami melakukan hal berikut:
- Memilih metrik yang memiliki banyak bobot dalam dukungan teknis;
- Kami menemukan beberapa masalah yang muncul secara teratur dan membutuhkan intervensi pengembang;
- Kami menawarkan rencana untuk mengurangi jumlah panggilan ke dukungan teknis dengan menghilangkan akar masalah.
- Jika jenis masalah ini diselesaikan, pengembang akan cenderung tidak terlibat dalam tugas dukungan pengguna. Artinya, mereka akan membebaskan lebih banyak waktu daripada yang dihabiskan untuk refactoring, yang berarti bahwa investasi akan membuahkan hasil - ROI yang sangat positif.
Akhirnya, mereka memutuskan
Tidak ada yang bisa membantahnya. Saya telah menawarkan lima argumen untuk meyakinkan orang-orang tentang pentingnya menghilangkan hutang teknis, tetapi sekarang saya pikir ada satu nasihat lagi yang perlu diberikan sebelum Anda menangani manajer mana pun.
Refactor saat Anda pergi
Refactoring tidak boleh dilihat sebagai fase kerja terpisah pada fungsionalitas. Toh Anda masih belum bisa memprediksi terlebih dahulu fitur-fitur apa saja yang akan diterapkan di masa mendatang. Ini berarti Anda perlu menyesuaikan basis kode untuk realitas baru saat tersedia. Ini juga bagian dari pekerjaan yang diperlukan untuk menciptakan nilai material itu - setiap pengembang profesional akan mengonfirmasi hal ini.
Aturan ini berfungsi bahkan untuk database dengan kode lama. Baiklah, kamu pasti tidak akan membawanya ke dalam bentuk dewa besok. Dan mencoba melakukan pemfaktoran ulang skala besar di antaranya adalah masalah yang mati juga. Tetapi dengan pendekatan ini, setidaknya situasinya tidak akan bertambah buruk. Dan saat bekerja dengan kode lrgacy, Anda harus fokus bukan pada "baik", tetapi pada "lebih baik".
Apakah Anda memperbaiki bug? Luangkan satu jam ekstra untuk menulis tes otomatis. Apakah Anda bersiap untuk meluncurkan fitur baru? Luangkan satu hari ekstra untuk membersihkan kode. Cobalah untuk membuat perubahan tanpa rasa sakit dari hari ke hari. Setelah beberapa bulan, Anda akan melihat bahwa kebiasaan ini berdampak besar pada produktivitas Anda. Apa kamu tahu kenapa? Karena refactoring membantu mengurangi volatilitas biaya marjinal per unit fungsionalitas perangkat lunak.