Bagaimana cara menghadapi berbagai gaya pemrograman dalam sebuah tim?

Kami memiliki tim pengembang kecil (hanya 3 pengembang) dan kami baru saja mendapat anggota tim baru. Walaupun dia adalah seorang pembuat kode yang cerdas, gaya pengkodeannya benar-benar berbeda dari kita. Basis kode kami yang ada sebagian besar berisi kode yang dapat dibaca, bersih, dan dapat dipelihara, tetapi anggota tim baru dengan cepat mengubah banyak file, memperkenalkan peretasan dan pintasan yang jelek, menggunakan definisi di semua tempat, menambahkan fungsi di tempat yang salah, dll.

Pertanyaan saya adalah apakah orang lain pernah mengalami situasi seperti itu sebelumnya, dan jika ada yang punya tips tentang cara berbicara dengannya.

Saya bekerja dengan tim yang tumbuh dari 2 pengembang menjadi 10 dalam waktu kurang dari setahun. Saya nomor 3, dan yang pertama mengangkat masalah standar pengkodean. Dua pengembang asli telah bekerja berdampingan selama beberapa tahun dan mereka telah mengadopsi standar umum yang tampak asing bagi saya. Kami memiliki masalah yang sama persis dengan yang Anda gambarkan.

Apa yang kami lakukan adalah:

Meneliti standar pengkodean

Kami menghabiskan beberapa hari memeriksa proyek sumber terbuka yang sudah mapan. Kami tahu tim akan berkembang pesat dan kami mencari solusi nyata berdasarkan proyek nyata bukan beberapa pedoman umum. Kami juga tidak peduli dengan standar pengkodean yang optimal, tetapi untuk seperangkat aturan dan pedoman yang masuk akal dan tidak menyerukan refactoring semua basis kode kami. Kami mencari peretasan standar pengkodean jika Anda mau.

Kami bertiga memutuskan bahwa standar pengkodean terbaik di luar sana untuk proyek PHP yang mapan adalah yang diikuti oleh Zend Framework. Untungnya orang-orang Zend Framework menyediakan dokumen standar pengkodean yang sangat komprehensif .

Menciptakan standar pengkodean kita sendiri

Tentu saja menerapkan standar pengkodean proyek lain pada proyek kami karena tidak masuk akal. Kami menggunakan dokumen Zend Framework sebagai templat:

• Pertama, kami menghapus semua yang tidak berlaku untuk proyek kami
• Kemudian kami mengubah semua yang kami anggap sebagai masalah gaya menjadi gaya kami
• Dan akhirnya kami menulis semuanya

Jadi kami memiliki dokumen yang cukup besar di tangan kami, disimpan di wiki mewah kami , itu adalah bacaan yang bagus, disetujui oleh kita semua. Dan sama sekali tidak berguna dengan sendirinya.

Tetap setia pada janji kami

Basis kode kami pada saat itu adalah sekitar 1 * 10 ^ 6 sloc. Kami tahu bahwa karena kami mengadopsi standar pengkodean formal, kami harus mulai refactoring kode kami, tetapi pada saat itu kami ditekan dengan masalah lain. Jadi kami memutuskan untuk hanya memperbaiki perpustakaan inti kami, hanya 5 * 10 ^ 3 sloc.

Kami menugaskan salah satu dari kami untuk menjadi master standar pengkodean (kami menggunakan kata-kata kotor lokal sebagai pengganti master ) dengan tanggung jawab memeriksa dan menegakkan standar. Kami mendaur ulang peran setiap beberapa sprint. Saya yang pertama, dan itu banyak pekerjaan, karena saya harus memantau hampir setiap komitmen.

Kami memiliki beberapa diskusi baru dan tambahan kecil pada dokumen asli selama masa jabatan saya, dan akhirnya kami memiliki dokumen yang agak stabil. Kami mengubahnya setiap sekarang dan kemudian tetapi sebagian besar dari perubahan ini adalah pada fitur baru dari bahasa, karena PHP 5.3 adalah rilis utama di semua kecuali nama.

