Bagaimana membujuk pemrogram untuk mengikuti aturan dasar

Ada beberapa aturan yang saya harus terus meminta programmer untuk mengikuti sangat sering. Mereka menulis kode dan, jika berhasil, pekerjaan baru saja selesai, untuk mereka. Sebagian besar aturan dasar mungkin:

• Melakukan perubahan
• Tidak menulis masalah Model di Tampilan atau Pengontrol
• Hindari hardcoding

Bisakah Anda ceritakan tentang pengalaman Anda? Bagaimana Anda mengatur ini?

Semua pekerja pengetahuan harus ditantang untuk melakukan pekerjaan yang berkualitas. Kualitas akan menderita jika mereka merasa kendala waktu sewenang-wenang ditempatkan pada mereka. Mengapa tidak hanya membuat hal-hal yang "cukup baik" ketika semua orang peduli dengan memenuhi spesifikasi dan memenuhi tenggat waktu?

Daftar keluhan Anda adalah gejala perusahaan yang hanya memberikan penghargaan untuk memenuhi tujuan jangka pendek dan tidak memiliki keinginan untuk menekankan kualitas tinggi. Apakah Anda menjalankan hotel bintang lima atau halte truk?

Untuk dapat mengikuti aturan dasar, mereka perlu tahu apa aturannya dan mereka harus menyetujuinya.

Cara untuk mengatasinya adalah dengan bersama - sama membuat dokumen pedoman pengkodean yang dapat disetujui semua orang. Jangan mencoba memaksakan ini pada mereka, itu akan menjadi bumerang jika Anda melakukannya.

Jadi kumpulkan tim dan mulailah bekerja pada definisi umum tentang aturan dasar Anda!

Lakukan itu sebagai bengkel di mana semua suara terdengar. Timebox untuk menghindari diskusi tanpa akhir. Anda mencoba menyatukan beberapa pikiran, jadi Anda mungkin ingin mengatur panggung dengan nada positif bahwa Anda semua harus menghormati dan tetap berpikiran terbuka (penulisan kode bersifat pribadi ...).

Pedoman ini harus diubah terus-menerus setiap kali tim merasa ada sesuatu yang harus ditambahkan atau diklarifikasi.

Apa peranmu Jika Anda hanyalah pengembang lain dengan minat kuat pada kualitas kode, Anda mungkin tidak memiliki wewenang untuk membuat mereka mendengarkan Anda, dan mungkin Anda harus melambungkan ide-ide ini kepada manajemen untuk menetapkan standar kode yang seharusnya / harus diikuti. Jika Anda seorang manajer / pemimpin tim / arsitek apa pun dan Anda memang memiliki otoritas, maka Anda dapat membangun sendiri praktik-praktik itu. Melembagakan dokumen standar dan proses peninjauan kode untuk menyingkirkan hal-hal ini.

Ini tidak akan menjadi saklar ajaib yang bisa Anda nyalakan; itu akan menjadi proses yang lambat dan tidak akan pernah 100%. Lagipula itu pengalaman saya.

Perlu kombinasi yang masuk akal dari semua jawaban sejauh ini. Pada akhirnya, ketika Anda berbicara tentang sekelompok orang pintar (pengembang), Anda harus memberi mereka alasan mengapa perilaku itu penting dan memberi mereka cukup kontrol atas bagaimana perilaku itu diterapkan sehingga mereka berinvestasi untuk melakukannya dengan benar. Mandat dari atas umumnya longgar dengan orang-orang pintar, karena jika mereka tidak setuju bahwa masalahnya adalah masalah, maka mereka cenderung menghabiskan lebih banyak waktu untuk bekerja di sekitar mandat daripada mengikuti aturan.

Inilah beberapa taktik saya:

Melakukan Perubahan:

Pertama, tim perlu menyepakati kapan komitmen dan apa yang harus dilakukan. Sangat penting adalah pengaturan bangunan yang masuk akal, sehingga orang tidak menunda hanya karena mereka tidak tahu di mana harus meletakkan sesuatu. Dan konsensus tentang kapan / seberapa sering untuk check-in. "Jangan merusak gedung" adalah aturan yang jelas, tetapi bagaimana itu diperiksa, dan siapa yang diberitahu tentang hal itu? Baseline lain adalah "tidak dilakukan jika tidak dicentang".

Sebagian besar pengembang yang saya kenal lebih dari senang untuk memeriksa kode JIKA:

• Proses check-in mudah
• Proses sinkronisasi itu mudah (memperhitungkan perubahan dari pengembang lain)
• Melihat perubahan dan berpindah antar versi itu mudah

