Menangani Standar Pengodean di Tempat Kerja (Saya bukan bos)

Saya bekerja di tim kecil, sekitar 10 devs. Kami tidak memiliki standar pengkodean sama sekali. Ada hal-hal tertentu yang telah menjadi norma tetapi beberapa cara melakukan hal-hal yang sama sekali berbeda. Yang besar saya adalah lekukan. Beberapa menggunakan tab, beberapa menggunakan spasi, beberapa menggunakan jumlah ruang yang berbeda, yang menciptakan masalah besar. Saya sering berakhir dengan konflik ketika saya bergabung karena seseorang menggunakan IDE mereka untuk memformat otomatis dan mereka menggunakan karakter yang berbeda untuk membuat indentasi daripada saya. Saya tidak peduli yang kita gunakan. Saya hanya ingin kita semua menggunakan yang sama.

Atau kalau tidak saya akan membuka file dan beberapa baris memiliki kurung keriting pada baris yang sama dengan kondisi sementara yang lain memilikinya di baris berikutnya. Sekali lagi, saya tidak keberatan yang mana asalkan semuanya sama.

Saya telah mengemukakan masalah standar kepada manajer langsung saya, satu lawan satu dan dalam pertemuan kelompok, dan dia tidak terlalu khawatir tentang hal itu (ada beberapa orang lain yang memiliki pandangan yang sama seperti saya). Saya mengemukakan kekhawatiran spesifik saya tentang karakter lekukan dan dia pikir solusi yang lebih baik adalah, "membuat semacam naskah yang dapat mengubah semua itu ketika kita mendorong / menarik dari repo." Saya curiga dia tidak ingin berubah dan solusi ini tampaknya terlalu rumit dan rentan terhadap masalah pemeliharaan (juga, ini hanya mengatasi satu manifestasi dari masalah yang lebih besar).

Adakah di antara Anda yang mengalami situasi serupa di tempat kerja? Jika demikian, bagaimana Anda menanganinya? Apa poin bagus untuk membantu menjual bos saya berdasarkan standar? Akankah memulai gerakan akar rumput untuk menciptakan standar pengkodean, di antara kita yang tertarik, menjadi ide yang bagus? Apakah saya terlalu khusus, haruskah saya membiarkannya begitu saja?

Terima kasih atas waktunya.

Catatan: Terima kasih semuanya atas tanggapan Anda yang luar biasa sejauh ini! Untuk lebih jelasnya, saya tidak ingin mendikte One Style Untuk Memerintah Mereka Semua. Saya bersedia mengakui cara yang saya sukai untuk melakukan sesuatu demi apa yang paling cocok untuk semua orang. Saya ingin konsistensi dan saya ingin ini menjadi demokrasi. Saya ingin itu menjadi keputusan kelompok yang disetujui semua orang. Benar, tidak semua orang mendapatkan apa yang diinginkannya, tetapi saya berharap setiap orang akan cukup matang untuk berkompromi demi kemajuan kelompok.

Catatan 2: Beberapa orang terjebak dalam dua contoh yang saya berikan di atas. Saya lebih mengincar inti permasalahan. Ini memanifestasikan dirinya dengan banyak contoh: konvensi penamaan, fungsi besar yang harus dipecah, harus ada sesuatu yang digunakan atau layanan, harus sesuatu menjadi konstan atau disuntikkan, haruskah kita semua menggunakan versi yang berbeda dari ketergantungan atau sama, jika suatu antarmuka digunakan untuk kasus ini, bagaimana seharusnya tes unit diatur, apa yang harus diuji unit, (khusus Java) kita harus menggunakan anotasi atau konfigurasi eksternal. Saya bisa melanjutkan.

