Bagaimana dengan semua aturan pengkodean itu?


10

Saya selalu mendukung gagasan memiliki aturan pengkodean untuk pengembang di perusahaan atau proyek tertentu. Apalagi jika ukuran perusahaan lebih besar dari 10. Semakin besar perusahaan semakin besar kebutuhan. Saya tahu banyak orang akan tidak setuju, tetapi saya telah melihat proyek yang tidak memilikinya dan kode ini terlihat seperti bencana total.

Masalah sebenarnya yang datang dari ini adalah bagaimana membuat mereka yang keras kepala yang tidak suka menggunakan tanda kurung di dalam pernyataan, atau menggunakan string koneksi yang sama di mana-mana dalam kode, atau apa pun, untuk menggunakan aturan pengkodean tanpa membuat mereka menentang ide?


3
Jika Anda menggunakan C # sebagai bahasa, maka gunakan StyleCop. If using Java ...
Job

@ Pekerjaan - Ya, kami kebanyakan menggunakan C #. StyleCop terlihat menarik.
TheBoyan

Jawaban:


9

Libatkan mereka dalam memperbaiki masalah alih-alih melawan aturan. Saya pribadi lebih suka ide "panduan gaya", "standar pengkodean" atau sesuatu yang serupa, dengan harapan dapat mencegah reaksi "aturan = buruk".

Tetapi bahkan jika itu terjadi - saya cenderung berpikir bahwa aturan itu ada karena suatu alasan, dan cara untuk membuat orang berkepala keras berbalik adalah untuk membuat mereka menyadari bahwa dengan mengikuti pedoman, mereka membantu membuat kode lebih mudah untuk baca untuk semua orang.

Terkadang tekanan teman sebaya adalah solusi terbaik untuk ini.


Bermain advokat iblis di sini, selalu mungkin bagi aturan untuk menjadi salah (misalnya, ada sesuatu yang dilakukan untuk proyek masa lalu tetapi merupakan beban bagi pengembang pada proyek saat ini) - sehingga memiliki aturan meninjau / mencabut proses - bahkan jika itu jarang digunakan - juga dapat membantu meyakinkan orang bahwa aturan tersebut adalah pedoman yang bermanfaat daripada pengenaan kebebasan pengembang.
Beekguk

Tentu saja - dan saya pikir jika Anda tetap dengan saran untuk fokus pada mengapa Anda membutuhkan aturan, maka jika Anda tahu Anda tidak memerlukan aturan, Anda tahu tim atau orang yang datang dari itu dengan pola pikir yang terbuka, daripada hanya menjadi defensif karena proses aturan yang tidak bisa dijelaskan.
bethlakshmi

6

Di pekerjaan saya, kami menggunakan ketiga solusi berikut:

1) Mengadopsi pemeriksa gaya kode seperti Checkstyle yang sangat baik (untuk Java) atau StyleCop (untuk C #). Ini adalah alat yang mudah dikonfigurasi yang dapat secara otomatis menyoroti penyimpangan gaya / aturan koding. Ini memberi semua orang pihak ketiga yang netral untuk menentukan apa yang bisa dan tidak bisa diterima.

2) Mengadopsi templat kode memformat simpan otomatis (inilah contoh menggunakan Eclipse) (dan yang lain untuk Visual Studio) yang akan secara otomatis memformat kode Anda saat disimpan. Ini bagus untuk memungkinkan seseorang untuk kode sesuai keinginan mereka, tetapi memiliki semua kode diformat dengan cara yang sama pada save / commit. Saya sangat suka yang ini dan kode kami tidak pernah lebih konsisten.

3) Ulasan kode. Semoga Anda tetap melakukan ini, tetapi satu hal yang harus disorot adalah di mana aturan pengkodean / gaya melanggar konvensi.

Selain hal di atas, penting bahwa setiap orang berada di kapal yang sama dan telah menyetujui gaya / aturan yang sedang mereka upayakan. Jelaskan bahwa Anda tidak akan mendapatkan persetujuan dari semua orang dalam segala hal, tetapi mintalah komitmen dari tim untuk berpegang teguh pada apa yang diputuskan tim. Pastikan untuk sesekali meninjau gaya / aturan yang dipilih untuk menjelaskan pengalaman dunia nyata menggunakannya dan pergantian tim.


Anda dapat mengonfigurasi beberapa sistem kontrol revisi untuk memberlakukan hal-hal seperti Checkstyle saat check-in. Jika Anda melakukannya, mulailah dengan aturan paling kritis dan tambahkan aturan pemilih nanti.
BillThor

4

Masalah sebenarnya yang berasal dari ini adalah bagaimana membuat mereka yang keras kepala yang tidak suka menggunakan tanda kurung dalam pernyataan if, atau menggunakan string koneksi yang sama di mana pun dalam kode, atau apa pun,

