Bagaimana Anda mengatasi kode jelek yang Anda tulis? [Tutup]

Jadi klien Anda meminta Anda untuk menulis beberapa kode, maka Anda melakukannya. Dia kemudian mengubah spesifikasi pada Anda, seperti yang diharapkan, dan Anda rajin menerapkan fitur barunya seperti anak kecil yang baik. Kecuali ... fitur baru agak bertentangan dengan fitur lama, jadi sekarang kode Anda berantakan. Anda benar - benar ingin kembali dan memperbaikinya, tetapi dia terus meminta hal-hal baru dan setiap kali Anda selesai membersihkan sesuatu, itu berakhir berantakan lagi.

Apa yang kamu kerjakan? Berhentilah menjadi maniak OCD dan terima saja bahwa kode Anda akan berakhir berantakan, apa pun yang Anda lakukan, dan teruslah menempelkan fitur-fitur ke monster ini? Simpan pembersih untuk versi 2?

Dapatkan pekerjaan lain dan biarkan orang lain menanganinya. Muahahahhahahaa.

.....

Hanya bercanda. :)

Namun dengan sangat serius: padding estimasi adalah teman Anda. Saya biasanya melakukan perkiraan realistis yang layak, kemudian menggandakannya. Ini mungkin terdengar berlebihan, dan terkadang memang demikian, tetapi lebih baik untuk melebih-lebihkan sedikit dan bahkan kadang-kadang terlihat agak lambat - daripada meninggalkan kesan buruk dengan mematikan kode kereta dan selalu membuat taksiran Anda. Dan tentu saja, Anda dikenai hutang teknis dengan membiarkan basis kode menjadi rusak.

Kiat lain (terkait): Selalu perkirakan tugas yang tampaknya kecil, tidak ada otak dengan ukuran yang layak. Katakan, misalnya - item yang Anda hampir yakin hanya akan menjadi perubahan satu baris 30 detik sederhana - berikan 1 jam (atau mungkin apa pun blok waktu terendah pada kartu absen atau sistem CR Anda, misalnya 15 menit / 0,25 jam) . Dan berikan blok setengah hari atau 1 hari untuk item yang sedikit lebih besar tetapi masih relatif sepele.

Alasan untuk ini adalah terutama psikologis: Saya menemukan bahwa jika Anda terbiasa dengan cepat meretas perubahan kecil, pekerjaan terasa terburu-buru, dan Anda tidak pernah berakhir dengan duduk santai, mengambil stok, dan merefactoring hal-hal yang perlu direaktor ulang. Juga, pada tingkat praktis: perubahan kecil tapi tidak sepele terkadang meledak, dan Anda tidak ingin terus-menerus merasa seperti Anda terlambat dan memadamkan kutu. Itu adalah bagian dari alasan mengapa basis kode menjadi rusak seiring waktu.

Akhirnya, selalu ingat bahwa orang tidak perlu tahu bahwa Anda menambah perkiraan Anda. Selama Anda adalah pengembang yang kompeten dan Anda sedang melakukan pekerjaan dengan kecepatan yang layak, bantalan ini tidak akan terlihat. yaitu, jangan beri tahu PHB "Perkiraan awal saya adalah bahwa ini akan memakan waktu dua jam, tapi beri saya setengah hari". Katakan saja kepadanya, "Saya pikir ini akan memakan waktu setengah hari." dan tinggalkan di sana.

Sengaja melebih-lebihkan waktu yang dibutuhkan untuk fitur Anda selanjutnya. Gunakan waktu ekstra itu untuk membersihkan.

Anda tidak akan pernah bisa membenarkan pemeliharaan, dan klien membutuhkannya, jadi beri mereka obat pahit (sedikit peningkatan biaya untuk fitur berikutnya) sehingga mereka bisa menjadi lebih baik.

Cobalah untuk melakukan desain ulang yang tepat sambil mengintegrasikan fitur-fitur baru. Tidak ada lagi. Tanpa desain ulang, Anda terus-menerus menambahkan semakin banyak gesekan untuk perubahan lebih lanjut dan fitur baru.

Pada titik tertentu, Anda akan berhenti dekat di mana segala sesuatu tampaknya butuh waktu lama. Sebagian besar perusahaan mungkin menggunakan penulisan ulang besar pada saat ini, versi 2. Ini memiliki ekonomi yang sangat buruk dan merupakan momen yang baik bagi pelanggan Anda untuk mencoba pihak pengembangan yang berbeda jika mereka merasa cenderung.