Satu hal yang saya perhatikan baru-baru ini adalah bahwa checkin menjadi lebih sering dan tidak terlalu menyakitkan ketika kita beralih ke alat CM baru. Tim kami memelopori Konser Tim Rasional yang sebelumnya menggunakan Clearcase. Saya tidak bermaksud mengiklankan alat, tetapi gelombang baru (untuk saya) streaming checkin dengan banyak penggabungan kecil dan cepat membuatnya jauh lebih menarik untuk checkin lebih awal dan sering.

Membiarkan pengembang bertanggung jawab menghilangkan rasa sakit CM umumnya meningkatkan jumlah checkin yang terjadi.

Mengikuti Arsitektur - Tidak Menulis Masalah Model dalam Tampilan dan Pengontrol

Saya menempatkan bahwa dalam rumpun umum "melakukan arsitektur dengan benar". Saya setuju dengan siapa pun yang mengatakan ulasan sejawat - tekanan sejawat sangat bagus untuk ini. Salah satu cara saya biasanya melihat orang masuk ke flip untuk praktik terbaik di bidang ini adalah ketika rekan-rekan mereka bertanya kepada mereka mengapa mereka melakukannya dengan cara lain (cara yang tidak begitu benar). Secara umum pertanyaan "mengapa" akan membawa orang ke jalan untuk menyadari mengapa mereka harus melakukannya secara berbeda. Ketika orang memiliki alasan yang dipahami dengan baik untuk praktik terbaik, akan lebih mudah untuk mematuhinya.

Juga, jika ada beberapa formalitas yang menghubungkan seseorang dengan suatu keputusan, maka akan lebih mudah untuk menetapkan bug di area itu ... jadi jika seseorang bertanggung jawab untuk memperbaiki bug di area desain yang salah, kebutuhan untuk mendapatkan sesuatu tepat sebelum mereka dapat beralih ke sesuatu yang baru dan menarik dapat menjadi motivator besar.

Hindari Hardcoding

Saya akan mulai dengan standar pengkodean yang jelas dan mengintegrasikan tinjauan standar pengkodean dalam ulasan sejawat. Hard coding adalah salah satu hal yang dapat dengan mudah menjadi kotak centang pada agenda peer review.

Saya khawatir hal semacam ini adalah satu-satunya hal di mana saya melihatnya menjadi peran pemimpin tim untuk menegakkan aturan. Di tim yang saya jalankan, kami biasanya tidak akan membiarkan seseorang pindah sampai mereka telah memperbaiki komentar dari ulasan rekan kode mereka. Dan "no hard coding" adalah komentar peer review yang sering.

Secara umum

Dengan hampir semua latihan terbaik, saya pikir Anda harus memilih pertempuran Anda. Tidak ada tim yang akan menjadi sempurna sempurna. Tetapi Anda bisa mengawasi titik-titik rasa sakit utama Anda dan mulai mengatasinya secara berkelompok. Saya pikir itu menjadi peran pemimpin untuk benar-benar tahu apa yang menjadi titik sakit bagi tim vs kekhasan yang mengganggu dari individu tertentu.

Jika tim Anda tidak melakukan praktik terbaik tertentu, saya pikir pertanyaan pertama adalah "berapa banyak kerusakan yang diakibatkan ini?" jika jawabannya "minimal", maka itu mungkin tidak sepadan dengan waktunya. Beberapa praktik terbaik paling relevan dengan jenis sistem tertentu - meskipun secara keseluruhan baik, mereka mungkin tidak sebanding dengan perjuangan untuk sistem di mana praktik tersebut tidak sering terjadi atau bagian utama dari sistem.

Jika jawaban untuk "berapa banyak damange?" adalah "ALOT !!!", maka Anda dapat mulai membangun sebuah kasus untuk menunjukkan kepada tim bahwa semua rasa sakit dan penderitaan ini dapat dihilangkan dengan memperbaiki satu titik kendur ini dalam praktik terbaik. Kebanyakan orang senang menghindari rasa sakit dan penderitaan dan itu mengubah dialog dari "lakukan ini karena saya katakan kepada Anda", menjadi "kami memutuskan untuk melakukan ini karena itu lebih baik".

Ulasan kode. Hanya terima kode yang ditulis dengan baik yang tidak memiliki kesalahan.

Paling sedikit :

• Buat lebih mudah bagi mereka untuk mengikuti kode (Alat seperti resharper, StyleCop) Jika mudah mereka cenderung mengadopsi.

