Ini adalah sesuatu yang telah saya pikirkan sejak saya membaca jawaban ini di utas opini pemrograman kontroversial :
Pekerjaan Anda adalah membuat diri Anda tidak bekerja.
Saat Anda menulis perangkat lunak untuk atasan Anda, perangkat lunak apa pun yang Anda buat harus ditulis sedemikian rupa sehingga dapat diambil oleh pengembang mana pun dan dipahami dengan sedikit usaha. Ini dirancang dengan baik, ditulis dengan jelas dan konsisten, diformat dengan bersih, didokumentasikan di mana perlu, dibangun setiap hari seperti yang diharapkan, diperiksa ke dalam repositori, dan versi yang sesuai.
Jika Anda tertabrak bus , diberhentikan, dipecat, atau keluar dari pekerjaan, majikan Anda harus dapat menggantikan Anda dengan pemberitahuan sesaat, dan orang berikutnya dapat masuk ke peran Anda, mengambil kode Anda dan bangun dan berjalan dalam seminggu puncak. Jika dia tidak bisa melakukan itu, maka Anda telah gagal total.
Menariknya, saya menemukan bahwa memiliki tujuan itu telah membuat saya lebih berharga bagi majikan saya. Semakin saya berusaha menjadi disposable, semakin berharga saya bagi mereka.
Dan sudah dibahas sedikit dalam pertanyaan lain, seperti yang ini , tapi saya ingin membahasnya lagi untuk membahas dari sudut pandang yang lebih kosong " ini bau kode !! " - yang belum benar-benar dibahas. belum mendalam.
Saya telah menjadi pengembang profesional selama sepuluh tahun. Saya mempunyai satu pekerjaan di mana kode itu ditulis dengan cukup baik untuk diambil relatif cepat oleh pengembang baru yang layak, tetapi dalam kebanyakan kasus di industri, tampaknya tingkat kepemilikan yang sangat tinggi (baik kepemilikan individu maupun tim) adalah norma. Sebagian besar basis kode tampaknya tidak memiliki dokumentasi, proses, dan "keterbukaan" yang memungkinkan pengembang baru mengambilnya dan bekerja dengan cepat. Tampaknya selalu ada banyak trik dan peretas kecil yang tidak tertulis yang hanya diketahui oleh seseorang yang mengetahui basis kode dengan baik ("memiliki" itu).
Tentu saja, masalah nyata dengan ini adalah: bagaimana jika orang itu berhenti atau "ditabrak bus"? Atau di tingkat tim: bagaimana jika seluruh tim keracunan makanan ketika mereka pergi makan siang tim mereka, dan mereka semua mati? Apakah Anda dapat mengganti tim dengan serangkaian pengembang acak baru yang relatif tanpa rasa sakit? - Dalam beberapa pekerjaan masa lalu saya, saya tidak bisa membayangkan itu terjadi sama sekali. Sistemnya begitu penuh trik dan peretasan sehingga Anda " hanya perlu tahu ", bahwa setiap tim baru yang Anda sewa akan membutuhkan waktu lebih lama daripada siklus bisnis yang menguntungkan (mis., Rilis stabil baru) untuk membuat semuanya berjalan kembali. Singkatnya, saya tidak akan terkejut jika produk tersebut harus ditinggalkan.
Jelas, kehilangan seluruh tim sekaligus akan sangat jarang. Tetapi saya pikir ada hal yang lebih halus dan menyeramkan dalam semua ini - yang merupakan titik yang membuat saya berpikir untuk memulai utas ini, karena saya belum pernah melihatnya membahasnya dalam istilah-istilah ini sebelumnya. Pada dasarnya: Saya pikir kebutuhan yang tinggi untuk kepemilikan kode sangat sering merupakan indikator hutang teknis . Jika ada kekurangan proses, komunikasi, desain yang baik, banyak trik kecil dan peretasan dalam sistem yang Anda "hanya perlu tahu", dll. - itu biasanya berarti bahwa sistem semakin masuk ke hutang teknis yang semakin dalam dan semakin dalam.
Tetapi masalahnya adalah - kepemilikan kode sering disajikan sebagai semacam "kesetiaan" kepada proyek dan perusahaan, sebagai bentuk positif dari "mengambil tanggung jawab" untuk pekerjaan Anda - sehingga tidak populer untuk langsung mengutuknya. Tetapi pada saat yang sama, sisi utang teknis dari persamaan sering berarti bahwa basis kode semakin tidak terbuka, dan lebih sulit untuk dikerjakan. Dan terutama ketika orang pindah dan pengembang baru harus mengambil tempat mereka, biaya utang teknis (yaitu pemeliharaan) mulai melonjak.
Jadi dalam arti tertentu, saya benar-benar berpikir bahwa itu akan menjadi hal yang baik untuk profesi kita jika tingkat kebutuhan kepemilikan kode yang tinggi secara terbuka dilihat sebagai bau pekerjaan (dalam imajinasi programmer populer). Alih-alih dipandang sebagai "mengambil tanggung jawab dan kebanggaan" dalam pekerjaan, itu harus dilihat lebih sebagai "membudidayakan diri sendiri dan menciptakan keamanan kerja buatan melalui utang teknis".
Dan saya pikir tes (percobaan pikiran) pada dasarnya harus: bagaimana jika orang (atau memang, seluruh tim) akan menghilang dari muka bumi besok. Apakah ini akan menjadi cedera besar - mungkin fatal - pada proyek, atau apakah kita dapat membawa orang baru, membuat mereka membaca dokumen dan membantu file dan bermain-main dengan kode selama beberapa hari - dan kemudian kembali bisnis dalam beberapa minggu (dan kembali ke produktivitas penuh dalam sebulan atau lebih)?