Redesign / refactoring yang tepat dapat melindungi investasi pelanggan Anda dan menjaga hal-hal yang berkelanjutan. Anda harus membangun ini. Optimalkan untuk perubahan, lampu perjalanan.

Dengan semua komentar tentang perkiraan yang berlebihan, saya pikir ada sedikit titik (peluang bagus) yang terlewatkan.

Ini bukan tentang memperkirakan waktu yang diambil membuat perubahan (hanya) dan kemudian menambahkan beberapa, ini tentang memperkirakan waktu yang diperlukan untuk memodifikasi kode (refactor!) Untuk membawanya ke titik di mana perubahan tersebut dapat dilakukan dengan aman dan kemudian membuat berubah (mungkin agak mungil bersama). Ok, ini sama saja dengan hal yang sama ... tapi tidak ada pertanyaan tentang pemalsuan atau peregangan atau estimasi yang berlebihan, ini hanya masalah mengatakan bahwa untuk melakukan ini pertama-tama saya perlu melakukan itu dan ini adalah berapa lama secara keseluruhan. Kuncinya di sini adalah bahwa Anda bekerja pada bagian-bagian dari sistem yang bergantung pada perubahan dan tidak lebih - jika ada kode mengerikan di tempat lain ... sulit, tangkap ketika Anda di sana.

Untuk kembali ke pertanyaan awal sedikit - setelah bertahun-tahun turun ke ini untuk saya, ketika Anda menerapkan sesuatu kecuali Anda tahu (tidak percaya, tidak berharap (curiga?), Tidak berpikir tetapi tahu ) bahwa hal-hal tambahan adalah juga diperlukan maka Anda harus melakukan apa yang Anda butuhkan untuk menerapkan persyaratan itu dan tidak lagi dengan cara yang rapi dan elegan yang Anda bisa.

Ketika Anda datang untuk mengimplementasikan hal berikutnya - beberapa saat kemudian - Anda mengambil langkah-langkah yang diperlukan untuk membawa basis kode (dan basis data dan apa pun) ke negara yang diperlukan untuk mengimplementasikan fungsionalitas tersebut dengan cara yang serapi dan elegan yang Anda bisa. Refactoring ini adalah tempat Anda berurusan dengan kekacauan yang muncul secara alami ketika sebuah proyek berkembang - dan mudah-mudahan menghindari menciptakan lebih banyak kekacauan (atau setidaknya menjaga levelnya konsisten).

Salah satu area diskusi di sini adalah "Hutang Teknis" - ini seperti cerukan, Anda harus membayarnya kembali dan semakin lama Anda membiarkannya semakin besar (dalam hal ini waktu yang diperlukan untuk memperbaiki) Anda akan bertambah - yang memberi Anda penghasilan yang baik. argumen untuk menghabiskan sebagian waktu Anda meminimalkan hutang teknis.

Di sinilah juga pengujian unit dan pengujian otomatis lainnya mulai masuk (jika saya bisa melakukannya dengan baik dan saya katakan saya cukup yakin saya akan menjadi orang yang lebih bahagia!) Dikombinasikan dengan server build yang tepat (yang dapat menjalankan setidaknya beberapa dari tes Anda). Dikombinasikan dengan itu - tetapi bernilai dalam diri mereka sendiri - adalah pola-pola seperti injeksi ketergantungan dan inversi kontrol (tidak pernah benar-benar yakin seberapa banyak "sama" keduanya) karena mereka membuatnya lebih mudah untuk mengubah pipa ledeng dan karenanya menangani perubahan dalam isolasi.

Terakhir - ingat, jika tidak rusak jangan memperbaikinya. Merapikan kode Anda semata-mata demi merapikannya mungkin memuaskan tetapi ini juga merupakan kesempatan untuk membuat kesalahan, sementara itu bisa menyakitkan jika Anda tidak perlu mengubahnya dan tidak membangunnya, mungkin lebih baik meninggalkan beberapa benjolan sendirian - kesempatan untuk memperbaiki atau mengganti akhirnya akan bergulir!

1) Kontrol perubahan yang tepat adalah teman Anda

Jika pelanggan mengubah spesifikasi yang baik-baik saja, itu haknya, namun itu adalah perubahan dan perlu dibebankan biaya (atau dihitung biayanya dengan cara apa pun yang sesuai dengan struktur / hubungan proyek).