Selain itu pilih yang berfungsi berdasarkan organisasi Anda, pengembang dan peran Anda dalam tim.

• Biarkan mereka melakukan perbaikan bug dan ubah permintaan secara teratur
• Pasangkan program dengan pengembang berpengalaman
• Ulasan kode secara konstruktif
• Panduan kode
• Mulai pelatihan, gunakan buku-buku seperti Code Complete dan The pragmatic programmer.

Peran saya adalah Manajer, tetapi sebagai tim kecil saya berkembang dan saya lebih suka mengelola sebagai pelatih.

Elektroda di kursi yang terhubung ke parser kode telah ditunjukkan, tetapi programmer tampaknya tidak takut. Memecat tidak terdengar sebagai pendekatan yang baik, karena itu berarti kehilangan aset yang layak.

Saya akan melihat semua alat itu dan saya tetap terbuka untuk yang lain yang Anda katakan.

Ada 3 cara kami mengatasi masalah ini:

1. Analisis statis kode sumber untuk memeriksa masalah dengan konvensi pengkodean. Gunakan alat seperti cppcheck dan yang dari grammatech . Wikipedia memiliki daftar yang bagus: http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis . Biasanya sebagian besar sistem kontrol sumber akan memiliki kait di mana Anda dapat memeriksa masalah tersebut secara langsung selama check-in. Untuk kait CVS lihat tautan ini: http://goo.gl/F1gd2 . Kegagalan untuk mematuhi berarti check-in yang gagal, dan lebih dari 3 kegagalan berarti bahwa pengembang harus menjelaskan sendiri kepada tim.

2. Selama proses pengkodean itu sendiri masalah bendera untuk pengembang. Memiliki skrip khusus yang terintegrasi dengan IDE pilihan Anda adalah cara yang keren untuk melakukan ini. Lihat tautan ini: http://goo.gl/MM6c4

3. Ikuti proses lincah dan pastikan bahwa tinjauan kode adalah bagian dari sprint

Inilah rencana 3 langkah saya:

1. Tembak para programmer
2. Sewa beberapa Insinyur Perangkat Lunak
3. ...
4. Keuntungan!

: D

Dalam semua keseriusan, jika mereka tidak percaya melakukan apa pun selain menulis kode, Anda memerlukan tim yang lebih baik. Seorang programmer tempat saya bekerja menggunakan direktori berbeda di komputer sebagai CM-nya. Kami bertarung dengan programmer mereka selama hampir setahun (karena perubahan akan memperkenalkan bug saat mereka menyalin dan menempel kode lama). Kami akhirnya memecat mereka.

1. Tunjukkan kepada mereka, ketika mereka melanggar aturan dasar.
2. Tunggu hingga mereka menghasilkan bug yang tidak dapat mereka lacak atau dihadapkan dengan permintaan fitur yang tidak dapat mereka terapkan karena kode mereka yang tidak fleksibel.
3. Ingatkan mereka tentang apa yang Anda katakan sebelumnya.
4. Biarkan mereka tenggelam dalam kotoran mereka sendiri untuk sementara waktu.
5. Luangkan waktu untuk memperbaiki kode yang dimaksud, mengisolasi bug / memberikan infrasturcutre untuk menghubungkan fungsionalitas baru. Luangkan waktu untuk menjelaskan apa yang Anda lakukan.

Atau, hal yang paling kejam tetapi sangat persuasif untuk dilakukan adalah membiarkan mereka mempertahankan basis kode yang ditulis dengan sangat buruk, diberi jadwal yang ketat. : D
Dan kemudian, untuk perubahan, biarkan mereka mempertahankan basis kode yang ditulis dengan baik, dengan jadwal yang ketat.

Secara umum, keengganan untuk mengadaptasi standar tertentu berarti kurangnya pengalaman dalam kerja tim.

Pada akhirnya orang hanya belajar dari kesalahan. JANGAN PERNAH memperbaiki masalah, yang didasarkan pada sikap keras kepala orang lain. Jika itu sangat penting untuk proyek (yaitu perusahaan Anda akan dituntut jika Anda tidak melakukannya dalam N hari), maka tunda dulu proyek itu.

Saya pikir Anda programmer tidak akan mengubah sikap mereka terhadap masalah yang telah Anda sebutkan sampai mereka menyadari bahwa hal-hal itu akan membawa manfaat atau keuntungan bagi mereka. Coba jelaskan kepada mereka mengapa Anda ingin mereka melakukan hal-hal ini. Bahkan lebih baik, biarkan mereka merasakan kelebihannya.