Berurusan dengan pria baru

Ketika orang baru berikutnya tiba, saatnya menguji standar pengkodean kami. Setelah pengantar kecil untuk basis kode kami, kami memintanya untuk mengevaluasi dokumen standar pengkodean kami. Dia hampir menangis. Tampaknya dia melakukan segalanya secara berbeda.

Karena saya adalah master standar pengkodean pada saat itu, terserah saya untuk mengevaluasi masukannya dan merevisi dokumen yang sesuai. Usulannya adalah:

• Hal-hal dari gaya pribadi (disingkirkan)
• Standar yang masuk akal untuk latar belakang Java-nya tetapi tidak begitu banyak dengan PHP (diberhentikan)
• Konvensi yang dia bawa dari paparan singkatnya dengan PHP (beberapa ditolak, tetapi banyak yang terbukti sebagai konvensi populer yang tidak pernah kita pikirkan atau temukan dalam penelitian awal kami)

Untuk beberapa minggu ke depan dia diberi tugas sederhana: Membawa beberapa bagian basis kode kami dengan standar terkini. Saya harus hati-hati memilih bagian-bagian itu berdasarkan beberapa aturan:

• Kode harus relatif mudah bagi seseorang yang tidak terbiasa dengan basis kode kami (dan PHP pada umumnya)
• Kode harus pada apa yang disewa untuk dilakukan

Saya memantau prosesnya dan dia melakukan pekerjaan dengan baik. Kami mengidentifikasi beberapa bagian kode yang tidak sesuai dengan dokumen kami dan direvisi sesuai (kode dan / atau standar, mana yang lebih masuk akal)

Dan kemudian seorang pria baru tiba. Kami mengulangi prosesnya (master berbeda kali ini), dan itu berhasil lagi. Dan lagi.

Kesimpulannya

1. Buat dokumen standar pengkodean, tetapi pastikan bahwa standar Anda tidak hanya milik Anda sendiri tetapi mencerminkan standar umum di komunitas yang lebih luas dari platform Anda.
2. Tetapkan peran yang mirip dengan master standar pengodean kami. Seseorang untuk memantau setidaknya kode baru, dan terutama kode baru dari anggota baru. Daur ulang peran, karena sangat membosankan.
3. Selalu evaluasi input dari anggota baru. Selalu revisi standar Anda jika itu masuk akal. Dokumen standar pengkodean Anda harus berevolusi, tetapi lambat. Anda tidak ingin memperbarui kembali basis kode Anda di setiap iterasi.
4. Berikan waktu bagi setiap anggota baru untuk belajar dan beradaptasi dengan standar dan konvensi Anda. Belajarlah dengan melakukan yang terbaik dalam situasi ini.
5. Wiki mengerjakan keajaiban untuk dokumen-dokumen semacam itu.
6. Ulasan kode berfungsi dengan sangat baik untuk situasi apa pun!

Pada titik tertentu dalam proses itu disarankan agar kami menggunakan kait pra-komit untuk mengotomatiskan pengecekan standar. Kami memutuskan untuk tidak melakukannya karena berbagai alasan, ada beberapa diskusi menarik tentang StackOverflow tentang masalah ini:

• Pemformatan kode otomatis SVN saat check-in?
• Kontrol Versi dan Pemformatan Pengodean
• PHP codesniffer (phpcs) - bagaimana mengizinkan override saat menggunakan sebagai bagian dari hook pre-commit svn?
• SVN Pre-commit hook akan dipicu untuk folder tertentu
• Menerapkan Standar Pengodean PHP

Beberapa khusus PHP, tetapi jawaban berlaku untuk semua platform.

Ya, saya pernah mengalaminya sebelumnya. Saat bekerja dalam tim, anggota tim harus menyetujui aturan dan konvensi tertentu, dan itu termasuk gayanya.

Anda harus meminta tim Anda duduk bersama dan menyusun seperangkat aturan, standar pengkodean , yang harus Anda patuhi setiap bagian dari kode yang diperiksa.