Seorang rekan kerja dan saya memiliki masalah serupa di tim kami ketika kami pertama kali bergabung (saya bergabung dengan tim pertama, ia bergabung sekitar setahun kemudian). Tidak ada standar kode nyata. Kami adalah toko MS, dan bahkan standar pengkodean MS tidak digunakan. Kami memutuskan untuk memimpin dengan memberi contoh. Kami duduk bersama dan menyusun dokumen yang memiliki semua standar kami: standar IDE, standar penamaan, semua yang dapat kami pikirkan. Kemudian dia dan saya setuju untuk mengikuti standar secara eksplisit. Saya mengirim email ke tim (dari kami berdua), dan memberi tahu mereka bahwa kami telah menemukan kekurangan dan kami akan mengatasi kekurangan tersebut dengan dokumen kami. Kami mengundang kritik, ide, komentar, pendapat. Kami menerima sangat sedikit umpan balik dan hanya sedikit dorongan. Dia dan saya segera mulai menggunakan standar, dan ketika kami membawa pengembang junior ke proyek kami, kami memperkenalkan mereka dengan standar dan mereka mulai menggunakannya. Kami memiliki beberapa petunjuk yang enggan pada awalnya tetapi perlahan mulai menggunakan standar untuk banyak hal.

Kami menemukan bahwa banyak pengembang junior telah mengenali masalah yang sama tetapi sedang menunggu orang lain untuk melangkah dan membuat keputusan. Begitu ada rencana untuk diikuti, banyak yang ingin mengadopsinya. Kacang-kacangan yang sulit untuk dipecahkan adalah orang-orang yang menolak kode dengan cara lain, dan mereka biasanya akan keluar dari gambar dalam jangka panjang.

Jika Anda menginginkan standar, nyalakan jalannya. Munculkan daftar standar yang menurut Anda akan menguntungkan tim Anda. Kirimkan ke rekan dan petunjuk untuk umpan balik. Saya yakin orang lain di tim Anda memiliki ide yang sama, tetapi mereka mungkin kurang memiliki keberanian untuk melakukan apa pun tentang itu. Seperti yang dikatakan Gandhi, "Anda harus menjadi perubahan yang ingin Anda lihat di dunia."

Standar seharusnya tidak menjadi sesuatu yang didefinisikan dan ditegakkan oleh seorang manajer. Tim secara keseluruhan harus menyetujui standar. Jika mereka tidak dapat menyetujui satu set standar yang sama, meminta seorang manajer untuk memaksakan standar akan gagal.

Anda dan orang lain yang setuju dengan Anda harus memimpin dengan memberi contoh. Mulai gunakan standar pengkodean yang sama, publikasikan, dan promosikan ke seluruh tim dan undang umpan balik tentang cara meningkatkannya.

Inilah bagian penting ketika mencoba mempromosikan standar: pastikan fokusnya bukan pada menemukan cara terbaik untuk melakukan sesuatu, tetapi lebih pada menemukan cara yang konsisten dalam melakukan sesuatu. Sama seperti beberapa orang mungkin tidak setuju, tidak ada satu gaya penyangga sejati, tidak ada satu gaya komentar sejati, dll. Apa yang membuat kode lebih mudah dibaca (dan dengan demikian, lebih mudah untuk mempertahankan) adalah gaya yang konsisten, tidak peduli apa itu.

Bisakah Anda menunjukkan beberapa bukti waktu yang Anda buang karena masalah yang ditimbulkannya?

Jika Anda menghabiskan banyak waktu untuk mengatasi masalah ini, atau menyebabkan bug yang membutuhkan waktu untuk memperbaikinya, maka ini adalah biaya yang dapat Anda kurangi secara drastis dengan mengadopsi standar pengkodean.

Jadi, catat semua masalah yang Anda temui dan waktu yang dibutuhkan untuk menyelesaikannya - baik untuk Anda dan (jika Anda mengetahuinya), kolega Anda.

Lalu ketika Anda memiliki jumlah data yang masuk akal, berikan kepada kolega Anda. Mereka harus melihat manfaat dari mengadopsi standar. Jika tidak menunjukkan data kepada bos Anda dan bosnya. Tunjukkan bahwa dengan memiliki standar pengkodean Anda dapat menghemat uang perusahaan Anda dan mereka harus mendukung Anda untuk menerapkannya.