Sewa satu Insinyur Perangkat Lunak profesional. Dan kemudian api terlemah. Lalu perlahan-lahan gantikan mereka yang tidak bisa mengadopsi. Memiliki orang-orang seperti itu terkadang membawa lebih banyak kerugian daripada keuntungan dalam jangka panjang.

Gagasan utama di sini, bahwa profesional akan mulai melakukan sebagian besar pekerjaan, dan memecat orang lain tidak akan mengurangi sumber daya manusia yang berharga.

Agak kotor, tapi saya meninggalkan Kode Lengkap di kamar mandi selama beberapa bulan. Tidak yakin itu efektif, tetapi sepertinya ide yang bagus saat itu.

Jadi apa konsekuensi dari tidak mengikuti aturan dan penghargaan karena mengikuti aturan? Jika jawabannya sama - tidak ada - semoga berhasil mendapatkan traksi. Saya menyarankan pendekatan berjenjang. Pertama kumpulkan mereka dan diskusikan apakah mereka setuju dengan aturan. Langkah selanjutnya adalah memasukkannya dalam ulasan kode. Anda juga dapat mencoba wortel dan tongkat. Sesuatu seperti siapa pun yang meninggalkan file diperiksa semalam harus membawa donat ke pertemuan mingguan berikutnya. Wortel bisa siapa saja yang mengikuti aturan selama sebulan penuh mendapat akhir pekan di Vegas. Untuk dua.

Atau tembak pelaku terburuk dan biarkan sisanya mengeluarkan keringat.

Buat mereka menderita akibat yang ingin Anda hindari dengan menggunakan aturan-aturan itu, itu satu-satunya cara mereka benar-benar akan mengerti mengapa Anda bertanya, misalnya: membuat kekacauan kecil yang terkontrol yang harus mereka perbaiki.

Jika kru ini benar-benar mengalami kesulitan memeriksa perubahan, mengikuti pemisahan kekhawatiran dan bukan konstanta sulap pengkodean keras maka saya akan memecat seluruh kru dan menggantinya dengan programmer nyata ¹ yang benar-benar peduli dengan kerajinan mereka sesegera mungkin. Jadilah yang satu per satu atau secara massal yang tidak bisa saya katakan tetapi pelawak ini harus pergi.

Jenis pengkodean yang Anda gambarkan cocok untuk skrip dibuang, sekali pakai saja. Bukan bagaimana seseorang membangun aplikasi nyata. Jika mereka dibayar sebagai programmer profesional, maka tugas mereka untuk mengetahui hal semacam ini.

¹ Ini sering digunakan sebagai istilah lelucon untuk orang imajiner yang menulis kode mereka secara langsung dalam biner atau sesuatu yang sama konyolnya. Di sini, saya tidak bercanda. Saya seorang programmer yang cukup pemula dan saya tidak perlu diberitahu hal-hal ini karena saya peduli dengan kerajinan saya. Ini bukan programmer nyata yang Anda hadapi.

Pekerjaan manajer bukanlah menjadi teman karyawan, terkadang Anda harus menjadi penjahat. Menegakkan standar pengkodean dan melakukan, penolakan untuk mengikuti arsitektur yang diproksi, kegagalan untuk menggunakan alat yang ditentukan dll adalah saat-saat ketika Anda harus tidak populer.

Nyatakan kebijakan dengan jelas. Lakukan tinjauan kode formal dan periksa untuk melihat apakah kebijakan diikuti. Jangan izinkan mereka pindah ke tugas lain sampai semua masalah dari tinjauan kode diputuskan.

Jika kebijakan mengenai tidak melakukan kode, ini menyerukan peringatan tertulis jika mereka tidak dapat melakukannya ketika mereka diminta untuk melakukannya. Jika mereka tidak melakukan kode, sejauh yang Anda ketahui mereka belum menulis apa pun.

Jika mereka tidak membaik setelah diberi kesempatan yang masuk akal untuk meningkatkan, memecat mereka. Pengembang tidak profesional adalah hambatan dalam tim Anda, apa pun jenis kode yang mereka tulis. Mereka memengaruhi orang lain dengan kurangnya profesionalisme dan tidak bisa ditoleransi. Mereka bukan orang baik untuk dipertahankan dalam peristiwa apa pun. Pengembang yang baik melakukan kode mereka, pengembang yang baik mengikuti keputusan arsitektur bahkan jika mereka tidak setuju dengan mereka dan pengembang yang baik tidak melakukan hard code. Anda tidak akan kehilangan apa pun kecuali sakit kepala dengan menyingkirkan coder koboi.