Seberapa pentingkah untuk membersihkan kode orang lain ketika menghadapi tenggat waktu yang ketat? [Tutup]

(Saya berbicara tentang kode HTML / CSS (bukan bahasa pemrograman) tapi saya pikir kami juga menghadapi masalah yang sama dengan programmer.)

Saya adalah desainer senior front-end dalam sebuah tim dan saya sering harus mengerjakan kembali output junior saya dalam tenggat waktu yang ketat.

Saya dihadapkan dengan 2 masalah:

1. Gaya pengkodean mereka agak berantakan.
2. Estetika tidak bagus.

Gaya pengkodean mereka, menurut saya, adalah tas campuran tanpa konvensi / standar yang tepat. Saya terpecah antara membersihkan kode atau hanya berurusan dengan kode mereka (bahkan menyalin bagaimana mereka melakukan sesuatu).

Saya merasa frustrasi untuk mengikuti gaya pengkodean mereka karena saya merasa saya mungkin belajar kebiasaan buruk. Namun, itulah cara tercepat untuk memenuhi tenggat waktu.

Bagi mereka yang memiliki lebih banyak pengalaman, mana yang lebih efektif? Haruskah saya menyimpan pembersihan untuk nanti? Atau membersihkan sepanjang jalan saat saya melakukan perubahan?

(Aku tidak ingin terdengar sombong tapi kenyataannya begitu. Butuh waktu bertahun-tahun untuk menulis kode yang lebih baik. Aku tahu, aku menulis kode berantakan ketika aku mulai.)

Saya percaya Anda melihat masalah dengan cara yang salah - Anda kehilangan peluang besar untuk mengajar junior bagaimana menulis kode yang lebih baik.

Jika Anda terbiasa menulis ulang kode mereka, Anda mungkin memberi kesan kepada junior Anda bahwa Anda tidak menghargai pekerjaan mereka, yang akan menurunkan moral mereka, dan tidak membantu mereka membuat kode yang lebih baik di lain waktu.

Pendekatan yang lebih baik, saya yakin, adalah menambahkan proses review kode pada proses pengembangan tim Anda. Itu tidak harus tentang setiap bagian dari kode yang dikomit, dan tidak (saya berpendapat bahwa seharusnya tidak) harus dilakukan hanya oleh Anda - setiap kali anggota tim Anda menyelesaikan tugas yang cukup besar ia harus berpasangan dengan satu (atau lebih) rekan setimnya, menjelaskan kodenya kepada mereka, dan menerima pendapat dan kritik yang membangun tentang desainnya, gaya pengkodean, kemungkinan bug dan masalah keamanan, dll.

Ketika rekan setim peninjau kode adalah Anda, mereka akan belajar dari keahlian Anda lebih banyak daripada saat Anda hanya menulis ulang kode mereka (mereka mendapatkan kesempatan untuk mendengar alasan kode tersebut harus diubah), dan mungkin lebih sedikit tersinggung.

Memberi mereka kesempatan untuk juga melakukan tinjauan kode akan semakin meningkatkan kemampuan mereka - melihat bagaimana orang lain menulis kode dan mengapa - dan akan meningkatkan harga diri mereka.

Mereka juga akan belajar banyak jika Anda memberi mereka kesempatan untuk meninjau kode Anda . Anda mungkin belajar sesuatu juga - jadi jangan lakukan itu hanya untuk pertunjukan!

Saya telah mengatakan ini sebelumnya dan akan mengatakannya lagi "kode kerja lebih berharga daripada kode cantik".

Jika Anda mengubah kode kemungkinan besar bahwa Anda akan mengubah perilakunya, jika ini adalah kode yang diuji maka Anda baru saja membatalkan semua upaya pengujian, dan perlu mengulangi tes.

Dengan segala cara mendorong junior Anda untuk menulis kode bersih dimengerti, tetapi jika Anda akan menulis ulang semua yang mereka tulis maka Anda membuang-buang uang majikan Anda beberapa kali lipat. Mereka harus membayar untuk junior Anda, kemudian membayar Anda untuk melakukan apa yang telah mereka bayarkan untuk junior Anda, dan kemudian membayar Anda sekali lagi untuk melakukan pekerjaan yang sebenarnya mereka sewa untuk Anda.