Kemungkinan besar, dasar untuk set aturan Anda, setidaknya gaya, akan menjadi kode yang ada. Setelah selesai, semua orang harus patuh, dan itu harus diperiksa sebagai bagian dari tinjauan kode . Kode yang tidak mematuhi standar tidak boleh diizinkan masuk.

Ngomong-ngomong, itu tidak harus menjadi pemungutan suara yang demokratis, itu adalah salah satu hal di mana pemimpin tim dapat benar-benar menjalankan wewenang. Tetapi setelah mengatakan itu, saya tidak berpikir bahwa Anda dapat memaksakan standar yang ditolak oleh sebagian besar tim. Anda dapat menerapkan standar yang ditolak oleh satu orang, terutama yang baru.

Mengenai cara berbicara dengannya ... Setiap programmer yang berpengalaman tahu bahwa setiap tempat dan tim memiliki konvensi dan gaya sendiri, yang harus diikuti. Anda dapat memberi tahu dia bahwa dia lebih dari menyambut untuk menyarankan perbaikan, tetapi dia harus mematuhi aturan yang dimiliki tim, dan dia tidak boleh mengubah gaya kode yang ada tetapi menggunakan gaya yang sama saat menambahkan kode baru.

Juga, Anda dapat memberi tahu (jika Anda adalah manajer, atau berbicara dengan manajer Anda tentang hal itu) kepada orang itu untuk tidak melakukan hal-hal tertentu yang Anda anggap tidak pantas (yang Anda sebutkan mendefinisikan, memesan, meretas dan pintasan, dan semacamnya).

1. Seseorang yang bertanggung jawab - mereka harus bertindak seperti itu.
2. Jika gaya pengkodean sangat penting, mengapa ini tidak dijelaskan kepada orang ini dan biarkan mereka tahu bahwa mereka tidak akan memiliki akses ke kode apa pun sampai mereka mempelajari aturannya.
3. Tinjauan Kode - tampaknya Anda tidak memiliki atau sangat lemah. Lihat # 1.

Buat catatan dalam proses perekrutan Anda, bahwa mengikuti gaya pengkodean yang diterima adalah persyaratan untuk pekerjaan. Sekarang apa yang Anda lakukan terhadap mereka yang tidak mengikuti aturan? Mulailah dengan menghapus akses mereka ke kode langsung sampai mereka mendapatkan dengan program ini.

.

Inilah yang bisa dilakukan:

1. Tulis dokumen yang menjelaskan gaya pengkodean yang diperlukan dan buat semua orang di tim mempelajarinya. Kumpulkan informasi dari setiap anggota tim.
2. bagilah tugas sedemikian rupa sehingga setiap anggota tim bertanggung jawab atas bagian mereka sendiri, dan dapat memutuskan konvensi bagian kode itu. Jika ada masalah yang ditemukan, siapa pun yang menulisnya akan memperbaiki masalahnya.
3. tambahkan alat otomatis ke kontrol versi yang memperbaiki lekukan dan hal-hal lain setiap kode waktu dikomit ke kontrol versi
4. Pemrogram yang berbeda selalu memiliki gaya pemrograman yang berbeda, dan nantinya bisa sulit untuk berubah. Cara terbaik untuk mengatasinya adalah dengan berbagi informasi antar anggota tim sehingga setiap orang mempelajari gaya apa yang telah digunakan orang. Jika Anda memiliki anggota tim yang menulis kode berbeda, ini merupakan kesempatan bagi anggota tim Anda yang ada untuk mempelajari gaya baru.
5. Salah satu trik yang bagus adalah jangan pernah memodifikasi kode yang ada. Alih-alih mengubah kode, tulis kode baru dengan mengganti baris kosong dengan kode baru. Dan begitu kode siap, lakukan hanya modifikasi terkecil ke sistem yang ada untuk menggunakan kode baru. Ini menghindari mengubah kode yang ada, mungkin merusak apa yang sudah berfungsi dengan baik.

Inilah yang harus dihindari:

1. memutuskan bahwa kode seseorang lebih baik atau lebih buruk daripada anggota tim lainnya. Itu tidak berfungsi seperti itu - semua orang tahu bagian tertentu dari bahasa yang cukup baik untuk menggunakannya dalam kode. Setiap programmer memilih subset berbeda untuk dipelajari, dan kecuali mereka mempelajarinya bersama, itu akan terlihat berbeda.
2. Mengubah cara seseorang menulis kode. Yang Anda dapatkan dengan memaksa orang untuk menulis gaya asing adalah Anda mendapatkan banyak bug dalam kode. Orang-orang tidak tahu cukup detail tentang sesuatu yang mereka gunakan pertama kali. Pemrogram selalu memilih subset bahasa dan menggunakannya sendiri. Jika programmer Anda telah menulis ribuan baris kode yang berisi gotos, maka gotos akan memberi Anda kode yang memiliki jumlah bug paling sedikit.
3. Anda juga tidak boleh berpikir bahwa basis kode Anda yang ada adalah hal-hal yang bagus, bersih, dapat dipelihara. Selalu ada hal untuk diperbaiki. Tetapi juga setiap perubahan mengaburkan ide desain asli yang ditulis untuk itu. Bertujuan untuk menulis kode sempurna pertama kali, sehingga perubahan tidak diperlukan nanti. (orang baru tidak perlu "memecahkan" kode sempurna Anda, jika itu dilakukan dengan benar pertama kali)

Basis kode kami yang ada sebagian besar berisi kode yang mudah dibaca, bersih, dan dapat dikelola

Satu hal yang saya pelajari selama bertahun-tahun adalah keterbacaan ada di mata yang melihatnya. Saya telah melihat banyak kasus di mana gaya pengkodean chickenscratch seseorang dibenarkan sebagai "dapat dibaca", dan saya telah melihat orang yang sangat masuk akal berdebat tentang gaya pengkodean mana yang paling "dapat dibaca". Mungkin orang ini tidak menganggap gaya Anda mudah dibaca?

Yang mengatakan, pria baru harus sesuai dengan standar Anda, bukan sebaliknya.

Pertimbangkan untuk menggunakan permintaan tarik untuk kode baru ke dalam repositori. Ini memberikan tempat yang nyaman untuk melakukan tinjauan kode. Kode yang gagal tinjauan kode tidak digabungkan ke dalam repositori hingga bentuknya sesuai.

Berhati-hatilah untuk tidak membuat permintaan tarikan terlalu besar. Dalam pengalaman saya mereka tidak boleh lebih besar dari antara setengah hari hingga maksimal dua hari atau Anda akan memiliki terlalu banyak konflik gabungan.

Sistem vcs online seperti bitbucket atau github mendukung fungsi ini. Jika Anda lebih memilih pendekatan on-premise, simpanan sepertinya merupakan taruhan terbaik saat ini.

Ada aturan sederhana yang dapat Anda ikuti: Jika Anda memodifikasi file dengan kode, Anda menggunakan standar pengkodean yang digunakan dalam file itu. Jika Anda membuat file baru, Anda menggunakan standar pengkodean yang bagus. (Plus: Jika kompiler Anda dapat memberikan peringatan, Anda mengaktifkan semua peringatan yang masuk akal, aktifkan peringatan = kesalahan jika memungkinkan, dan jangan izinkan kode apa pun dengan peringatan. Plus: Jika Anda menggunakan alat yang membuat perubahan grosir dalam file, seperti mengubah tab ke spasi atau sejenisnya, JANGAN menggunakannya).

Alasan mengapa ada argumen besar tentang standar pengkodean adalah bahwa satu standar tidak lebih baik atau lebih buruk daripada yang lain (biasanya) tetapi hanya berbeda. Satu-satunya yang benar-benar buruk hal yang adalah mencampur gaya pengkodean.

Jelas saya berharap bahwa setiap programmer yang layak dapat menulis kode mengikuti standar pengkodean, apakah mereka lebih suka standar tertentu atau tidak.

Dan di sisi lain, ada standar kualitas. Jangan pernah menerima kode yang tidak memenuhi standar kualitas Anda.