Peninjauan Kode Lanjutan dan Praktik Pengujian Unit

Sebagai pemimpin tim yang mengelola sekelompok pengembang tanpa pengalaman (dan tidak perlu melihat) dalam tinjauan kode dan pengujian unit, bagaimana Anda bisa memajukan tinjauan kode dan praktik pengujian unit?

Bagaimana Anda akan membuat cara agar ulasan kode dan pengujian unit agar secara alami sesuai dengan alur pengembang?

Salah satu hambatan dari kedua bidang ini adalah "kami selalu ketat pada garis waktu, jadi tidak ada waktu untuk meninjau kode dan pengujian unit".

Perlawanan lain untuk tinjauan kode adalah bahwa saat ini kami tidak tahu bagaimana melakukannya. Haruskah kita meninjau kode pada setiap check-in, atau meninjau kode pada tanggal yang ditentukan?

Apakah anggota tim Anda benar-benar setuju bahwa ulasan kode dan pengujian unit adalah Hal Baik, hanya saja tidak ada waktu untuk ini?

Atau apakah mereka hanya mencoba menolak ide dengan alasan ini?

Dalam kasus pertama, solusinya adalah Mulai Melakukannya Sekarang . (Oke, jika Anda berada di hari-hari terakhir sebelum tonggak utama, mungkin Anda bisa menunggu sampai setelah - tetapi tidak lebih.) Kami memiliki situasi itu di tempat kerja saya sebelumnya, di mana saya adalah Insinyur Kualitas, bertanggung jawab untuk meningkatkan praktik pengkodean dan kualitas keseluruhan. Kami terus menunda permulaan ulasan kode hingga minggu depan. Suatu hari saya menyadari bahwa kita telah melakukan ini selama sebulan atau lebih, dan mungkin akan berlanjut sampai akhir kali kecuali saya mencoba sesuatu yang berbeda. Jadi saya mengumumkan review kode pertama untuk minggu itu. Saya mengatakan kepada mereka "tidak masalah jika itu tidak sempurna, atau jika kita belum tahu apa yang harus dilakukan - kita akan mulai melakukannya, lihat bagaimana hasilnya dan perbaiki hal-hal yang kita pelajari". Itu berhasil, setidaknya sampai saya meninggalkan perusahaan.

Dalam kasus kedua, Anda mungkin perlu lebih banyak pendidikan dan diskusi terbuka dengan tim. Diskusikan masalah kualitas kode, tanyakan kepada mereka apa yang mereka lihat sebagai masalah dalam proses pengembangan (atau ketiadaan) / dalam kode / pengujian dll. Dan bertukar pikiran bersama tentang bagaimana menyelesaikannya . Tujuan utamanya tidak harus melakukan tinjauan kode - mereka hanya sarana, sedangkan tujuannya adalah untuk meningkatkan proses pengembangan dan kualitas outputnya. Bisa jadi ternyata ada masalah lain yang lebih menyakitkan yang bisa diperbaiki lebih mudah, membawa manfaat lebih cepat; kemudian ambil ini dulu. Mereka bahkan bisa menjadi perubahan sepele di lingkungan atau proses; semua ini akan meningkatkan moral tim, membangun rasa saling percaya dan membantu ikatan tim.

Intinya adalah, Anda tidak dapat memaksakan kualitas pada siapa pun - Anda hanya dapat menghilangkan hambatan untuk menciptakan kualitas . Dengan menerapkan aturan ketat dan praktik wajib tanpa konsensus tim sebelumnya , Anda dapat mengasingkan tim dan pada akhirnya mencegah peningkatan kualitas yang Anda tuju. OTOH dengan diskusi terbuka dan mengincar kesepakatan tentang apa masalah yang paling mendesak bagi tim dan bagaimana memperbaiki situasi, Anda lebih mungkin mendapatkan dukungan tim. Ini akan membuat perbedaan penting dalam menjaga dorongan peningkatan kualitas dalam jangka panjang.

Masalah klasik. Tidak pernah cukup waktu untuk melakukannya dengan benar, selalu cukup waktu untuk mengulang pekerjaan. Sampai orang mulai melakukan praktik terbaik, tampaknya tidak akan pernah ada cukup waktu untuk melakukan praktik terbaik. Terutama karena kemenangan tidak terlihat oleh orang-orang di luar pembangunan.