• Jawaban singkatnya adalah: tidak. Ketika masa sulit, kadang-kadang Anda hanya perlu menundukkan kepala dan mengambil peluru estetika. ;)

• Jawaban yang lebih pragmatis adalah mengatur waktu. Anggaran satu jam untuk menjalankan dan membersihkan satu aspek spesifik dari kode. Kemudian periksa dan lakukan beberapa pekerjaan nyata. Tapi jujur ​​dengan diri sendiri tentang menjaganya agar tetap dibatasi.

• Namun, kadang-kadang, sedikit pembersihan membuat pekerjaan berjalan lebih cepat. Bahkan beberapa perubahan jenis pencarian dan ganti yang cepat membuat segalanya jauh lebih mudah diakses.

• Berhati-hatilah dengan perang gaya. Terutama dalam situasi tenggat waktu yang ketat, jika Anda akan membatalkan beberapa preferensi gaya yang hanya akan dilakukan ulang oleh programmer lain, maka sekali lagi Anda lebih baik menunggu sampai Anda punya waktu untuk benar-benar mengetahui bagaimana Anda ingin mengatasinya. masalah gaya secara kooperatif. (Yang berarti beberapa memberi dan menerima.)

Tapi ada nilai penilaian dalam jawabannya. Saya akan mengatakan "cukup" penting. Kode yang bersih benar-benar dapat membuat pekerjaan berjalan lebih cepat, dan kualitas kode, bagaimanapun, adalah bagian dari yang dapat disampaikan. Saya tidak berpikir saya bisa menyentuh kode (bahkan saya sendiri) tanpa menghabiskan waktu membersihkan. Tetapi pastikan bahwa sibuk dengan gaya dan format, dan perang gaya, tidak menjadi lebih penting daripada mendapatkan kode untuk produksi.

Saat memperbaiki kode, dan memiliki tenggat waktu, saya biasanya menggunakan dua aturan:

Kode ini buruk tetapi mungkin untuk menemukan masalah dalam waktu yang wajar dan memperbaikinya

Saya memperbaiki masalah dan membiarkan sisanya tetap utuh .

Kode ini sangat berantakan sehingga sangat sulit untuk menemukan masalah di sana. Memperbaiki sesuatu menyebabkan istirahat segera sesuatu yang lain. Mungkin akan lebih cepat untuk menulis kode itu dari awal daripada memperbaikinya.

Maka saya tidak punya pilihan selain menulis ulang / refactor sampai kode akan cukup bersih untuk melokalkan dan memperbaiki bug.

Kasus batas adalah:

Kode ini berantakan dan sangat buruk. Masih mungkin untuk memperbaiki bug dalam waktu yang wajar, tetapi struktur kode akan membuatnya sangat sulit untuk dipelihara. Setiap fitur baru sangat mungkin untuk memperkenalkan bug baru atau menyebabkan penurunan kinerja yang signifikan.

Dalam hal ini, kode harus diperbaiki, tetapi hanya ketika fitur baru diimplementasikan, selama waktu siaga, tidak pernah dalam waktu perbaikan bug dalam menghadapi tenggat waktu!

Saya akan tertarik untuk mengetahui pada titik mana dalam proses Anda Anda menemukan masalah ini?

Sebenarnya, di dunia ideal magis yang tidak kita huni ini, semua kode yang dipromosikan atau disebarkan harus sempurna. Tidak kadang-kadang Anda harus pragmatis.

Namun, jika Anda memiliki proses peninjauan kode, itu harus menyoroti ini sebelum pengujian. Jika Anda selalu menghadapi tenggat waktu, apakah masalah estimasi untuk pengiriman berarti bahwa komponen utama dari setiap proses pengembangan - yaitu - tinjauan kode - semakin dicekik?

