Menilai individu dalam ulasan bertentangan dengan sistem paling sukses yang pernah saya gunakan, mungkin semuanya. Tetapi tujuan yang saya coba capai selama lebih dari 20 tahun adalah lebih sedikit bug dan peningkatan produktivitas per-insinyur-jam. Jika menilai individu adalah tujuan, saya kira ulasan dapat digunakan. Saya belum pernah melihat situasi di mana diperlukan, sebagai pekerja atau sebagai pemimpin.
Beberapa studi objektif (Fagan, dll.) Dan banyak kearifan populer menunjukkan bahwa hubungan teman sebaya memfasilitasi ulasan kode yang ditujukan untuk mengurangi bug dan meningkatkan produktivitas. Manajer yang bekerja dapat berpartisipasi sebagai pekerja, tetapi bukan sebagai manajer. Poin diskusi dicatat, perubahan untuk memuaskan pengulas umumnya adalah hal yang baik tetapi tidak diperlukan. Karenanya hubungan teman sebaya.
Setiap alat otomatis yang dapat diterima tanpa analisis lebih lanjut atau penilaian baik - serat di C, C ++, Java. Kompilasi teratur. Compiler benar-benar bagus dalam menemukan bug kompiler. Mendokumentasikan penyimpangan dalam pemeriksaan otomatis terdengar seperti dakwaan halus pemeriksaan otomatis. Arahan kode (seperti halnya Java) yang memungkinkan penyimpangan cukup berbahaya, IMHO. Bagus untuk debugging, untuk memungkinkan Anda mendapatkan inti permasalahan, dengan cepat. Tidak begitu baik untuk ditemukan di 50.000 kode blok non-komentar yang Anda dokumentasikan dengan buruk.
Beberapa aturan bodoh tapi mudah ditegakkan; default untuk setiap pernyataan switch bahkan ketika mereka tidak terjangkau, misalnya. Maka itu hanya kotak centang, dan Anda tidak perlu menghabiskan waktu dan menguji uang dengan nilai-nilai yang tidak cocok dengan apa pun. Jika Anda memiliki aturan , Anda akan memiliki kebodohan , mereka terkait erat . Manfaat aturan apa pun harus sebanding dengan kebodohannya, dan hubungan itu harus diperiksa secara berkala.
Di sisi lain, "Ini berjalan" tidak ada kebajikan sebelum ditinjau, atau pertahanan dalam peninjauan. Jika pengembangan mengikuti model air terjun , Anda ingin melakukan peninjauan saat pengkodean selesai 85%, sebelum kesalahan rumit ditemukan dan dikerjakan, karena peninjauan adalah cara yang lebih murah untuk menemukannya. Karena kehidupan nyata bukanlah model air terjun, kapan mengulasnya agak merupakan seni dan merupakan norma sosial. Orang yang benar-benar akan membaca kode Anda dan mencari masalah di dalamnya adalah emas murni. Manajemen yang mendukung ini secara berkelanjutan adalah mutiara di atas harga. Ulasan harus seperti checkin- awal dan sering .
Saya menemukan hal-hal ini bermanfaat:
1) Tidak ada perang gaya . Ke mana perginya kurung kurawal buka hanya akan dikenakan pemeriksaan konsistensi dalam file yang diberikan. Semua sama. Baiklah kalau begitu. Kedalaman indentasi Ditto ** dan lebar tab ** . Sebagian besar organisasi menemukan bahwa mereka membutuhkan standar umum untuk tab, yang digunakan sebagai ruang besar.
2) `Ragged
looking
teks yang tidak
line up is hard to read
untuk konten.`
BTW, K&R membuat indentasi lima (LIMA) ruang, sehingga banding ke otoritas tidak berharga. Bersikaplah konsisten.
3) Salinan file bernomor, tidak berubah, tersedia untuk umum untuk ditinjau harus ditunjuk selama 72 jam atau lebih sebelum peninjauan.
4) Tidak ada desain on the the fly. Jika ada masalah, atau ada masalah, perhatikan lokasinya, dan terus bergerak.
5) Pengujian yang melewati semua jalur dalam lingkungan pengembangan adalah ide yang sangat, sangat, sangat, baik. Pengujian yang membutuhkan data eksternal besar-besaran, sumber daya perangkat keras, penggunaan situs pelanggan, dll. Adalah pengujian yang menghabiskan banyak uang dan tidak akan menyeluruh.
6) Format file non- ASCII dapat diterima jika pembuatan, tampilan, edit, dll. Alat ada atau dibuat pada awal pengembangan. Ini adalah bias pribadi saya, tetapi di dunia di mana OS dominan tidak dapat keluar dengan caranya sendiri dengan kurang dari 1 gigabyte RAM, saya tidak dapat mengerti mengapa file kurang dari, katakanlah, 10 megabyte harus menjadi apa pun selain ASCII atau format lain yang didukung secara komersial. Ada standar untuk grafik, suara, film, dapat dieksekusi, dan alat yang menyertainya. Tidak ada alasan untuk file yang berisi representasi biner dari sejumlah objek.
Untuk pemeliharaan, refactoring, atau pengembangan kode yang dirilis, satu kelompok rekan kerja saya telah menggunakan ulasan oleh satu orang lain, duduk di layar dan melihat perbedaan lama dan baru , sebagai pintu gerbang ke cabang check-in. Saya menyukainya, murah, cepat, relatif mudah dilakukan. Jalan-jalan untuk orang-orang yang belum membaca kode di muka dapat mendidik untuk semua tetapi jarang memperbaiki kode pengembang.
Jika Anda terdistribusi secara geografis, melihat perbedaan di layar saat berbicara dengan orang lain yang melihat hal yang sama akan relatif mudah. Itu mencakup dua orang yang melihat perubahan. Untuk grup yang lebih besar yang telah membaca kode yang dimaksud, beberapa situs tidak jauh lebih sulit daripada semua dalam satu ruangan. Beberapa kamar dihubungkan oleh layar komputer bersama dan kotak jongkok bekerja sangat baik, IMHO. Semakin banyak situs, semakin banyak manajemen rapat diperlukan. Seorang manajer sebagai fasilitator dapat memperoleh penghasilan mereka di sini. Ingatlah untuk terus memberikan polling ke situs-situs yang tidak Anda kunjungi.
Pada satu titik, organisasi yang sama memiliki pengujian unit otomatis yang digunakan sebagai pengujian regresi. Itu sangat bagus. Tentu saja kami kemudian mengubah platform dan tes otomatis tertinggal. Review lebih baik, seperti yang ditulis oleh Agile Manifesto , hubungan lebih penting daripada proses atau alat . Tetapi begitu Anda mendapat ulasan, tes unit otomatis / uji regresi adalah bantuan terpenting berikutnya dalam menciptakan perangkat lunak yang baik.
Jika Anda dapat mendasarkan tes pada persyaratan , well, seperti yang dikatakan wanita di "When Harry Met Sally" , saya akan mendapatkan apa yang dia miliki!
Semua ulasan harus memiliki tempat parkir untuk menangkap persyaratan dan masalah desain pada tingkat pengkodean di atas. Setelah sesuatu diakui sebagai milik di tempat parkir, diskusi harus berhenti di ulasan.
Kadang-kadang saya pikir review kode harus seperti review skematik dalam desain perangkat keras - sepenuhnya publik, menyeluruh, tutorial, akhir proses, gateway yang setelah itu akan dibangun dan diuji. Tetapi tinjauan skematis merupakan hal yang berat karena mengubah benda fisik mahal. Tinjauan arsitektur, antarmuka, dan dokumentasi untuk perangkat lunak mungkin harus kelas berat. Kode lebih cair. Ulasan kode harus lebih ringan.
Dalam banyak hal, saya pikir teknologi adalah tentang budaya dan harapan seperti halnya alat khusus. Pikirkan semua improvisasi " Keluarga Swiss Robinson " / Flintstones / McGyver yang menyenangkan hati dan menantang pikiran. Kami ingin barang kami bekerja . Tidak ada jalan tunggal untuk itu, tidak ada "kecerdasan" yang entah bagaimana bisa diabstraksikan dan diotomatisasi oleh program AI tahun 1960-an .