Kunci untuk tinjauan kode adalah Anda ingin meninjau kode sesedikit mungkin, sesegera mungkin. Dengan begitu lebih mudah mendapatkan waktu untuk memeriksanya, kode itu segar di pikiran orang, dan menerapkan perbaikan yang disarankan akan lebih mudah. Yang paling ekstrem, Anda ingin meninjau setiap check-in. Alat yang bagus untuk mengotomatisasi ini adalah http://code.google.com/appengine/articles/rietveld.html . Ini adalah varian alat yang digunakan Google secara internal untuk memaksa peninjauan kode terjadi pada setiap check-in.

Tantangan tinjauan kode dijelaskan beberapa dekade yang lalu dalam klasik The Psychology of Computer Programming . Masalahnya adalah bahwa pemrogram cenderung mengikat citra diri mereka dengan keterampilan pemrograman mereka. Yang berarti bahwa setiap kali programmer dihadapkan dengan bukti bahwa keterampilan mereka tidak sampai mati, ada kecenderungan untuk menganggapnya pribadi. Ini dapat menyebabkan konflik serius. Jika Anda mengambil Rapid Development klasik Steve McConnell, ia menawarkan sejumlah saran untuk cara mengatur proses peninjauan kode yang mengurangi kemungkinan konflik tersebut. (Elemen kuncinya adalah memastikan bahwa manajemen tidak pernah terlibat dalam proses tersebut.) Perhatikan bahwa ini mengurangi kemungkinan konflik, tetapi tidak mencegah terjadinya konflik.

Yang mengatakan, manfaatnya jauh lebih besar daripada biaya. Hanya mengutip satu metrik, IBM menemukan bahwa tinjauan kode adalah dolar untuk dolar cara paling efektif untuk menemukan dan menghilangkan bug. Ini tidak menggantikan departemen QA Anda dengan cara apa pun. Tapi itu menghasilkan masalah yang jauh lebih sedikit bagi mereka untuk ditemukan. Dan itu sebelum Anda mendapatkan manfaat yang melibatkan seberapa cepat belajar, menyebarkan pengetahuan, dll.

Jangan beri mereka pilihan. Buat pengujian dan ulasan wajib. Jika mereka tidak bekerja sama, Anda dapat menggunakan beberapa taktik garis keras seperti menolak promosi yang belum diuji atau tidak ditinjau. Jika semuanya benar-benar buruk, tembak pelaku terburuk Anda.

Saya telah melihat kasus di mana tim selalu terlambat karena mereka selalu memperbaiki bug yang seharusnya ditangkap oleh pengujian dan ulasan. Sedikit lebih banyak pekerjaan di depan menghemat jauh lebih banyak dalam jangka panjang, dan semakin cepat Anda membawa tim Anda, semakin baik tim Anda akan mendapatkannya.

Sayangnya, ini membutuhkan waktu untuk benar-benar melihat hasilnya. Untuk mendorong praktik, Anda dapat mulai memetakan tingkat laporan bug, berarti waktu untuk perbaikan bug dan tingkat implementasi fitur. Saya biasanya menemukan bahwa setelah sekitar enam bulan pengujian dan ulasan, metrik tersebut akan meningkat dan tim Anda akhirnya akan mendapatkannya.

Memperkenalkan tdd melawan kehendak para pengembang adalah sulit. Ini adalah cara yang sulit untuk belajar mencintai tdd.

Karena tdd paling efektif dalam bidang hijau (atau sulit, mahal, tidak efisien jika tes tidak dilanjutkan setelahnya) saya akan mulai dengan tim kecil yang mengimplementasikan sesuatu yang baru. Jika Anda menemukan dua develloppers di tim yang kurang menentang tdd daripada yang lain, itu adalah titik awal yang baik. perlu diingat bahwa produktivitas para pengembang-tdd akan menderita sementara mereka tidak berpengalaman dengan tdd.

Pengembangan tdd ini adalah titik awal yang baik untuk codereview. Diskusikan bagaimana tdd memengaruhi arsitektur program dan bagaimana hal itu memudahkan softwaremaintanance.