Junior Anda tidak akan pernah belajar untuk duduk dan menyerap cara-cara yang lebih baik dalam melakukan sesuatu jika Anda tidak meluangkan waktu untuk menjadikannya bagian dari proses pengembangan mereka untuk belajar. Bagi saya sepertinya Anda tidak melakukan itu.

Tergantung pada budaya keseluruhan. Jika tenggat waktu yang ketat bersifat sporadis, terima Anda harus melakukan pembersihan nanti. Jika jumlahnya konstan, maka Anda secara struktural membangun utang teknis dan Anda harus menyelesaikan masalah dengan manajemen. Jika mereka tidak mengatasi masalah Anda, lebih baik mulai mencari peluang kerja lain karena budaya perusahaan kemungkinan besar akan segera bertemu dengan prinsip-prinsip Darwin.

Untuk membantu mengatasi masalah di masa depan, kembangkan dokumen Standar dan Praktik Pengkodean internal yang harus diikuti oleh semua karyawan.

Untuk kumpulan saat ini, bersihkan kode sesuai dengan dokumen S&P saat Anda membuat ulang kode tetapi hanya saat Anda melakukan refactor.

Saya cukup berpengalaman dengan pemrograman. Namun, sebagai mahasiswa, saya sering berkomitmen untuk melakukan peer review dan kemitraan pada proyek-proyek. Jika ada cukup waktu untuk menyelesaikan proyek, saya akan melanjutkan dan membersihkan kode anggota tim untuk kejelasan dan keterbacaan. Lebih sering daripada tidak, saya akan kesulitan bahkan untuk menyaring 100 baris pertama atau lebih. Dalam kasus ini, saya lebih dari bersedia untuk mengulurkan tangan untuk membantu mengajar sesama programmer kebiasaan dan pengkodean yang lebih baik. Jika tidak ada cukup waktu, saya cukup menyalin / menempel, dan mengerjakan proyek-proyek saya ke dalam gambaran besar berurusan dengan antarmuka yang buruk. Setelah itu, saya yakin akan menawarkan banyak saran tentang teknik pengkodean. Ketika datang ke peer review, kritik konstruktif (terlepas dari seberapa tidak disukai) hanya menguntungkan dirinya dan dia dalam jangka panjang.

Secara keseluruhan, jika Anda punya waktu luang, luangkan waktu untuk mengajari pendatang baru Anda cara melakukan pekerjaan mereka sehingga semua orang bermanfaat. Luangkan waktu sebentar dan ajari mereka apa yang berhasil bagi Anda, dan apa yang tidak. Jika Anda tidak punya waktu, telanjang dengan pekerjaan mereka untuk saat ini dan pastikan untuk kembali kepada mereka ketika Anda memiliki kesempatan. Biarkan mereka tahu bahwa ada cara yang lebih baik untuk melakukan sesuatu, terutama jika Anda akan bekerja dengan mereka di masa depan.

Meningkatkan kualitas keseluruhan jauh lebih unggul daripada menggunakan satu orang sebagai "filter" untuk grup yang lebih besar. Pada catatan itu:

• Pemrograman pasangan berfungsi seperti versi ulasan kode yang disempurnakan untuk memahami bagaimana mengembangkan - ini seperti perbedaan antara membaca dan melakukan, mengatakan dan menunjukkan. Menonton kode berkembang dan mendiskusikan perubahan dengan cepat sangat membantu untuk memahami tidak hanya bagaimana tetapi mengapa refactoring dan kode yang baik. Dalam pengalaman saya, ini lebih cepat daripada berkembang sendiri, karena ide-ide dilontarkan terus menerus, diakhiri dengan hasil kualitas yang lebih tinggi secara keseluruhan dan pemahaman yang lebih baik dari kode dan pemikiran orang lain.
• Alat Linting dapat memverifikasi bahwa gaya pengkodean sedang diikuti. Ini mengajarkan semua orang cara memformat kode, dan kesalahan akan cepat hilang setelah pengembang mengingat standar.
  • Jadikan ini bagian dari proses pembuatan untuk memastikan bahwa itu sudah diperbaiki sebelum melakukan.
  • Gunakan templat bahasa untuk memastikan bahwa CSS, HTML, JavaScript, dan kode sisi server Anda dapat diperiksa secara terpisah.
