Berurusan dengan rekan kerja yang tidak memiliki gaya pengkodean yang konsisten?

Apa yang Anda lakukan ketika Anda bekerja dengan seseorang yang cenderung menulis kode yang buruk gaya? Kode yang saya bicarakan biasanya secara teknis benar, cukup terstruktur, dan bahkan mungkin secara algoritmik elegan, tetapi hanya terlihat jelek . Kita punya:

• Campuran konvensi dan judul penamaan yang berbeda ( underscore_styledan camelCasedan UpperCameldan CAPSsemua diterapkan lebih atau kurang secara acak ke variabel yang berbeda dalam fungsi yang sama)
• Spasi yang aneh dan tidak konsisten, mis Functioncall (arg1 ,arg2,arg3 );
• Banyak kata yang salah eja dalam komentar dan nama variabel

Kami memiliki sistem peninjauan kode yang baik di tempat saya bekerja, jadi kami dapat memeriksa dan memperbaiki hal-hal terburuk. Namun, rasanya sangat sepele untuk mengirim ulasan kode yang terdiri dari 50 baris "Tambahkan spasi di sini. Eja 'itarator' dengan benar. Ubah huruf besar ini. Dll."

Bagaimana Anda mendorong orang ini untuk lebih berhati-hati dan konsisten dengan detail seperti ini?

Setuju pada konvensi pengkodean

Bahkan jika ini adalah satu pager. Saya menyarankan agar seluruh tim duduk dan semua setuju pada konvensi pengkodean kerja dasar yang dapat digunakan oleh seluruh tim.

Saya pikir Anda hanya harus terus melakukan apa yang Anda lakukan. Memiliki seperangkat pedoman pengkodean yang jelas, dan menegakkannya selama ulasan kode. Jika pengembang mendapatkan 50 atau 100 baris "Tambahkan spasi di sini" dan "Eja 'iterator' dengan benar" setiap kali ia mencoba memeriksa sesuatu, dan ia sebenarnya tidak diizinkan untuk check-in sebelum semua itu diperbaiki, akhirnya ia Anda harus mulai menulis kode pembersih hanya untuk menghindari kerepotan.

Saya pikir jika Anda memperbaiki hal-hal ini sendiri, seperti yang disarankan NimChimpsky, Anda akan membersihkan orang ini selamanya.

Saya memanggil BS pada semua orang yang mengatakan bahwa kesalahan ejaan nama variabel dan pemformatan tidak masalah. Jelas, mereka hanya membaca kode mereka sendiri. Dan perhatikan kata itu di sana - baca. Bayangkan membaca buku dengan banyak kesalahan ejaan, pemformatan mash, pemformatan garis yang tidak konsisten, dan berbagai kemalasan lainnya yang lazim dalam banyak kode sumber. Itu akan membosankan.

Untuk profesi di mana sintaks Anda harus 100% benar untuk bekerja, sama sekali tidak ada alasan bagi pengembang nyata untuk tidak memiliki gaya kode yang bersih dan konsisten. Yang lainnya adalah kecerobohan dan kemalasan. Saya selalu mempertanyakan kebenaran kode sembarangan diformat dalam implementasi.

Kami memiliki sistem peninjauan kode yang baik di tempat saya bekerja, jadi kami dapat memeriksa dan memperbaiki hal-hal terburuk. Namun, rasanya sangat sepele untuk mengirim ulasan kode yang terdiri dari 50 baris "Tambahkan spasi di sini. Eja 'itarator' dengan benar. Ubah huruf besar ini. Dll."

Saya akan mengubahnya sendiri dan kemudian menambahkan komentar sopan dalam kode.

ini mengasumsikan bahwa sudah ada panduan gaya seperti pertanyaan yang dinyatakan:

Kami memiliki sistem peninjauan kode yang baik

Jadi saran saya adalah pilihan terakhir, saya pikir itu cepat untuk mengubahnya sendiri dan meninggalkan komentar, seperti mengirim email atau apa pun.

