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


30

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?


2
Bantuan "Printer cantik". Juga, apakah perusahaan Anda memiliki panduan gaya?
chrisaycock

1
bagaimana dengan rekan kerja yang tidak memiliki tata bahasa? ;)
Muad'Dib

4
@JSBangs: instal pemeriksa gaya pra-komit dan minta ditolak. Itu akan membuat mereka memformat dengan benar dengan cepat. Atau minta kait pra-komit menjalankan formatter untuk Anda. Beberapa hal akan terlihat tetapi lebih baik daripada yang aneh lebih baik daripada "mengerikan" kurasa.
haylem

3
Satu lagi pemikiran - ini mungkin tampak remeh, tetapi picik untuk suatu tujuan (dengan asumsi bahwa a) ada standar pengkodean dan bahwa b) semua orang setuju dan menganutnya)
Murph

3
Apa latar belakang programmer ini? Kedengarannya dia bekerja untuk banyak perusahaan yang berbeda dengan terlalu banyak konvensi pemformatan kode yang berbeda, dan otaknya telah menginternalisasi semuanya menjadi berantakan. :-)
Carson63000

Jawaban:


19

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.


1
Tentu saja - maka a) semua orang berusaha untuk mencapai standar yang sama dan tahu apa itu dan b) penolakan Anda pada tinjauan kode dapat dikurangi menjadi "gagal mematuhi standar pengkodean" (setidaknya jika file secara keseluruhan adalah berantakan - jika hanya satu atau dua hal yang Anda harus spesifik)
Murph

Biasanya saya belum pernah melihat tim yang mengelola untuk "setuju" dalam satu jam pada konvensi pengkodean sepenuhnya untuk bahasa apa pun :) Tetapi jika dengan setuju Anda maksudkan "diskusikan sampai ketidaksepakatan, dan kemudian paksakan dengan pangkat dan wewenang", maka itu bekerja. Anda harus meletakkan beberapa poin karena Anda tidak akan menemukan konsensus, atau Anda sangat beruntung dengan tim Anda.
haylem

28

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.


5

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.


4

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.


10
Itu menjadi sangat cepat.
Robert Harvey

3
Mungkin lebih cepat bagi Anda daripada mengirim email, dan lebih cepat secara keseluruhan untuk mengatasi masalah, tetapi lebih lambat daripada jika masalahnya tidak terjadi sejak awal.
haylem

4

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


Apa yang Anda katakan tentang kode seperti ini: stackoverflow.com/questions/6221098/save-mapview-as-a-bitmap/... Apakah Anda masih berpikir bahwa programmer yang telah menangani "style" ini adalah programmer yang buruk jika ia punya masalah serius dengan itu?
WarrenFaith

@ WarrenFaith, Anda mungkin ingin mengunjungi kembali paragraf ke-3 saya, terutama bagian ini di sini: "Harap dicatat bahwa saya tidak menganjurkan pengkodean gaya spaghetti / koboi di sini ...".
Jas

3

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.


3

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.


3
Programmer menghabiskan lebih banyak waktu membaca kode daripada menulis kode. Jika kode tidak dapat dibaca, biaya untuk memperpanjang atau mempertahankannya menjadi sangat besar. Dan jika nama variabel tidak konsisten, salah eja, dan tidak deskriptif, itu membuat kode tidak dapat dibaca.
Dima

@Dima, benar, tetapi kode yang berfungsi dan elegan itu sudah lebih mudah dibaca daripada kode yang rusak dan tidak elegan.
jjnguy

1
Maksud saya adalah bahwa Anda harus dapat melihat nama variabel, atau nama kelas, atau nama fungsi, dan segera tahu cara menggunakannya tanpa harus menggali seluruh basis kode. Anda juga harus bisa mengetik nama mengikuti konvensi dan melakukannya dengan benar tanpa harus mencarinya. Saya sarankan Anda membaca "Kode Bersih" oleh Robert C. Martin.
Dima

@ Dima, saya setuju bahwa variabel harus memiliki nama deskriptif. OP tidak menyebutkan bahwa nama-nama itu buruk, hanya saja mereka tidak konsisten.
jjnguy

1
Dalam pengalaman saya, ketika nama tidak konsisten, mereka juga cenderung tidak deskriptif. Tapi ada masalah lain. Ketika nama tidak konsisten, Anda perlu waktu lebih lama untuk mengingatnya, dan Anda harus meluangkan waktu untuk mencarinya. IDE yang baik bisa membantu, tetapi itu tidak akan menyelesaikan masalah sepenuhnya. Pemrograman sudah menempatkan cukup banyak beban di otak Anda, jadi Anda ingin mengurangi jumlah pemetaan mental dan memeriksa sebanyak mungkin.
Dima

2

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.


2

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.


2

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.


2

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.



1

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.


1

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!

teks alternatif


1

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.


0

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.


5
Jika nama variabel Anda salah eja, orang berikutnya yang menggunakan kode Anda harus menghabiskan waktu ekstra untuk memperbaiki kesalahan kompiler ketika ia mengeja dengan benar. Ini bukan tentang "kepekaan halus". Hal-hal yang tampaknya sepele ini menyebabkan kesalahan, yang menyebabkan frustrasi, yang menyebabkan lebih banyak kesalahan. Semua itu menambah biaya perawatan kode besar.
Dima

4
Ini sedikit lebih daripada tentang "sensibilitas halus", tetapi produktivitas saya tidak keberatan seseorang dengan gaya pengkodean yang sedikit berbeda, kadang-kadang lupa ruang, dll ... Kami tidak sempurna. Tetapi ketika seluruh file tampak seperti itu telah ditulis oleh seorang sarjana, tanpa spasi baris, posisi, indentasi dan aliran kode umum, maka saya baru saja menekan tombol "tolak" (atau kembalikan) dengan sangat cepat.
haylem

2
Banyak proyek open source yang sukses (termasuk linux) melakukan ini: jika Anda tidak memiliki gaya yang tepat (dan tes unit), maka ditolak. Sayang sekali jika itu baik dan memecahkan masalah nyata: Anda tidak selalu dapat memperbaiki kode orang lain. Secara keseluruhan, Anda kehilangan lebih sedikit waktu dan uang hanya lewat sepotong jenius sesekali yang melewati tetapi tampak seperti neraka atau tidak dapat dipertahankan.
haylem

1
Hal lucu. Namun tentu saja poin utama sepertinya dilewatkan. Pertama-tama, ajak pria itu bergabung dengan hal-hal nyata yang bisa Anda jadikan alasan kuat. Kemudian Anda mengerjakan hal-hal yang kurang penting. Ada cara untuk bekerja dengan orang-orang di luar hanya mencekik mereka dengan aturan. Dan mungkin, mungkin saja, kerumunan OCD mungkin sedikit kompromi atau belajar mengapa ada begitu banyak variabel dalam kode yang lain. Mungkin sebenarnya ada sebab atau alasan.
ElGringoGrande

0

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.

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.