• Alat validasi dapat memeriksa apakah output yang dihasilkan waras. Ini juga harus menjadi bagian dari proses pembangunan.

Praktik terbaik adalah memiliki panduan gaya pengkodean, dan memiliki ulasan berkala, sehingga ketika Anda mendekati tenggat waktu, Anda tidak dihadapkan dengan masalah ini.

Rekomendasi saya adalah agar Anda menunjukkan kepemimpinan, dan mempelopori tinjauan kode reguler. Manajemen tidak didorong dari atas untuk memastikan bahwa ulasan kode reguler terjadi, tetapi pengalaman saya adalah bahwa mereka akan terkesan ketika seorang programmer meningkatkan jadwal dan mengadakan tinjauan kode reguler.

Ada banyak manfaat bagi karyawan Anda, yang akan:

• belajar gaya yang lebih baik
• ikuti praktik yang lebih baik
• belajar untuk meneliti apa yang mereka lakukan

Dan beberapa manfaat untuk diri sendiri, Anda akan:

• lebih efisien selama debit menit terakhir (yang akan selalu terjadi)
• diakui sebagai pakar dan pemimpin oleh tim dan manajemen Anda

Saya dapat melihat alasan dalam jawaban "jangan perbaiki apa yang berfungsi" dan "jangan buang waktu Anda untuk apa yang tidak penting bagi klien". PM khawatir tentang risiko dan ini baik-baik saja.

Saya juga mengerti kebanyakan orang tidak melakukan perbaikan dengan baik. Saya mengerti ini juga.

Mengatakan itu, saya percaya bahwa sebagian besar tenggat waktu adalah buatan. Sistem nyata hidup lebih dari tenggat waktu dan desain buruk yang Anda lakukan hari ini akan melawan Anda selamanya. Orang-orang berlari untuk mengirimkan sesuatu dalam beberapa bulan dan menghabiskan bertahun-tahun setelah ini memperbaiki beberapa keputusan buruk dalam suatu kode yang sedang dijalankan dalam produksi.

Utang teknologi adalah kata. Itu akan kembali suatu hari nanti dan seseorang akan membayarnya.

Jadi IMO, saya pikir Anda benar memperbaiki desain yang rusak, dan menjadi profesional (khusus untuk junior) juga berarti bahwa Anda harus tahu cara menerima kritik dan cara belajar dari itu, bahkan jika itu tidak sopan. Faktanya, sebagian besar kehidupan tidak sopan.

Setiap jawaban langsung akan menjadi ekstrem. Jelas ada kasus di mana tenggat waktu sangat ketat sehingga Anda harus menggunakan kode jelek, dan ada kasus di mana kode begitu jelek sehingga perlu melewati tenggat waktu untuk memperbaikinya. Yang Anda butuhkan adalah metode untuk menilai di mana Anda berada, dan mungkin metode untuk menetapkan tenggat waktu realistis yang memungkinkan waktu untuk menulis kode yang lebih baik.

Jangan simpan pembersihan untuk nanti. Kecuali jika Anda biasanya memiliki periode tanpa melakukan apa pun selain refactor, tidak ada "nanti" di mana ia akan menjadi prioritas lebih tinggi untuk merapikan kode daripada sekarang. Rutinnya adalah "merah, hijau, refactor", bukan "merah, hijau, lakukan sesuatu yang sama sekali berbeda selama dua minggu, refactor". Secara realistis Anda tidak akan mengubah kode sampai waktu berikutnya Anda mengunjungi lagi karena alasan lain, dan Anda mungkin akan berada pada tenggat waktu juga. Opsi nyata Anda adalah memperbaikinya sekarang atau meninggalkannya.