Saya pikir konvensi seperti penamaan kelas dan variabel adalah penting dan harus diikuti melalui, kode yang elegan dan efisien juga, tetapi dengan risiko jawaban saya sering diabaikan, saya harus mengatakan bahwa secara umum paradigma "kode cantik" yang didorong banyak di dalam IMHO sangat berlebihan.

Pertama, pengembang yang menulisnya harus mempertahankannya di tempat pertama, dan jika dia pernah ditabrak bus dan programmer lain tidak dapat mengetahui cara kerjanya karena kode tersebut tidak "cantik", saya akan mengatakan bahwa pengembang lainnya tidak terlalu bagus. Dan ada banyak formatters / beautifiers otomatis di luar sana, jadi siapa pun dapat menggunakannya untuk mempercantik kode jika perlu, tanpa menghabiskan waktu sambil "dalam aliran" / "di zona".

Harap dicatat bahwa saya tidak menganjurkan pengkodean gaya spaghetti / koboi di sini, pada kenyataannya saya telah melihat beberapa kode spaghetti yang diformat dengan sangat baik (badan fungsi mencakup 4-5 layar, variabel global yang tersebar di berbagai file kode sumber yang berbeda, umumnya pilihan nama yang buruk , dll).

Salah satu kolega saya menulis html sedemikian rupa sehingga membuat kulit saya merangkak. Bayangkan html saya bagus dan terstruktur dengan dua indentasi ruang, diretas menjadi potongan-potongan dengan tag yang ditambahkan ke ujung tambang yang berakhir pada baris yang sama atau di sebelah seperti pemabuk yang perlu memeluk Anda agar tetap berdiri. Garis baru jarang dijorok tetapi jika ya, saya yakin ada beberapa lubang hitam yang sangat kacau di beberapa bagian galaksi yang memuntahkan nilai suhu tidak rasional sedemikian rupa sehingga entah bagaimana digit-nya mencerminkan jumlah ruang atau tab yang digunakan dalam lekukan seperti itu. oleh wanita ini. Jika saya beruntung, saya akan melihat tag input yang ditutup dengan " </input>". Total mimpi buruk yang bisa kau mengerti.

Sepertinya tidak ada yang memahami hal ini, melihat bagaimana bagi kebanyakan petinggi di sini, kode yang terorganisasi atau kode yang tidak terorganisir kepada mereka adalah seperti perbedaan antara kita meletakkan keju swiss atau keju Amerika di sandwich kita, yang bisa dikatakan, mereka benar-benar tidak peduli. Saya mulai membiarkannya meluncur karena saya stres dengan proyek lain, dan saya pikir dia mulai menyadari betapa sulitnya memahami kode seperti itu sebelum dia ingin meningkatkan. Saran saya adalah untuk mendemonstrasikan mengapa lebih baik mendesain kode Anda lebih dari sekadar menyuruh mereka melakukannya.

Kode yang saya bicarakan biasanya secara teknis benar, cukup terstruktur, dan bahkan mungkin secara algoritmik elegan ...

Berbahagialah karena Anda mendapatkan semua itu. Sebagian besar programmer mungkin akan memberi Anda hal pertama dalam daftar itu. Saya pikir penamaan variabel dan spasi adalah hal yang paling tidak penting untuk dikhawatirkan.

Sepertinya Anda perlu mengatur dan menyetujui konvensi gaya. Jika tidak, Anda akan memiliki perpustakaan yang memiliki 3 indentasi ruang, yang lain memiliki 4, beberapa yang menggunakan Casing Unta dan lainnya yang menggunakan underscore_case.

Apakah perubahan yang Anda ingin buat preferensi pribadi Anda atau apakah Anda memiliki standar aktual untuk diikuti? Jika Anda tidak memiliki standar aktual, maka jangan lakukan ini. Pertama-tama tentukan standar. Kemudian Anda bisa mendapatkan perangkat lunak yang dapat diatur untuk refactor kode ke pengaturan standar (setidaknya beberapa hal).

Jika Anda memiliki standar, mulailah menerapkannya dalam tinjauan kode. Tidak ada gunanya memiliki standar jika Anda tidak menegakkannya dalam tinjauan kode. Ini akan berarti banyak pekerjaan tambahan dalam pemeliharaan karena orang harus memperbaiki kode lama yang tidak memenuhi standar pada awalnya ketika mereka menyentuhnya.