Perkiraan untuk perubahan itu harus mencakup biaya refactoring yang diperlukan . Klien mungkin saja menolak apa yang tampaknya menjadi biaya tinggi tetapi pada saat itu Anda perlu menjelaskan kepadanya bahwa karena kode sudah setengah ditulis ada elemen yang perlu ditulis ulang untuk memastikan kuat dan dapat didukung di masa depan dan bahwa jika itu tidak dilakukan maka dia kemungkinan akan mengalami masalah dengan dukungan di masa depan atau perubahan menjadi lebih mahal.

2) Refactoring Harus Dilakukan Seperti Itu Memberikan Manfaat Jangka Panjang Asli kepada Klien

Ketika mempertimbangkan refactoring Anda selalu perlu mempertimbangkan apa yang sebenarnya dibutuhkan dan apa yang penting dan memastikan bahwa pekerjaan refactoring memberikan nilai uang jangka panjang yang asli.

Bagaimanapun, kita harus melakukan hal-hal ini sehingga kode tetap dapat diperpanjang dan dapat didukung dalam jangka menengah / panjang untuk memastikan bahwa investasi klien tetap valid daripada tidak ada dorongan untuk kesempurnaan teoritis. Pekerjaan refactoring (dan perkiraan yang sesuai) harus dilakukan dengan ini sebagai ruang lingkup, dan bukan hanya karena Anda sekarang berpikir mungkin ada cara yang sedikit lebih baik untuk melakukannya.

Beberapa programmer menyarankan bahwa cara untuk mengendalikan masalah itu dengan klien adalah membuat klien menandatangani dan mengesahkan spesifikasi awal. LALU, ketika mereka meminta perubahan persyaratan yang tidak ada dalam spesifikasi awal, Anda memberi tahu mereka bahwa Anda harus melalui kontrak dan jadwal proyek untuk menghitung biaya tambahan dan penundaan waktu, kemudian membuat lampiran pada kontrak. Tampaknya hal itu sangat membantu dalam mencegah klien bersikeras pada fitur baru (tidak terduga).

Saya memiliki komentar berikut dalam basis kode yang saat ini saya kerjakan:

/*
 * Every time I see this function, I want to take a shower.
 */

Saya tahu, sangat baik situasi yang Anda gambarkan. Apa yang saya lakukan adalah mencoba (yang terbaik) untuk menunggu sampai semuanya tenang dan segala jenis 'creep' telah 'merayap' semua yang akan dilakukannya. Pada saat itu, Anda mungkin telah merilis sesuatu yang dapat digunakan, dan Anda dapat meluangkan waktu untuk membereskan dan menerapkan hal-hal yang sedikit berbeda.

Anda tidak dapat berlarian membersihkan banyak kekacauan kecil berulang kali. Itu hanya tiga kali lipat pekerjaan Anda, dan frustrasi. Tunggu sampai menjadi lebih besar, tetapi tidak bergerak berantakan dan kemudian Anda dapat melakukan sesuatu tentang hal itu.

Preferensi saya adalah untuk menghindari situasi ini sejak awal.

Itu semua tergantung pada BAGAIMANA Anda membaca spec. Mudah untuk menganggapnya sebagai tablet batu, tetapi dalam kenyataannya sebagian besar spesifikasi berubah. Saat Anda mendesain kode Anda, lihat seberapa besar kemungkinan masing-masing bagian dari spesifikasi akan berubah. Seiring waktu, Anda akan menjadi cukup baik dalam memprediksi ini.

Setelah masuk ke dalam kekacauan, pengalaman dan penilaian sangat penting. Apakah Anda menulis bug baru karena kode spageti ini? Apakah perlu waktu lebih lama untuk diterapkan? ini akan mengarah pada melakukan refactor taktis.

untuk masa depan, sepertinya Anda harus bekerja dalam kemitraan dengan pelanggan Anda. Mengatakan kepada mereka, "lihat produk ini berkembang secara signifikan di luar spesifikasi asli. Sementara desain asli bagus untuk tingkat itu, memperluasnya ke arah X dan arah Y perlu beberapa restrukturisasi dalam desain" ditangani dengan baik, dan Anda bahkan akan mendapatkan pelanggan untuk membayarnya.

Biaya oleh jam dan jika dia ingin perubahan mengatakan itu baik-baik saja tetapi memasukkan waktu yang diperlukan untuk menulis kode yang baik ke dalam persamaan. Juga ingat menulis kode yang lebih rapi terbayar dalam jangka panjang ketika Anda harus memeliharanya. Menghemat waktu sekarang bisa dikenakan biaya nanti.