Tentu saja kode yang ditata dengan baik lebih baik daripada kode yang buruk, dengan asumsi Anda berencana untuk membacanya lagi. Jika Anda berencana untuk tidak membacanya lagi, maka jangan merapikannya . Kirimkan hal pertama yang lolos tes. Tapi itu skenario yang cukup langka, bagi kebanyakan programmer itu terjadi kira-kira tidak pernah. Mengabaikan kasus itu, hanya Anda yang memiliki perincian dari kasus Anda yang sebenarnya untuk membuat keputusan berapa biaya untuk memperbaiki vs berapa biayanya (dalam peningkatan pemeliharaan di masa mendatang) untuk tidak memperbaikinya.

Ada hal-hal tertentu yang tidak sulit untuk diperbaiki pada titik di mana kode membutuhkan pemeliharaan, daripada yang harus diperbaiki sekarang. Ini sebenarnya tidak menguntungkan Anda banyak untuk diperbaiki sekarang. Yang paling jelas adalah sepele untuk memperbaiki (kesalahan spasi dan sejenisnya) dan jadi sulit untuk membayangkan bahwa Anda punya waktu untuk mengajukan pertanyaan ini tetapi tidak untuk memperbaikinya ;-) Untuk itu yang tidak sepele dan dari jenis ini maka OK , Anda memiliki beberapa kode yang tidak ideal tetapi Anda harus pragmatis. Ini bekerja dan Anda berada di tenggat waktu. Gunakan.

Ada hal-hal tertentu yang jauh lebih mudah diperbaiki sekarang daripada nanti ketika (a) mereka tidak begitu segar dalam pikiran setiap orang; (B) hal-hal lain telah ditulis yang bergantung pada mereka atau meniru mereka. Ini jauh lebih berharga untuk diperbaiki sekarang, jadi prioritaskan. Jika Anda tidak punya waktu dalam tenggat waktu untuk memperbaikinya, maka Anda harus mendorong sekuat mungkin untuk tenggat waktu yang lebih lama, karena Anda menumpuk utang dalam basis kode Anda sehingga Anda mungkin harus membayar lain kali saat Anda mengunjungi Kode.

Metode perbaikan kode yang disukai adalah melalui proses peninjauan. Komentari masalah yang Anda miliki dengan itu, dan kirim kembali ke junior untuk berubah . Anda dapat memberikan contoh tentang apa yang Anda maksud dan meninggalkan junior untuk menemukan semua kasus dalam kode yang mereka terapkan, tetapi jangan hanya menyelesaikan kode mereka untuk mereka. Jika Anda melakukannya maka Anda memberi mereka tidak ada sarana untuk meningkatkan.

Anda harus menulis masalah umum menjadi panduan gaya yang mengatakan "jangan lakukan ini, lakukan ini sebagai gantinya", dan menjelaskan alasannya. Pada akhirnya alasannya adalah, "untuk membuat kode kita konsisten secara estetika", tetapi jika Anda tidak siap untuk menuliskan aturan Anda dengan beberapa pembenaran maka Anda mungkin juga tidak harus menegakkannya. Biarkan setiap programmer bebas memilih.

Akhirnya, waspadai kecenderungan untuk mengubah hal-hal tanpa batas. Pengembalian berkurang, dan Anda perlu belajar melalui pengalaman di mana mereka masih baik. Sangat penting bagi Anda untuk membentuk ide realistis tentang apa yang cukup baik, atau Anda tidak dapat melakukan negosiasi di mana Anda memastikan bahwa tenggat waktu Anda memberi Anda waktu untuk membuat kode "cukup baik". Luangkan waktu Anda untuk hal-hal yang tidak cukup baik.

Seperti yang telah dikatakan banyak orang sebelumnya, apa pun yang Anda lemparkan ke udara akan selalu turun kembali. Saya percaya pada keseragaman yang kuat di seluruh basis kode. Tentu saja beberapa hal tidak terlalu menjadi masalah. Penamaan konvensi pada variabel lokal dalam prosedur misalnya. Namun untuk apa pun yang struktural, itu harus segera diperbaiki, sebelum penggabungan akhir ke dalam bagasi utama. Mungkin hanya sedikit jelek ketika Anda melihat prosedur atau kelas individu, tetapi jika semua orang melakukan kode "sedikit jelek", itu sangat cepat menjadi sangat jelek secara keseluruhan.

