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


38

(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.)


1
Jika Anda memiliki pilihan, lihatlah produk JetBrains (Re-Sharper untuk C #, IntelliJ untuk Java, dan bahkan beberapa bahasa 'dinamis') yang dapat melakukan perubahan idiomatik proyek-lebar solusi, dengan investasi waktu yang sangat sedikit. (Ini juga dapat digunakan untuk secara interaktif mengajar junior apa yang idomatik. Tapi pastikan Anda dan mereka menyetujui pengaturan yang sama untuk proyek tersebut. (Dan pastikan Anda melakukan semua hal itu dalam komit terpisah, sehingga Anda tidak mencampur perubahan substantif dan kosmetik dalam komit yang sama),
David Bullock


2
Menerapkan panduan gaya / minimanual? Maksud saya, itu tidak akan membuat mereka menulis kode yang lebih baik , tetapi semua orang mampu mengikuti panduan yang mengharuskan untuk menulis hal-hal sepele dalam satu cara tertentu.
Peteris

10
Saya sudah melihat Anda memiliki masalah dengan kurangnya kerja tim di sini. Anda harus mendidik dan mengasuh junior; tidak hanya menulis ulang kodenya dan mengeluhkannya.
James

3
@Ramhound sejak Turing merancang Mesin Turing kurasa. Tapi kembali ke intinya, jika Anda adalah senior yang harus membuat junior untuk mendengarkan Anda. Ajari mereka cara melakukan hal yang benar (atau dalam kenyamanan). Tetapi penting untuk menanyakan pendapat mereka dan mungkin mereka memiliki beberapa ide untuk melakukan hal-hal itu dengan cara yang lebih baik. Juga jika Anda menggunakan CSS mentah untuk proyek non-sepele yang Anda lakukan salah, cobalah membuat proyek Anda untuk mengadopsi KURANG atau SASS.
Hoffmann

Jawaban:


79

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 100% setuju dengan Anda, namun saya bertanya-tanya bagaimana menerapkannya di hadapan tenggat waktu yang ketat. Apakah Anda menyarankan melakukan tinjauan kode meskipun mereka mungkin menyedot lebih banyak waktu terbatas kami yang berharga (baik dalam proses peninjauan maupun perbaikan yang dilakukan setelah peninjauan)?
Phil

3
Saya tidak berpikir bahwa anggota tim harus mengubah pekerjaan anggota tim lain tanpa kerjasama / persetujuannya. Orang yang menulis kode harus bertanggung jawab untuk itu, dan kecuali kode tersebut mengandung bug kritis dan penulis asli tidak tersedia, berada di jadwal yang ketat tidak ada alasan untuk mengubah kode orang lain. Jika Anda menemukan kode terlalu berantakan - komunikasikan dengan pengembang, dan katakan padanya untuk membersihkannya untuk rilis berikutnya.
Uri Agassi

23
@ Phil Ketika menghitung tenggat waktu, waktu untuk sesi peninjauan kode harus dipertimbangkan. Ini bukan langkah tambahan di atas proses devleopment - ini adalah bagian integral dari proses pengembangan.
dj18

2
Juga, melatih junior melalui tinjauan kode mungkin memiliki sejumlah biaya waktu sekarang (yang seperti kata DJ18 harus diperhitungkan dalam tenggat waktu dan perkiraan Anda), tetapi itu akan dilunasi pada waktunya berkali-kali karena membebaskan Anda untuk melakukan lebih banyak karya orisinal. Jika tenggat waktu Anda sangat ketat sehingga Anda tidak pernah memiliki kesempatan untuk melakukan ini, baunya bukan spiral kematian ...
Julia Hayward

2
@JustinPaulson jangan salah paham - fakta bahwa seseorang menulis beberapa kode, tidak menjadikan kode ini "miliknya". Seminggu kemudian, beberapa anggota tim lain akan mendapatkan tugas yang mengharuskannya untuk memodifikasi kode itu, dan dia pasti harus mengubah kode untuk kebutuhannya. Namun, saya tidak melihat kasus penggunaan di mana seseorang harus 'membersihkan' kode orang lain demi membersihkan, terutama bukan sebagai menit terakhir dalam tenggat waktu yang ketat.
Uri Agassi

29

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.


11
"jika ini adalah kode yang diuji maka Anda baru saja membatalkan semua upaya pengujian, dan perlu mengulangi pengujian." Tidak, Anda tidak membatalkan upaya pengujian apa pun. Anda hanya perlu menjalankan kembali tes, yang harus Anda lakukan untuk setiap komit. Jika itu memakan waktu begitu lama sehingga dianggap tidak layak, tes itu omong kosong dan harus diperbaiki.
l0b0

7
Perlu dicatat bahwa terus menulis kode ceroboh untuk "membuatnya berfungsi" akan menyebabkan bola lumpur besar . Tidak apa-apa jika itu pengecualian, dan bukan aturannya. Jika itu menjadi aturan, Anda harus berbicara dengan atasan Anda bahwa tenggat waktu bukan satu-satunya hal yang perlu dipertimbangkan.
Neil

20
Masalahnya adalah bahwa kode jelek cepat berubah menjadi kode yang rusak.
Telastyn

1
@ramhound - tentu saja, tetapi OP (dan hampir semua orang) tidak berbicara tentang kode yang hanya menggunakan standar lama - mereka berbicara tentang kode yang aneh, tidak konsisten, dan jelek.
Telastyn

1
@ JamesAnderson Ini adalah perspektif yang sangat pendek. Kode ditulis sekali tetapi dipelihara untuk seumur hidup produk. Kebanyakan pengkodean adalah refactoring. Berapa lama Anda benar-benar menuliskan kode pada layar kosong sebelum Anda kemudian men-tweak dan melihat apakah itu berjalan seperti yang diharapkan? Karenanya Anda refactoring, bahkan di jam pertama setelah memulai kelas baru. Biaya refactoring kode jelek dalam perbaikan bug dan peningkatan selanjutnya akan melebihi biaya sedikit waktu yang dihabiskan di depan dengan ulasan kode dan menggerakkan tim menuju satu standar yang jelas.
Scott Shipp

16
  • 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.


9

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!


Masalah dengan "kasus batas" adalah bahwa modul lain cenderung muncul yang menggunakan kode itu. Maka menjadi sangat berisiko untuk berubah karena modul-modul lain sekarang mungkin mengandalkan perilaku "salah / tidak diinginkan". Jadi Anda akhirnya terjebak dengan kode yang benar-benar sulit dipertahankan yang membuat Anda merasa ngeri setiap kali melihatnya dan membuat Anda ingin pergi ke tempat lain untuk pekerjaan. Minimal, kode yang buruk perlu ditutup oleh seseorang yang tahu apa yang mereka lakukan. Dengan begitu, bisa diperbaiki di lain waktu tanpa menimbulkan risiko sebanyak hanya meninggalkannya sampai seseorang punya waktu untuk menyiasatinya.
Dunk

6

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.


4

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.


3

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 telah bekerja untuk beberapa perusahaan besar yang sangat berorientasi pada proses yang bersedia mengeluarkan uang untuk memastikan standar dan praktik pengkodean terpenuhi. MEREKA TIDAK PERNAH ADA sampai alat otomatis mulai menegakkan mereka.
Dunk

@Dunk Apakah militer AS dianggap "besar dan berorientasi pada proses"? Mereka menggunakan S & Ps sepanjang waktu: stroustrup.com/JSF-AV-rules.pdf
Casey

Mereka tentu saja dianggap sebagai standar emas untuk standar pengkodean dan praktik. Setiap kontrak membutuhkannya. Namun, sekeras perusahaan berusaha untuk mematuhi standar dan praktik mereka, itu tidak terjadi dengan andal dan konsisten. Terlalu banyak yang terjadi. Itu sebabnya alat otomatis diperlukan jika Anda ingin memasukkan kata "harus" dalam saran Anda, seperti yang Anda lakukan. DOD mengakui ketidakmungkinan mematuhi standar melalui cara manual dan itulah sebabnya kongres mengeluarkan undang-undang pada 2011 yang mewajibkan kontraktor pertahanan untuk mulai menggunakan alat otomatis untuk melakukan pemeriksaan ini.
Dunk

BTW, saya tidak mengatakan bahwa tidak perlu pengkodean standar dan praktik. Benar-benar ada kebutuhan. Saya hanya memiliki pertentangan dengan bagian "semua karyawan harus mengikuti", kecuali jika Anda juga menyebutkan sesuatu tentang menegakkan ini melalui alat otomatis.
Dunk

@Dunk Tim JSF-AV pasti mengenali ini, dokumen tersebut secara khusus menyebutkan penggunaan alat otomatis sebagai cara untuk menegakkan S&P (kembali pada 2005)
Casey

2

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.


2

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.

2

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

1
Masalah dengan panduan gaya pengkodean adalah mereka cenderung berubah menjadi buku. Kebanyakan orang mau belajar dan mengikuti serangkaian aturan yang sederhana. Sayangnya, pada titik tertentu panduan ini selalu tumbuh melampaui kemampuan orang untuk belajar dan mengingat semua aturan. Anda memerlukan alat yang akan melakukan pemeriksaan gaya secara otomatis, titik. Ulasan kode tidak boleh untuk melakukan pemeriksaan tata bahasa, mereka harus untuk menemukan kesalahan dan kesalahpahaman.
Dunk

Sebagai programmer Python dan pemimpin tinjauan kode, saya telah mencetak PEP 8 dan panduan Gaya Python Google setidaknya selusin kali untuk diedarkan. Programer apa pun yang tidak akan belajar dari mereka akan menemukan diri mereka tertinggal dari mereka yang melakukannya. Yang mengatakan, saya setuju bahwa pemeriksa gaya juga merupakan praktik yang baik jika Anda bisa menerapkannya.
Aaron Hall

Saya tidak menggunakan Python, jadi saya tidak tahu alat yang tersedia, tetapi jika Anda mengandalkan ulasan kode untuk menegakkan aturan gaya Anda maka Anda membuang-buang ratusan (jika tidak ribuan) jam per tahun untuk sesuatu yang Anda bisa dilakukan untuk Anda tanpa biaya. Saya tentu saja tidak akan melanjutkan dan mengimplementasikan versi rumahan. Saya akan menghabiskan uang untuk membeli versi komersial yang akan menjadi WAY lebih baik daripada apa pun yang dapat dibuat sendiri di rumah. Bahkan alat mahal akan membayar sendiri berkali-kali lipat.
Dunk

Python, sebagai tumpah ruah open source, memiliki semua jenis alat gratis (pylint, pep8, pyflakes), beberapa di antaranya telah kami gabungkan dan tingkatkan, yang karena kami memiliki ribuan pengembang, benar-benar berskala dengan baik.
Aaron Hall

1
: Saya merujuk pada cuplikan "jika Anda dapat menerapkannya". Jika Anda bisa membeli pemeriksa gaya maka itu cara untuk pergi. Jika Anda dapat meminta tim Anda mengimplementasikan sesuatu yang bermanfaat seperti ini dalam waktu yang wajar maka harus ada perusahaan / sumber terbuka yang telah melakukannya. Jadi akan jauh lebih efektif dari segi biaya hanya dengan membelinya. Saya yakin ini akan lebih baik dan lebih baru daripada versi rumahan yang "tidak diproduksi". Jika Anda memiliki ribuan pengembang, maka saya sangat meremehkan jumlah tabungan yang disediakan alat pengecekan gaya / keamanan otomatis.
Dunk

2

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.


0

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.


0

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.


0

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 .

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.