Saya pikir menulis perangkat lunak harus berjalan seiring dengan kebutuhan bisnis. Jika itu adalah proyek sekali pakai (seperti prototipe yang perlu dibangun dalam seminggu, dengan input baru datang setiap hari), maka tidak perlu khawatir tentang pemeliharaan kode dan hal-hal lain - waktu sangat penting dan Anda hanya perlu dorong kode Anda keluar dari pintu secepat mungkin.

Tetapi jika Anda menulis aplikasi jangka panjang, maka masuk akal untuk mempertimbangkan semua ini, karena ada dampak yang cukup besar pada berapa lama waktu yang dibutuhkan untuk membangun fitur baru, untuk memperbaiki bug yang ada, untuk mengintegrasikan ke dalam aplikasi lain dan hal-hal lain - dan ini diterjemahkan ke dalam dampak bisnis (karena lebih banyak waktu diperlukan kemudian dan lebih banyak biaya).

Jadi lebih baik untuk membuat pembuat keputusan peka terhadap biaya aktual dari tidak refactoring kode kapan pun diperlukan - dalam pengalaman saya, jika biaya dan dampak waktu dari kedua opsi dijelaskan dalam istilah yang terukur kepada pemilik keputusan, maka keputusan dapat menjadi tidak punya otak. Jangan berharap orang-orang memberi tahu Anda 'ya, silakan tulis kode yang indah, walaupun itu membutuhkan waktu dua kali lebih banyak dan tidak memberi saya manfaat tambahan'. Itu tidak bekerja seperti itu.

Jadikan itu bagian dari proses Anda, saya menyebutnya "refactoring ekstrem" dan itu akan menjadi besar! ;) Lakukan saja dengan cepat dan ketika cukup banyak fitur baru telah ditambahkan bahwa ada jaringan parut, perbaiki itu. Terus bertanya pada diri sendiri, "Sekarang, jika saya mulai dari awal, bagaimana saya melakukannya?"

Orang-orang yang berpikir mereka dapat merancang dan memikirkan segala sesuatu di muka sebagian besar membodohi diri mereka sendiri, Anda (dan klien Anda) selalu belajar hal-hal seiring berjalannya waktu. Gunakan pelajaran itu.

Ketika Anda seorang programmer yang baik, Anda akan dapat melakukan refactor dengan cukup cepat dan ketika Anda melakukannya terus-menerus kode akan mulai mengambil "bentuk yang tepat", yang berarti akan menjadi lebih fleksibel dengan lebih sedikit ketergantungan.

Klien mungkin jengkel jika mereka tahu Anda "membuang-buang waktu" mengerjakan ulang hal-hal sehingga membantu tidak bertanya / mengatakan dan menjadi sangat cepat tentang hal itu.

Kode yang dikembangkan dengan cara ini akan menghemat banyak waktu pada akhirnya dan akan membuatnya semakin mudah untuk menambahkan fitur baru.

Saya juga akan mengatakan bahwa salah satu alasan terbesar untuk kode buruk adalah ketakutan beberapa programmer untuk melakukan refactoring struktural yang lebih besar, dan semakin lama Anda menunggu semakin buruk.

Andalkan Kekuatan Yang Lebih Tinggi

Maksud saya bukan berdoa. Maksud saya, pastikan ada orang bisnis (yaitu manajer proyek atau yang setara) yang dapat Anda tempatkan sebagai bantalan antara Anda dan klien. Jika klien terlalu menuntut, biarkan pebisnis turun ke bawah dan siap untuk menggunakan "itu bisa dilakukan tetapi saya tidak yakin apakah itu cocok dengan ruang lingkup spesifikasi, lihat [pebisnis]".

Dalam aliran proyek normal, spesifikasi umum harus dibekukan sebelum pengembangan serius terjadi.

Banyak klien akan terus mendorong perubahan / peningkatan / peningkatan selama Anda membiarkannya. Banyak yang akan menyalahgunakan kemampuan itu secara maksimal karena itu membuat mereka merasa mendapatkan yang terbaik untuk uang mereka (bahkan jika itu menyabot proyek Anda).

Mintalah seseorang yang berdedikasi untuk menyempurnakan dan membekukan spesifikasi sejak dini dan menegakkannya nanti.

Tidak ada yang salah dengan melakukan sedikit tambahan untuk sedikit karma baik dengan klien, tetapi bersiaplah untuk tunduk pada kekuatan yang lebih tinggi ketika mereka keluar dari tangan. Jika spesifikasi memerlukan jumlah perubahan yang konyol, mungkin inilah saatnya untuk kembali ke lingkaran bisnis dan menilai kembali kontrak dan / atau menambahkan tambahan pada kontrak (dengan kompensasi uang yang adil).