Kode jelek yang berfungsi sering bekerja dengan baik 90% dari waktu tetapi berantakan di tepinya. Memastikan itu tidak biasanya cukup sederhana dengan mengikuti hanya beberapa aturan sederhana. Pertama, wajib bagi setiap programmer untuk mendefinisikan dan mendokumentasikan kendala yang tepat untuk setiap prosedur atau blok fungsional yang mereka hasilkan.

Kedua, untuk setiap prosedur harus ada tes terhadap kendala tersebut. Ini harus menjadi unit tes sederhana yang dapat (dan harus) dijalankan oleh programer secara lokal terhadap prosedurnya sebelum melakukan. Jelas ini lebih mudah untuk dikelola dengan suite pengujian yang tepat, tetapi bahkan tanpa tes harus ditulis, dan mungkin dilakukan dalam kelas parsial yang dapat dikecualikan dari build.

Ketiga, seperangkat lingkungan pengembangan standar dengan alat yang sudah dikonfigurasi sebelumnya sangat berharga. Server TS luar biasa untuk ini. Setiap orang memiliki alat yang persis sama (dan versi), konfigurasi yang sama, dan pembaruan yang sama. Instal alat refactoring seperti CodeRush atau Resharper, yang sudah dikonfigurasikan sebelumnya dengan standar Anda, dan beri tahu programmer Anda bahwa Anda akan menolak semua komitmen yang masih memiliki peringatan. Sekarang Anda dapat menggunakan waktu tinjauan kode tim Anda untuk benar-benar memperbaiki set aturan Anda dari umpan balik mereka, dan tim Anda dengan senang hati memperbaiki diri tanpa Anda harus terus-menerus membersihkannya setelah itu. Juga jauh lebih mudah bagi seorang programmer untuk mengambil kritik kode dari alat yang dikonfigurasikan dengan benar daripada dari seorang kolega atau bos, di mana standar mungkin tampak ditentukan secara sewenang-wenang atau tidak dipahami dengan baik. Jika IDE memberi tahu Anda bahwa kode Anda jelek, tidak ada yang akan membantahnya dan itu akan diperbaiki. Anda akan menemukan bahwa kualitas kode akan meningkat secara dramatis, dan tim secara keseluruhan akan menghabiskan waktu JAUH lebih sedikit refactoring dan pembersihan setelah beberapa minggu. Pemrogram juga akan terbiasa dengan aturan dan berhenti menulis kode omong kosong.

Terakhir, perbaikan sederhana di sini adalah memberi insentif kepada programmer untuk meningkatkan. Programmer secara kompetitif kompetitif. Semua orang ingin memiliki kode terbaik atau tercepat. Cara yang baik untuk memotivasi semua orang, meningkatkan produktivitas, dan membasmi yang tidak kompeten adalah dengan menghitung papan skor tertimbang mingguan untuk semua orang, mengambil poin untuk komitmen yang ditolak dan tenggat waktu yang rusak misalnya. Tunjukkan N teratas di pertemuan tim mingguan, bahkan mungkin membayar makan siang kepada siapa pun yang pertama dalam rata-rata bulan.

Saya sarankan menggunakan alat ulasan. Jika Anda memiliki repositori berbasis Git, Anda dapat menggunakan alat ulasan Gerrit . Setelah beberapa komitmen ditolak, tim akan mempelajari standar yang ingin Anda ikuti dan komitmen di masa depan tidak akan memerlukan pekerjaan tambahan dari Anda.

Komit akan menunggu penerimaan Anda. Jika Anda melihat baris apa pun yang harus ditulis ulang, Anda dapat menulis komentar dan rekan tim Anda dapat memperbaiki kode sendiri berdasarkan kebutuhan Anda. Ini benar-benar cara yang bagus untuk mempelajari standar pengkodean anggota tim .