Apakah mereka "keras kepala" dengan tidak menggunakan tanda kurung atau ini permintaan "keras kepala"?

Pilih pertempuran Anda. Saya ragu ini adalah salah satu yang layak dipetik. Saya tidak akan menikmati bekerja di mana pun yang diharapkan mendekati tingkat detail ini pada "kode masuk pertama". Ini adalah indikator bendera merah bahwa tim tidak memahami refactoring.

OO 101 : "Refactor ketika produk melakukan apa yang perlu dilakukan". Tidak sebelum.


Kurung yang tidak menggunakan hanyalah contoh :) walaupun saya telah bekerja untuk perusahaan besar yang memiliki buku> 200 halaman aturan pengkodean dan ini adalah salah satunya. Ngomong-ngomong, saya yakin Anda akan setuju dengan saya bahwa seseorang yang sengaja menggunakan string koneksi yang sama (contoh lagi) berulang-ulang dalam kode hanya karena dia terlalu malas untuk meletakkannya di file konfigurasi dan membaca dari sana, perlu perhatian dan orang perlu tahu bagaimana menghadapi situasi semacam ini.
TheBoyan

2

Cukup sulit untuk duduk di pundak setiap pengembang tunggal dalam tim besar, memastikan mereka menempatkan penyangga di mana Anda pikir mereka harus pergi - percayalah pada yang satu itu;).

Jika itu sesuatu yang Anda benar-benar rasakan menghambat perkembangan Anda, maka Anda akan membutuhkan "penjaga gerbang". Jangan biarkan orang-orang check-in tanpa ulasan kode misalnya. Mintalah arsitek teknis atau pemimpin tim untuk meninjau kode dan menolaknya sampai mereka "memperbaiki" gaya kode. Mereka akan segera bosan dengan ini dan menyesuaikan dengan aturan, meskipun, mungkin hanya selama mereka diperiksa.

Tentu saja, beberapa perusahaan mengambil hak akses masuk sepenuhnya dari programmer junior. Ketika mereka akhirnya mempelajari aturan pengkodean perusahaan, maka mereka mendapatkan hak istimewa.


2
Jika penempatan brace adalah masalah kualitas terbesar Anda, saya kira Anda cukup beruntung. Apakah itu level yang tepat untuk fokus?
Bo Persson

Contoh murni diambil dari pertanyaan. Prinsipnya adalah bahwa desain kode "pedoman" seperti bethlakshmi mengatakan di bawah ini, hanya itu - pedoman. Jika Anda benar-benar khawatir tentang bagaimana mereka diikuti, maka poin-poin dalam proses tersebut perlu terjadi untuk mengingatkan / mengajar / menegakkan mereka.
Martin Blore

Tapi bersiap di mana Anda pikir mereka harus pergi ... Itu berbicara banyak. Saya pikir ada aspek yang lebih mendasar dari standar pembacaan pengkodean / pengkodean kemudian penempatan brace. Saya setuju semua orang di proyek harus mengikuti standar yang sama tetapi satu di atas yang lain tidak terlalu berarti di sini. Mungkin Anda bisa membiarkan mereka "memenangkan" pertempuran penempatan penjepit dengan imbalan bagi mereka menerima saran Anda yang lain tentang standar pengkodean? Tidak hanya itu tetapi mereka akan merasa menjadi bagian dari solusi jika ide mereka tentang penempatan kawat gigi ada dalam standar.
Gilles

1
Persis. Saya menyerah mencoba membujuk pengembang untuk melakukan tanda kurung pada baris mereka sendiri, bukan tanda kurung inline, dengan imbalan dia belajar SOLID dan TDD ... perdagangan yang bagus, saya akan mengatakan;).
Martin Blore

1
"Tentu saja, beberapa perusahaan merampas hak istimewa check-in sepenuhnya dari programmer junior. Ketika mereka akhirnya mempelajari aturan-aturan pengkodean perusahaan, maka mereka mendapatkan hak istimewa." - ini adalah satu-satunya cara untuk melakukannya ketika itu penting.
ocodo

2

Saya pikir Anda berbicara tentang masalah pada tingkat yang sangat berbeda:

bagaimana membuat orang-orang yang keras kepala yang tidak suka menggunakan tanda kurung jika pernyataan,

Itu sebagian besar masalah gaya / keterbacaan, kecuali ada masalah prioritas operator yang diutamakan. Yang terakhir seharusnya tidak terlalu umum, dan masih dapat diuji unitnya, sehingga mudah untuk diperbaiki. Yang pertama dapat dengan mudah mundur ke dalam Perang Suci dengan sedikit untuk mendapatkan, tetapi konsekuensi negatif yang parah terhadap semangat tim. Jadi berhati-hatilah - hanya push yang mencoba dan menguji aturan, yang telah diterima oleh setidaknya beberapa tim / komunitas dan terbukti berhasil.

