it-swarm-id.com

Bagaimana Anda mengatasi kode jelek yang Anda tulis?

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 sungguh 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 hanya menerima bahwa kode Anda akan berakhir berantakan tidak peduli apa yang Anda lakukan, dan terus menempelkan fitur-fitur ke monster ini? Simpan pembersih untuk versi 2?

89
mpen

Dapatkan pekerjaan lain dan biarkan orang lain menanganinya. Muahahahhahahaa.

.....

Hanya bercanda. :)

Tetapi dalam semua keseriusan: estimasi padding 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 terutama bersifat psikologis: Saya menemukan bahwa jika Anda terbiasa dengan cepat meretas perubahan kecil, pekerjaan itu terasa terburu-buru, dan Anda tidak pernah berakhir dengan duduk santai, mengambil persediaan, dan melakukan refactoring hal-hal yang perlu di refactored. Juga, pada tataran praktis: perubahan kecil tapi non-sepele terkadang meledak, dan Anda tidak ingin terus-menerus merasa seperti Anda terlambat dan memadamkan kutu. Ini adalah bagian dari alasan mengapa kode basis menjadi rusak seiring waktu.

Akhirnya, selalu ingat bahwa orang tidak harus tah bahwa Anda sedikit banyak memperkirakan estimasi Anda. Selama Anda adalah pengembang yang kompeten dan Anda sedang mengerjakan pekerjaan dengan kecepatan yang layak, bantalan ini tidak akan terlihat. yaitu, jangan beri tahu PHB "Perkiraan awal saya adalah akan memakan waktu dua jam, tapi beri saya setengah hari". Katakan saja padanya, "Saya pikir ini akan memakan waktu setengah hari." dan tinggalkan di sana.

41
Bobby Tables

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.

66
Frank Shearar

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.

11
Joppe

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

Ini bukan tentang memperkirakan waktu yang diambil membuat perubahan (hanya) dan kemudian menambahkan beberapa, tentang memperkirakan waktu yang diperlukan untuk memodifikasi kode (refactor!) Untuk membawanya ke titik di mana perubahan dapat dilakukan dengan aman dan untuk kemudian membuat ganti (mungkin agak mungil bersama). Ok, ini sama saja dengan hal yang sama ... tetapi tidak ada pertanyaan tentang pemalsuan atau peregangan atau estimasi yang berlebihan, itu 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 sistem yang bergantung pada perubahan dan tidak lebih - jika ada kode mengerikan di tempat lain ... sulit, tangkap ketika Anda berada di sana.

Untuk kembali ke pertanyaan awal sedikit - setelah bertahun-tahun turun ke ini untuk saya, ketika Anda menerapkan sesuatu kecuali Anda tah (tidak percaya, tidak berharap (tersangka?), Tidak berpikir tetapi tah) bahwa hal-hal tambahan 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 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 hal-hal tersebut - tetapi memiliki nilai dalam diri mereka sendiri - adalah pola-pola seperti injeksi ketergantungan dan inversi kontrol (tidak pernah yakin seberapa banyak keduanya "sama") karena mereka membuatnya lebih mudah untuk mengubah pipa ledeng dan karenanya menangani perubahan isolasi.

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

6
Murph

1) Kontrol perubahan yang tepat adalah teman Anda

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

Perkiraan untuk perubahan itu harus mencakup biaya yang diperlukan refactoring. 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 Sehingga 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 teoretis. Pekerjaan refactoring (dan perkiraan terkait) harus dilakukan dengan ini sebagai ruang lingkup, dan bukan hanya karena Anda sekarang berpikir mungkin ada cara yang sedikit lebih baik untuk melakukannya.

4
Jon Hopkins

Beberapa programmer menyarankan bahwa cara untuk mengendalikan masalah itu dengan klien adalah meminta klien menandatangani dan mengesahkan spesifikasi awal. MAKA, 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).

3
Jas

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.

3
Tim Post

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 aslinya 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.

2
Michael Shaw

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.

2
Craig

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.

1
Roopesh Shenoy

Jadikan itu bagian dari proses Anda, saya menyebutnya "refactoring ekstrem" dan itu akan menjadi besar! ;) Lakukan saja dengan cepat dan ketika fitur baru yang cukup 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 mendesain dan berpikir tentang segala sesuatu di muka sebagian besar menipu diri sendiri, Anda (dan klien Anda) selalu belajar hal-hal saat Anda melanjutkan. 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 sebagian programmer untuk melakukan refactoring struktural yang lebih besar, dan semakin lama Anda menunggu semakin buruk.

1
Homde

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 menuntut terlalu banyak, biarkan pebisnis turun ke bawah dan siap untuk menggunakan "itu bisa dilakukan tetapi saya tidak yakin apakah itu sesuai 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 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.

1
Evan Plaice

Jawaban paling sederhana. Saya akan berhenti mengkodekan 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 sekarang, 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 cakupan 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, katakan pada 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 membuang waktu Anda, teruslah ubah pikiran. Lalu saya berhenti bekerja pada 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.

0
crosenblum

Dari perspektif lengkap proyek:

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

Dari perspektif dalam 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.

0
Kevin

Bunuh 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 seharusnya) menambahkan lebih banyak fitur sampai kode yang ada dapat dipertahankan, jika tidak itu akan membuatnya lebih sulit untuk men-debug kode masa depan.

0
wildpeaks

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.

0
duros

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.

0
chiurox