Mengapa Paman Bob menyarankan agar standar pengkodean tidak dituliskan jika Anda dapat menghindarinya?
Jika Anda menanyakan alasan di balik pendapatnya, maka Anda mungkin memiliki jawaban hanya jika dia akan mengirim jawaban di sini ( pendapat kami tidak relevan), namun ...
Mengapa saya tidak menulis Standar Pengkodean?
Jika Anda bertanya apakah dia benar tentang hal itu: biarkan saya menjadi satu-satunya yang tidak populer (sejauh ini) untuk mengatakan bahwa Anda tidak punya alasan untuk menghindarinya.
MENULISKANNYA . Namun saya akan mencoba menjelaskan alasan saya ...
David menyarankan dalam komentar bahwa poin utama dari jawaban Stephen bukanlah mengapa Anda tidak harus menulis dokumen tetapi dalam bentuk apa mereka. Jika pedoman diformalkan dalam alat (bukan hanya tinjauan kode manual) maka saya dapat setuju (ketika hukum tidak mensyaratkan hal lain). Harap perhatikan bahwa sayangnya alat tidak dapat memeriksa semuanya (teori perhitungan bukan teman kami) sering karena mereka terbatas pada unit terjemahan atau paket tertentu atau apa pun bahasa favorit Anda yang disebut batas .
Namun kata-kata Paman Bob tidak membuat saya berpikir dia berbicara tentang itu.
Bisakah saya tidak setuju dengan pakar senior seperti itu? Saya lakukan, untuk hampir setiap poin dalam posting yang dikutip (lihat juga bagian kedua dari jawaban ini untuk perincian). Mari kita coba memahami mengapa (dengan asumsi Anda sudah tahu bahwa pedoman pengkodean bukan hanya tentang masalah format kecil ).
- Dalam beberapa keadaan, standar pengkodean tertulis diwajibkan oleh hukum.
- Saya membaca dokumentasi dan saya yakin saya tidak sendirian. Anggota tim dapat berubah seiring waktu, pengetahuan tidak dapat berada dalam basis kode 5-10 tahun atau dalam pikiran anggota tim. Organisasi harus memecat orang yang tidak mengikuti pedoman internal.
- Standar pengkodean, setelah disetujui , tidak akan sering berubah dan jika mereka ingin Anda mengetahuinya. Jika standar berubah maka dokumentasi Anda (dalam kode) kedaluwarsa karena semua kode Anda tidak mengikuti standar baru. Pemformatan ulang / refactoring mungkin lambat tetapi Anda selalu memiliki pedoman otoritatif tertulis untuk diikuti.
- Lebih baik membaca dokumen 5 halaman daripada memeriksa 10 / 20K LOC untuk memperkirakan aturan (yang mungkin Anda salah pahami, BTW), tidak diragukan lagi.
- Sungguh ironis bahwa seseorang yang menulis banyak buku tentang prinsip-prinsip desain dan gaya pengkodean menyarankan agar Anda tidak menulis pedoman Anda sendiri, bukankah lebih baik jika ia mencampakkan kita dengan beberapa contoh kode? Tidak, karena pedoman tertulis tidak hanya memberi tahu Anda apa yang harus dilakukan tetapi juga dua hal lain yang tidak memiliki kode: apa yang tidak boleh dilakukan dan alasan untuk melakukannya atau tidak.
"Free self-organizing programming" baik untuk seorang ninja berusia 16 tahun tetapi organisasi memiliki persyaratan lain :
- Kualitas kode harus diberikan (dan ditentukan) di tingkat perusahaan - itu bukan sesuatu yang bisa diputuskan oleh satu tim. Mereka bahkan mungkin tidak memiliki keterampilan untuk memutuskan mana yang lebih baik (berapa banyak pengembang, misalnya, memiliki semua keterampilan yang diperlukan untuk meninjau MISRA atau bahkan hanya memahami setiap aturan?)
- Anggota dapat dipindahkan di tim yang berbeda: jika semua orang mengikuti standar pengkodean yang sama maka integrasi menjadi lancar dan lebih sedikit rawan kesalahan.
- Jika sebuah tim mengorganisir diri sendiri maka standar akan berkembang seiring waktu ketika anggota tim berubah - Anda kemudian akan memiliki basis kode besar yang tidak mengikuti standar yang berlaku saat ini .
Jika Anda memikirkan orang sebelum proses maka saya hanya bisa menyarankan membaca tentang TPS: manusia adalah bagian utama Lean tetapi prosedurnya sangat formal.
Tentu saja organisasi kecil dengan hanya satu tim dapat membiarkan tim memutuskan standar untuk diadopsi tetapi kemudian harus ditulis. Di sini, di Programmers.SE Anda dapat membaca posting oleh Eric Lippert: Saya kira kita semua setuju dia adalah pengembang yang berpengalaman, ketika dia bekerja untuk Microsoft dia harus mematuhi pedoman tertulis mereka (bahkan jika beberapa aturan mungkin salah , tidak berlaku atau tidak berguna padanya.) Bagaimana dengan Jon Skeet? Pedoman Google sangat ketat (dan banyak orang tidak setuju dengan mereka) tetapi dia harus mematuhi pedoman tersebut. Apakah itu tidak sopan kepada mereka? Tidak, mereka mungkin bekerja untuk mendefinisikan dan meningkatkan pedoman tersebut, sebuah perusahaan tidak dibuat oleh satu anggota (atau satu tim) dan masing-masing tim bukan pulau .
Contohnya
- Anda memutuskan untuk tidak menggunakan beberapa kelas warisan dan bersarang di C ++ karena Anda anggota tim yang sebenarnya tidak memahaminya dengan baik . Kemudian seseorang yang ingin menggunakan multiple inheritence harus menelusuri seluruh 1M LOC untuk melihat apakah ia pernah digunakan. Itu buruk karena jika keputusan desain tidak didokumentasikan Anda harus mempelajari basis kode keseluruhan untuk memahaminya. Dan bahkan kemudian, jika belum digunakan, apakah itu karena itu melanggar standar pengkodean, atau apakah itu diizinkan, tetapi tidak ada situasi sebelumnya di mana banyak pewarisan cocok?
- Di C # Anda memiliki metode kelebihan untuk memberikan parameter default karena basis kode Anda dimulai ketika parameter opsional tidak tersedia di C #. Kemudian Anda berubah dan Anda mulai menggunakannya (refactoring kode lama untuk menggunakannya setiap kali Anda harus memodifikasi fungsi tersebut). Bahkan kemudian Anda memutuskan bahwa parameter opsional buruk dan Anda mulai menghindari menggunakannya. Apa aturan kode Anda memberi tahu Anda? Itu buruk karena standar berevolusi tetapi basis kode lebih lambat untuk berkembang dan jika itu dokumentasi Anda maka Anda dalam kesulitan.
- Jon pindah dari tim A ke tim B. Jon harus belajar standar baru; sambil belajar dia mungkin akan memperkenalkan bug yang lebih halus (atau, jika beruntung, hanya perlu waktu lama untuk memahami kode yang ada dan membuat ulasan kode lebih lama).
- Tim A pindah ke basis kode yang sebelumnya dimiliki oleh tim B. Ini memiliki standar pengkodean yang sama sekali berbeda. Menulis kembali? Menyesuaikan? Campuran? Semuanya sama-sama buruk.
Paman Bob
Biarkan mereka berkembang selama beberapa iterasi pertama.
Benar, sampai Anda tidak memiliki standar dan organisasi Anda memberi Anda tugas untuk membangunnya .
Biarkan mereka menjadi tim spesifik, bukan khusus perusahaan.
Tidak, untuk semua alasan yang dijelaskan di atas. Bahkan jika Anda berpikir untuk memformalkan pemformatan kode saja (hal yang paling tidak berguna yang mungkin ingin Anda formalkan), saya masih memiliki memori perang tanpa akhir (dan tidak berguna) tentang pemformatan. Saya tidak ingin menghidupkannya lagi dan lagi, atur sekali untuk semua.
Jangan menuliskannya jika Anda bisa menghindarinya. Alih-alih, biarkan kode menjadi cara standar ditangkap.
Tidak, untuk semua alasan yang dijelaskan di atas (tentu saja kecuali jika Anda akan memperbaiki semua kode Anda dalam sekali pakai ketika pedoman berubah). Apakah Anda ingin membiarkan kode apa adanya? Bagaimana Anda memeriksa basis kode untuk memahami pedoman saat ini ? Mencari berdasarkan usia file dan mengadaptasi gaya pengkodean Anda ke sumber usia file?
Jangan membuat undang-undang desain yang bagus. (mis. jangan bilang orang tidak menggunakan goto)
Benar, pedoman harus singkat atau tidak ada yang akan membacanya. Jangan ulangi yang sudah jelas.
Pastikan semua orang tahu bahwa standarnya adalah tentang komunikasi, dan tidak ada yang lain.
Tidak hanya, standar yang baik adalah tentang kualitas kecuali jika Anda ingin memiliki standar hanya tentang detail kecil .
Setelah beberapa iterasi pertama, buat tim bersama untuk memutuskan.
Lihat poin pertama dan jangan lupa bahwa standar pengkodean biasanya merupakan proses yang membutuhkan waktu bertahun-tahun untuk dikembangkan dan disempurnakan: beberapa iterasi, mungkin dengan pengembang junior? Benarkah? Apakah Anda ingin mengandalkan memori satu anggota senior (jika ada)?
Tiga catatan:
- Menurut pendapat saya kekurangan lebih serius dengan beberapa bahasa daripada yang lain, misalnya dalam C ++ standar tingkat perusahaan bahkan lebih dibutuhkan daripada di Jawa.
- Alasan ini mungkin tidak berlaku sepenuhnya (dan alasan Paman Bob mungkin tidak terlalu ekstrem ) jika Anda bekerja di perusahaan yang sangat kecil di mana Anda hanya memiliki satu tim kecil.
- Anda dipekerjakan (sebagai tim) dan Anda akan bekerja sendiri dengan satu proyek baru maka Anda akan melupakannya dan melanjutkan. Dalam hal ini Anda mungkin tidak peduli (tetapi majikan Anda harus ...)