Bahkan tanpa standar, bersikeras memperbaiki kesalahan ejaan dalam nama variabel (saya tidak akan terlalu khawatir tentang komentar) karena mereka akan membuat semua orang yang menyentuh kode gila selamanya.

Standar pengkodean perlu diidentifikasi sehingga semua orang tahu apa itu dan kemudian mereka perlu ditegakkan. Harus ada konsekuensi untuk tidak mengikuti aturan.

Berikut adalah hal-hal yang harus memberikan insentif:

1. Ulasan kode akan membosankan dan lebih lama dari yang diperlukan.
2. Kode akan ditolak lebih sering.
3. Jadwal tidak akan dipenuhi.

Jika orang ini tidak perlu khawatir tentang ini karena tidak ada yang menegakkan aturan Anda atau mereka tidak peduli jika mereka tidak produktif (dan tidak ada yang melakukan apa-apa tentang itu), tidak banyak yang dapat Anda lakukan tentang hal itu.

Saya akan tergoda untuk menyarankan melakukan obrolan pribadi dan melihat apakah Anda berdua dapat menemukan penyebab utama:

1. Apakah rekan kerja itu terburu-buru dan karena seseorang menginginkan kode kemarin orang tersebut berusaha mendapatkan sesuatu yang bekerja secepat mungkin? Ini bisa menjadi kesempatan untuk memberi tahu orang ini untuk lebih fokus pada kualitas daripada kecepatan dalam pekerjaan mereka. Mantra seperti, "Luangkan waktu Anda," bisa berguna jika ini tidak produktif.

2. Bagaimana orang tersebut melihat pekerjaan mereka? Jika ada rasa bangga, maka Anda mungkin memiliki sudut untuk menggunakannya untuk meningkatkannya. Jika itu hanya pekerjaan yang membayar tagihan, mungkin akan jauh lebih sulit untuk mendapatkan perubahan. Apakah mereka tahu mereka tidak melakukan pekerjaan dengan baik tetapi sangat dekat dengan itu?

3. Apakah orang ini tidak setuju dengan konvensi dan mencoba untuk memprotes? Jika demikian, maka Anda mungkin memiliki masalah besar, tetapi ini layak untuk mencari tahu apakah ini masalahnya atau apakah orang itu hanya malas? Jenis motivasi apa yang mungkin berguna di sini, misalnya Anda dapat menarik minat pada keserakahan, kebanggaan, atau sifat buruk lainnya untuk membuat orang tersebut meningkat. Ini licik tetapi mungkin efektif jika mencoba rute pria baik tidak mendapatkan apa-apa.

4. Cara Memenangkan Teman dan Mempengaruhi Orang memiliki beberapa saran dalam hal persuasif yang mungkin berhasil, seperti memuji peningkatan dan memberi orang reputasi yang baik untuk ditegakkan.

Adapun mengapa ini harus dilakukan secara pribadi, berikut adalah beberapa alasan:

1. Ada peluang bagus untuk dipermalukan, dikritik atau tidak menyenangkan lainnya yang lebih baik disimpan di belakang pintu daripada ditinggalkan di tempat terbuka di mana seseorang mungkin merasa karakter mereka sedang dibunuh.

2. Anda ingin mendorong orang lain ini untuk sedikit terbuka. Sebuah tantangan di sini adalah bahwa beberapa orang sangat dijaga sehingga butuh waktu lama untuk membuat mereka merobohkan tembok mereka.

3. Jika memungkinkan, saya sarankan mencoba melakukan ini agak jauh dari kantor. Pergi keluar untuk makan siang, berjalan-jalan, atau melakukan sesuatu agar lingkungannya cukup diubah sehingga orang tersebut mungkin merasa sedikit lebih nyaman. Ini bisa menjadi tantangan dan membutuhkan mengenal orang itu, tetapi idenya di sini adalah bahwa di kantor beberapa orang akan mengenakan topeng kerja yang sepertinya tidak akan membantu di sini.