Pada situasi khusus Anda, saya pikir solusi atasan Anda adalah solusi yang bagus. Tidak ada yang harus mengubah apa yang telah mereka lakukan untuk seluruh karir mereka, dan itu tidak apa-apa karena potongan-potongan gaya kode yang diabaikan oleh kompiler tidak masalah selama kode tersebut dapat dibaca. Jika semua orang melakukan autoformat untuk gaya mereka saat check out dan autoformat ke gaya standar saat check-in, semua akan baik-baik saja. (Sayangnya saya menyarankan di mana saya bekerja dan itu ditentang dengan alasan bahwa pembuat kode tidak lagi akan menulis kode persis sama seperti yang dilihat oleh server integrasi berkelanjutan.)

Saya pikir standar pengkodean baik ketika diterapkan ke tempat-tempat di mana ia membuat perbedaan nyata dalam kualitas kode: misalnya, metode bertubuh kecil, kelas yang memiliki satu tanggung jawab yang dinyatakan dengan jelas, komentar yang berguna dan akurat untuk bit yang lebih keras, dll. Sayangnya, aspek-aspek tersebut lebih sulit untuk secara otomatis memeriksa, tetapi itu penting untuk pengembangan perangkat lunak. Yang dapat Anda lakukan adalah mengajar orang lain praktik yang baik dan mengajar diri sendiri untuk membaca kode dengan penjepit di baris yang salah.

Mengenai standar pengkodean: Saya akan naik ke papan dengan hampir semua orang mengatakan bahwa standar pengkodean adalah "hal yang baik" (versus tidak ada standar).

Namun, jangan terbawa suasana. Saya telah mengerjakan beberapa proyek yang mendiktekan gaya lekukan tertentu, hingga jumlah karakter (dan ketika proyek berjalan sejauh itu, mereka pasti memilih sesuatu yang bodoh seperti indentasi 8 ruang). Jangan memusingkan hal-hal kecil.

Solusi sederhana: Berikan para pengembang pilihan terbatas untuk penyangga dan lekukan, tetapi menentukan bahwa gaya penyangga dan lekukan harus konsisten di seluruh modul. (Anda ingin foo.h dan foo.cpp mengikuti gaya yang sama, bukan?) Pengelola harus beradaptasi dengan gaya yang ada; mereka tidak dapat menulis ulang modul yang sesuai dengan gaya aneh mereka. Berbagai gaya dalam modul hanya membingungkan dan merupakan tanda kecerobohan. Ketika saya melihat omong kosong itu membuat saya bertanya-tanya apa lagi yang salah.

Anda mungkin juga ingin mempertimbangkan untuk melarang tab untuk lekukan dalam isi file yang disimpan . Kebanyakan IDE / editor melakukan pekerjaan yang wajar menerjemahkan tab input pengguna ke spasi, dan sebagian besar memiliki opsi untuk membuat terjemahan itu otomatis. Banyak yang melakukan pekerjaan yang jelek ketika file sudah berisi tab, khususnya kantong campuran tab dan spasi.

Semua yang dikatakan, saya pikir Anda mungkin memiliki masalah yang lebih dalam dalam proyek Anda. Anda menyebutkan masalah dengan penggabungan. Jika Anda mendapati diri Anda perlu melakukan banyak penggabungan, itu mungkin merupakan tanda partisi yang buruk dari proyek tersebut. Sama seperti terlalu banyak koki merusak kaldu, terlalu banyak programmer yang beroperasi pada file yang sama merusak proyek. Mengapa masing-masing dari Joe, Susie, dan Anda menyentuh foo.cpp?

Ini adalah salah satu bidang di mana beberapa penelitian dilakukan. Pada dasarnya pertanyaan utama adalah apakah Anda melakukan tinjauan kode. Ulasan kode tanpa ragu merupakan cara yang paling efisien untuk meningkatkan kualitas kode. (Sumber: Software Engineering Institute, CMU). Ini tentu saja lebih efisien daripada tester tambahan.

Sekarang, ulasan kode mendapat manfaat dari standar pengkodean yang umum, karena itu membuatnya lebih mudah untuk membaca kode orang lain. Itu memberi Anda argumen dua langkah untuk memperkenalkan standar pengkodean: pada akhirnya, itu membuatnya lebih murah untuk menghasilkan kode yang baik.