Fakta bahwa Anda mengalami masalah ini tidak ada hubungannya dengan bagaimana Anda membuat kode. Ini pertanda bahwa manajer proyek Anda kurang dimanfaatkan pada proyek (apakah itu salah Anda, salahnya, atau keduanya).

Seperti yang orang lain katakan dalam banyak jawaban, menambahkan buffer waktu untuk kemungkinan juga diperlukan pada proyek apa pun tetapi menentukan yang harus diputuskan di balik pintu tertutup sebelum spesifikasi dibekukan dan dikirim ke klien oleh PM.

Desain awal yang tepat tidak bisa menghindari masalah. Dan hampir tidak mungkin (atau sangat-sangat sulit) untuk mempertimbangkan semua persyaratan "mungkin" di masa depan. Jadi setelah beberapa waktu Big Re-factoring akan tiba. Dan solusi terbaik adalah menulis ulang semuanya.

Dalam beberapa kata: alih-alih memasang turet ke Ferrari merah, pertimbangkan kembali persyaratan dan buat tank.

Matikan dengan api.

Aka refactor sesegera mungkin: misalnya ketika kode jelek datang dari terburu-buru untuk tenggat waktu, saya akan refactor setelah tenggat waktu karena Anda tidak dapat (atau setidaknya tidak boleh) menambahkan lebih banyak fitur sampai kode yang ada dapat dipertahankan, jika tidak itu akan membuatnya lebih sulit untuk men-debug kode masa depan.

Tulis unit test untuk proyek Anda yang menguji keadaan saat ini dan kemudian refactor ketika Anda punya waktu, dengan cara ini Anda menghindari melanggar proyek Anda saat Anda sedang mencoba untuk membersihkannya.

Jawaban paling sederhana. Saya akan berhenti melakukan pengkodean dalam bentuk apa pun, sampai dia memiliki spesifikasi akhir untuk apa yang dia inginkan sampai sekarang.

Maka mereka perlu memprioritaskan daftar fitur dll, untuk mengkonfirmasi item apa yang harus dimiliki saat ini, dan apa yang dapat dilakukan nanti ....

Menggunakan pengalaman Anda untuk menentukan berapa waktu / biaya dari masing-masing fitur, dan kemudian memberi tahu mereka, jika mereka menginginkannya, itu akan memakan waktu x jumlah & uang.

Anda berurusan dengan kejahatan besar lingkup fitur merayap, dan mereka akan terus menambahkan fitur tanpa henti, sampai tidak ada yang pernah dilakukan atau diselesaikan dengan buruk.

Beri tahu mereka setelah Anda memiliki daftar akhir, bahwa Anda akan membuat modifikasi di masa depan, seperti yang mereka inginkan, tetapi perlu fokus pada 15/20 teratas yang harus mereka miliki sekarang.

Kemudian berdasarkan waktu penyelesaian, beri tahu mereka, bahwa setelah ini dirilis, maka Anda akan terbuka untuk membahas / melakukan brainstorming pada versi selanjutnya.

Setelah keputusan akhir dibuat tentang apa yang harus dilakukan untuk versi saat ini, semua diskusi / ide / saran harus dihentikan 100%.

Jika ia mendapatkan ide tanpa henti, katakan padanya untuk menuliskannya, dalam daftar fitur mereka untuk versi berikutnya, dan biarkan Anda fokus untuk memberikan fitur paling penting yang mereka inginkan saat ini.

Jika mereka terus buang waktu Anda, teruslah ubah pikiran. Kemudian saya akan berhenti mengerjakan proyek, dan mengerjakan proyek lain, sampai mereka menyelesaikan keputusan mereka ..

Ini sulit dilakukan, tetapi fitur scope creep sangat merusak waktu, energi, motivasi dan pemikiran jernih.

Dari perspektif lengkap proyek:

Belajarlah dari kode dengan tim Anda, lihat apa yang bisa di refactored dan digunakan kembali lain kali, lalu minum bir.

Dari perspektif pengembangan:

Dengan sabar jelaskan mengapa pengembangan telah berhenti, dan jelaskan mengapa itu tidak dapat berlanjut sampai semua spesifikasi ada di meja dan dipahami. Lalu, pergi minum bir.

Dari perspektif perencanaan:

Minta semua spesifikasi di muka dan bekerja dengan semua orang untuk memiliki pemahaman yang jelas tentang jalur pengembangan. Libatkan klien / pemangku kepentingan sedekat mungkin untuk memastikan setiap orang di halaman yang sama. Malamnya, buat semua orang minum bir. Besok, mulailah proyek.