4. Bersiaplah untuk percakapan yang agak panas atau jelek, tapi ini bisa menjadi pertanda baik jika Anda bisa membuat orang lain terlibat dan berdialog dengan baik. Beberapa orang suka menjaga hal-hal di tempat terbuka dan yang lain mungkin lebih suka cara yang lebih halus untuk menyelesaikan sesuatu. Kuncinya adalah memastikan Anda mendengarkan orang lain cukup untuk berempati dan mencoba memahami sisi mereka.

Kami memiliki tes JUnit yang mencari masalah pemformatan. Ini berjalan sebagai bagian dari build. Saya terus mendapatkan sedikit dengan menghilangkan spasi antara if, while atau for dan tanda kurung buka. Kode kami diformat secara konsisten.

http://code.google.com/p/kawala/wiki/BadCodeSnippetsRunner

Keindahan kode seperti unscrutify akan dapat menyelesaikan beberapa masalah Anda. Jika Anda siap membayar untuk ini maka ada perangkat lunak tingkat tinggi yang menyematkan aturan dalam kode sumber itu sendiri seperti Parasoft . Parasoft membuatnya wajib untuk menulis kode dengan gaya seragam. Anda dapat menanamkan aturan Anda sendiri juga. Ketika alat tersebut digunakan, para pengembang dipaksa untuk menggunakan gaya seragam. Dan setelah beberapa saat mereka akan terbiasa.

Jika Anda menggunakan Eclipse, maka aktifkan Simpan Tindakan untuk Editor Java, dan beri tahu semua orang untuk menggunakannya. Ini memperbaiki masalah pemformatan pada setiap penyimpanan, tetapi tidak memperbaiki permodalan yang buruk. Mungkin akan sangat membantu!

Seberapa sulit untuk mengikuti konvensi gaya? Saya mengerti kesalahan ejaan tetapi sisanya adalah indikator pemikiran dan pengkodean yang ceroboh. Katakan kepada orang itu bahwa mereka harus lebih konsisten ketika datang ke kode produksi karena mereka bukan satu-satunya yang akan melihatnya. Benar-benar kasar, egois, dan tidak peduli untuk menulis kode produksi dengan gaya yang tidak konsisten.

LOL. Anda benar-benar akan membenci kode saya. Saya tidak bisa mengeja untuk menyelamatkan hidup saya dan saya tidak peduli.

Tetapi saya tahu beberapa orang benar-benar peduli tentang hal-hal itu.

Saya sarankan Anda memecat orang yang menulis kode jelek jika mereka tidak berubah kemudian menemukan seseorang yang membuat semuanya benar-benar cantik dan berharap mereka dapat menulis kode yang

biasanya secara teknis benar, terstruktur secara wajar, dan bahkan secara algoritmik elegan

dan jika mereka tidak bisa maka setidaknya Anda dapat menunjukkan kode cantik rusak kepada pelanggan dan menjualnya!

Tapi serius. Fokus pada hal-hal yang sebenarnya penting terlebih dahulu. Jika Anda tidak dapat menemukan alasan yang bagus dan kuat di luar "itu menyakitkan kepekaan halus saya" maka abaikan saja untuk saat ini. Jika itu penting, maka duduklah bersama orang tersebut dan yakinkan mereka akan pentingnya itu. Hal-hal seperti standar yang memudahkan untuk membedakan antara tingkat kelas, tingkat metode, berbagi, variabel konstan membuat perbedaan. Jika pembuat kode yang bersangkutan sama sekali peduli dengan profesinya, mereka akan memahami dan mencoba melakukan hal yang benar.

Solusi saya ketika berurusan dengan sumber daya outsourcing yang tidak memberikan &% $ # tentang pembentukan (atau bug yang dapat dicegah dengan mudah dalam hal ini) adalah membuat server build memberlakukan ini. Saya membuat pekerjaan server CI yang dijalankan setiap malam yang memeriksa kode, menjalankan Jalopy dan findbugs kemudian memeriksa kode kembali. Setelah tim lain mengetahui bahwa tidak menggunakan konvensi kode standar akan membuat pekerjaan mereka lebih sulit, mereka mulai menggunakan IDE untuk mempertahankan format standar.