Karena sudah ada "beberapa orang lain" yang bersama Anda dalam hal ini, saya akan menyarankan pertemuan dadakan. Undang semua devs, luangkan waktu sebentar dan cari tahu hal - hal apa yang mengganggu diri Anda dan kolega Anda sehari-hari. Jangan mencoba mencari solusi spesifik pada awalnya, cari tahu apa yang perlu diubah dengan cara Anda semua menulis kode saat ini.

Kemudian, lihat apakah Anda semua bisa menyetujui beberapa konsep dasar. Saran untuk menggunakan gaya yang sama dalam setiap modul yang dibawakan oleh @David Hammen adalah awal yang baik, dan saya pikir sebagian besar pengembang dapat langsung menyetujuinya.

Jika, begitu Anda memiliki tepuk bawah, Anda merasa bahwa Anda semua dapat menyetujui beberapa gaya dasar untuk saat menulis kode baru, itu tambahan yang bagus. Fokus pada hal-hal yang benar-benar berdampak pada pemeliharaan masalah penamaan akan tinggi pada daftar pribadi saya karena jika Anda memiliki setengah lusin gaya penamaan yang berbeda dalam satu produk dari setiap kompleksitas yang menonjol, itu akan menjadi sakit kepala dengan sangat cepat, tetapi sekali lagi, fokus pada apa yang Anda dan tim Anda anggap penting . Buat konsep dokumen pendek yang setidaknya semua orang setuju untuk mengikuti (bahkan jika mereka mungkin memiliki gaya hewan peliharaan yang berbeda) dan mengirimkannya kepada semua orang di tim. Jadikan itu dokumen "hidup", pastikan untuk memperbaruinya dengan waktu, tetapi pastikan untuk tidak membuatnya terlalu kaku dan spesifik.

Kecuali jika bos Anda terlibat dalam penulisan kode, ia tidak perlu terlalu khawatir tentang gaya yang tepat diadopsi (asalkan fokus pada keterbacaan dan pemeliharaan), tetapi ia harus dapat melihat manfaat dari semua orang di tim mengikuti gaya yang sama saat menulis kode.

Ada beberapa hal yang menyakitkan. Paling menyakitkan adalah IDE yang secara otomatis memformat ulang kode, dikombinasikan dengan pengembang yang mengatur IDE mereka dengan cara yang berbeda. Setiap kali Anda membandingkan kode, Anda memiliki ratusan perubahan setelah seseorang dengan pengaturan berbeda mengedit kode. Itu tidak bisa diterima. Di sini Anda perlu membenturkan kepala semua orang, menyetujui serangkaian pengaturan, dan menolak checkin apa pun oleh siapa pun yang menggunakan pengaturan berbeda. Jika saya mengubah satu baris kode, diffs akan menunjukkan satu baris kode yang berubah, dan bukan ratusan.

Segala sesuatu yang lain tidak berbahaya, atau ada cara yang lebih baik untuk melakukan hal-hal yang dapat diyakinkan oleh orang lain. Di sini aturannya adalah: Jangan main-main dengan kode orang lain kecuali Anda benar-benar memperbaikinya. Dan campuran gaya A dan gaya B selalu lebih buruk daripada gaya A atau gaya B.

Pastikan Anda mengikuti praktik terbaik. Yang berbeda per bahasa. Tetapi di sana Anda tidak memerlukan standar (yang mungkin ditulis oleh seseorang yang bermaksud baik tetapi tidak benar-benar diketahui), tetapi semua orang harus mencoba memberikan contoh yang baik.