atau gunakan string koneksi yang sama di mana pun dalam kode,

Jika yang Anda maksud adalah Magic Constants, itu memang masalah pemeliharaan (plus berpotensi keamanan), dan dengan demikian IMHO, pengembang berpengalaman mana pun akan memahami dan menerima bahwa itu adalah Masalah Buruk.

atau apa pun, untuk menggunakan aturan pengkodean tanpa membuat mereka menentang gagasan itu?

Anda tidak dapat memaksa orang untuk setuju dengan aturan pengkodean apa pun - satu-satunya kesempatan Anda adalah mencapai pemahaman bersama dan persetujuan dari anggota tim melalui diskusi dan (kadang-kadang sengit) debat . Anda perlu menggunakan argumen logis dan meyakinkan , menunjukkan nilai di balik setiap aturan, dan menjelaskan bagaimana mengikuti akan membayar untuk ketidaknyamanan menyesuaikan kebiasaan yang sudah tertanam. Di sisi lain, berusaha untuk membuat transisi semudah mungkin , dengan misalnya memperkenalkan pemformatan kode otomatis saat check-in, sesuai dengan aturan yang berlaku.

Namun, kadang-kadang Anda hanya perlu menerima bahwa orang memiliki pendapat yang berbeda , sehingga aturan pengkodean yang dapat diterima setiap orang akan lebih lunak dalam hal tertentu. Terima itu dan fokuslah pada bidang-bidang di mana Anda dapat meningkatkan hal-hal dengan sedikit usaha.


"memperkenalkan pemformatan kode otomatis pada saat check-in, sesuai dengan aturan yang diterima" ... ini terdengar menarik, ada ide lebih lanjut di mana saya dapat menemukan sesuatu seperti ini.
TheBoyan

@ bojanskr, sebagian besar IDE arus utama saat ini mendukung aturan pemformatan kode pada tingkat yang lebih rendah atau lebih besar, dan dapat mengatur otomatis kode Anda saat simpan atau checkin. Untuk Java, seperti yang dilakukan Eclipse dan IntelliJ, saya kira NetBeans juga, tapi saya belum punya banyak pengalaman dengannya. Untuk C #, lihat komentar @ Job di atas. Tetapi ada juga alat yang berdiri sendiri, seperti Gaya Artistik untuk C / C ++. Dan sebagian besar SCC yang saya tahu mendukung eksekusi skrip / pemicu khusus pengguna di mis. Checkin.
Péter Török

2

Libatkan mereka dalam membuat aturan. Ini biasanya membantu mendorong orang untuk mengikuti mereka.


1

Inilah tujuan dari tinjauan kode. Peninjau kode tidak boleh membiarkan kode lulus yang tidak memenuhi standar. Pastikan untuk tidak mengendurkan aturan untuk perbaikan yang mendesak. Harus mengulang beberapa kali di bawah tekanan untuk menyelesaikannya akan memperbaiki mereka yang enggan untuk melakukan pekerjaan mereka dengan benar pertama kali.


1

String koneksi yang sama di mana-mana? Solusi untuk itu adalah melakukan refactor hingga Anda telah menghapus semua duplikasi. Copy-paste coders harus masuk ke penjara programmer. (Jangan tertawa! Steve Ballmer adalah sipir.)

Tapi masalah sebenarnya di sini adalah kata kerja "make" Anda . Anda tidak dapat membuat programmer melakukan apa pun, dan jika Anda melakukannya, Anda menyia-nyiakan karakteristik mereka yang paling berharga: keterlibatan intelektual yang dalam yang berasal dari mengerjakan sesuatu yang Anda pedulikan.

Cara saya menyelesaikannya:

  1. Bersikeras bahwa tim memiliki standar pengkodean yang sama. Panjangnya bisa 5 baris, tetapi mereka semua harus setuju.
  2. Setiap kali Anda melihat argumen bersikeras mereka menyelesaikannya bersama dan memasukkannya ke dalam standar pengkodean. Jika Anda melihat orang memformat ulang dan mundur, anggap itu sebagai argumen.
  3. Setiap kali item standar disetujui, lihat apakah ada alat yang akan membersihkan seluruh basis kode sekaligus.
  4. Setiap beberapa bulan, pelajari standar pengkodean dan lihat mana yang masih benar dan relevan. Standar hanya mendokumentasikan apa yang dilakukan orang. Dan tidak ada gunanya menyimpan item dalam standar yang sudah jelas.

Pemrograman adalah olahraga tim, atau karya artistik kolektif. Apa yang disepakati orang tidak terlalu penting seperti yang mereka sepakati, dan pandai mencapai kesepakatan baru jika diperlukan.

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.