Jelas menghindari perebutan kekuasaan. Tidak ada yang lebih buruk daripada Hitler kecil di tim Anda yang mencoba memaksa semua orang untuk melakukan kehendaknya. Dan itu sayangnya pria yang akan secara sukarela menulis standar pengkodean Anda :-(

Semua contoh yang Anda berikan pada dasarnya tentang spasi dan pemformatan. Jika itu masalah terbesar, saya agak setuju dengan manajer Anda: itu bukan masalah besar.

Di mana standar sangat berguna adalah dengan memberi nama dan mengurangi kerumitan. Cara memberi nama pengidentifikasi, kelas, tempat menempatkannya, dll. Menjaga nama tetap konsisten adalah sangat penting, terutama dalam proyek besar. Aturan untuk mengurangi kerumitan termasuk menjaga fungsi di bawah sejumlah garis tertentu (memecahnya menjadi fungsi yang lebih kecil), atau menjaga daftar parameter di bawah sejumlah argumen tertentu (mungkin Anda harus menggabungkannya ke dalam objek dan meneruskannya di sekitar).

Jika pengembang tertentu di tim Anda menulis kode yang lebih sulit untuk dipahami / didebug karena mencakup banyak potongan kode panjang dengan nama variabel satu huruf, itu adalah alasan yang baik untuk mengadopsi beberapa standar, dan bukan sesuatu yang dapat diperbaiki dengan sebuah skrip. Itu hal yang baik untuk ditunjukkan (secara bijaksana) sebagai hal yang dapat ditingkatkan standar.

Alasan lain yang mungkin tidak dilihat manajer Anda sebagai masalah adalah karena Anda jarang membaca kode satu sama lain. Itu bisa terjadi ketika semua orang memiliki area kode mereka sendiri dan tidak berani keluar terlalu banyak. Itu bekerja dengan sangat baik sampai seseorang meninggalkan organisasi, yang dapat terjadi karena berbagai alasan baik atau buruk. Standar yang membantu keterbacaan akan memudahkan pengembang baru untuk mengambil alih pemeliharaan sepotong kode.

konflik ketika saya bergabung karena seseorang menggunakan IDE mereka untuk memformat otomatis dan mereka menggunakan karakter yang berbeda untuk membuat indentasi daripada saya

Sepertinya ini adalah masalah Anda, bukan format, tetapi format ulang. Ini adalah masalah besar bagi SCM dan sarannya sederhana: jangan lakukan itu. Jadi lain kali seseorang memformat ulang semua ruang untuk tab, atau refactor kurung keriting dengan gaya pilihan mereka, Anda perlu menamparnya. Buat mereka melakukan penggabungan sebagai gantinya; berdiri di atas mereka tampak tidak suka membuang-buang waktu karena kesembronoan mereka.

Alternatifnya adalah memasukkan formatter pra-komit, yang selalu memformat ulang semua kode ke gaya standar sebelum checkin. Jika Anda memiliki tim pengembang yang memformat ulang sebagai hal yang biasa, maka ini adalah pilihan yang baik - SCM akan selalu melihat format yang sama, sehingga delta akan kecil dan bagus untuk digabungkan.

Ketika seseorang menyarankan standar pengkodean baru tempat saya bekerja, kami memberikan suara untuknya. Jika mendapat suara mayoritas, itu diterima sebaliknya ditolak. Jika Anda tidak melakukan ini, Anda tidak akan menerima standar Anda dan mereka tidak akan digunakan bahkan jika mereka didokumentasikan.

Pada masalah spesifik Anda, taruhan terbaik Anda mungkin akan dimulai dengan saran Joel dan memimpin dengan memberi contoh. Kumpulkan 1 atau 2 programmer yang peduli tentang ini, dapatkan kesepakatan dan Anda akan memiliki kekuatan untuk memaksakan yang malas.

Sekarang, untuk masalah umum, saya menemukan yang terbaik adalah memodulasi . Setiap orang mendapatkan file yang berbeda, jika Anda harus mempertahankan file Anda mempertahankan standar pengkodeannya, bahkan jika itu berbeda dari yang lain. Perlu menulis dalam file yang sama? Buat file subset dan sertakan.

Jangan coba ini!

Pimpin dengan contoh balasan. Cobalah untuk membuat format kode Anda seburuk yang Anda bisa, dan periksa di banyak perubahan diformat mengerikan untuk kode cantik orang lain. Ketika reaksi (tak terhindarkan) terjadi, katakan bahwa apa yang Anda lakukan baik-baik saja karena tidak ada standar pengkodean.

Jika Anda tidak dihukum oleh rekan kerja Anda (!!), Anda mungkin berakhir dengan standar pengkodean.

Jelas, ini adalah strategi berisiko tinggi ... :-)