Saat ini, banyak orang menggunakan ulasan kode dalam pengembangan. Latihan itu bermanfaat, perlu. Bahkan jika Anda tidak melakukan review, Anda mungkin tahu apa itu.

Ada banyak alat untuk meninjau kode di pasar dengan skenario, rekomendasi, dan aturan penggunaan siap pakai. GitHub, Phabricator, FishEye / Crucible, GitLab, Bitbucket, Upsource - daftarnya terus bertambah. Di Badoo, kami juga bekerja dengan mereka pada satu waktu: di artikel saya sebelumnya saya menceritakan kisah kami tentang ulasan kode dan bagaimana kami menemukan penemuan "sepeda" kami sendiri - solusi Codeisok .

Ada banyak informasi, Anda dapat google banyak artikel tentang ulasan kode dengan contoh nyata, praktik, pendekatan yang berbicara tentang seberapa baik, seberapa buruk, bagaimana melakukannya, dan bagaimana - Anda tidak perlu, apa yang perlu Anda pertimbangkan, dan apa yang tidak perlu, dll. e. Secara umum, tema ini "tersedot ke tulang."

Itulah sebabnya bagian gunung es yang lain mungkin tidak diperhatikan.

Saya harap Anda akan menganggap serius hal-hal yang akan saya uraikan dalam artikel ini, dalam beberapa kasus sengaja dibesar-besarkan. Tinjauan, seperti proses lainnya, membutuhkan implementasi yang hati-hati dan disengaja, sementara pendekatan "Kami akan melakukan seperti yang lainnya, jika saja" tidak hanya bisa gagal, tetapi bahkan membahayakan.

Setelah membaca pengantar ini, Anda mungkin memiliki pertanyaan: apa yang rumit tentang ulasan kode? Intinya agak sepele. Selain itu, sebagian besar alat yang tercantum di atas segera dan menawarkan ulasan aliran (di luar kotak: set, komit / mulai - dan pergi!).

Tetapi latihan menunjukkan bahwa semuanya tidak sejelas kelihatannya pada pandangan pertama. Termasuk karena kesederhanaan imajiner proses. Ketika semuanya berjalan dan berjalan, ada risiko bahwa manajer akan tenang dan berhenti tenggelam ke dalam proses, meneruskannya ke pengembang. Dan mereka akan mengikuti proses, atau melakukan sesuatu yang merugikan penyelesaian masalah yang dirancang untuk dipecahkan oleh proses peninjauan. Manajer mungkin tidak menyadari bahwa ada sesuatu yang salah, karena tidak menetapkan aturan atau memaksakan aturan. Meskipun sangat penting bagi bisnis untuk menyelesaikan masalah secepat mungkin, tanpa membuang waktu untuk kegiatan yang tidak direncanakan .

Suatu ketika, ketika saya bekerja di perusahaan lain, saya sangat tenggelam oleh percakapan tentang ulasan kode dengan salah satu pengembang terkemuka. Itu adalah p1lot . Mungkin salah satu pembaca sudah mengenalnya (p1lot, halo :)). Dia saat ini bekerja dengan kami di Badoo, yang bagus.

Jadi, PILOT kemudian berkata: "Hal yang paling sulit bagi saya dalam proses peninjauan adalah kompromi dan lewati tugas yang sudah selesai dan bekerja dengan benar lebih lanjut, bahkan jika saya tahu cara lain untuk menyelesaikannya dan bahkan jika saya lebih suka metode saya." Menurut pendapat saya, ini adalah pemikiran utama. Dan pesan utama dari seluruh artikel saya entah bagaimana berkisar dalil ini.

Mengapa saya memerlukan proses peninjauan kode?

Apakah Anda memiliki ulasan di perusahaan Anda? Apakah Anda melakukannya dengan benar? Saya memiliki tes yang dapat membuat Anda ragu.

Anda hanya perlu menjawab tiga pertanyaan:

1. Berapa lama tinjauan kode diperlukan untuk tugas rata-rata (bola dalam ruang hampa)?
   
2. Bagaimana Anda meminimalkan waktu ulasan?
   
3. Bagaimana Anda menentukan apakah peninjauan tugas tertentu dilakukan dengan benar?
   

Jika Anda tidak memiliki jawaban yang jelas untuk beberapa (atau semua) pertanyaan, jika Anda meragukan jawaban Anda, maka saya berani berasumsi bahwa ada sesuatu yang salah.

Jika Anda tidak tahu berapa lama untuk meninjau, dan tidak terus-menerus menguranginya, lalu bagaimana Anda merencanakannya? Mungkinkah pemain, yang melakukan review selama empat jam, tidak minum teh setengah kali ini? Apakah mungkin untuk memastikan bahwa waktu minum teh tidak meningkat dari satu tugas ke tugas lainnya? Atau mungkin pengulas tidak melihat kode sama sekali, tetapi cukup mengklik "Kode tidak apa-apa"?

Dan, bahkan jika peninjauan dilakukan dengan itikad baik, bagaimana kita dapat memastikan bahwa dengan pertumbuhan basis kode dan perusahaan, waktu untuk menyelesaikan tugas tidak meningkat? Setelah semua, manajemen, sebagai suatu peraturan, mengharapkan bahwa proses akan mempercepat, bukan memperlambat.

Jika jawaban untuk pertanyaan ketiga tidak langsung terlintas dalam pikiran, maka masuk akal untuk bertanya satu lagi. Apakah Anda tahu mengapa Anda benar-benar membutuhkan proses ini? Karena "begitu adat untuk semua orang besar"? Mungkin Anda tidak membutuhkannya sama sekali?

Jika Anda bertanya kepada prospek dan pengembang Anda tentang apa yang dimaksud dengan ulasan kode "yang benar", Anda akan sangat terkejut melihat betapa berbedanya hal-hal yang Anda dengar. Jawaban dapat bervariasi tergantung pada pengalaman pribadi, kepercayaan, kepercayaan pribadi dalam kebenaran atau kesalahan hal-hal, dan bahkan pada tumpukan teknologi yang digunakan dan bahasa pengembangan.

Ingat alat yang siap pakai untuk tinjauan kode, menawarkan pendekatan dan alur mereka sendiri? Sebagai contoh, saya bertanya-tanya bagaimana para pengembang alat ini akan menjawab pertanyaan itu. Apakah jawaban mereka tentang "kebenaran" ulasan akan berkorelasi dengan jawaban karyawan Anda? Tidak yakin Terkadang saya sedih melihat bagaimana seseorang mengimplementasikan alat ulasan di rumah, tidak meragukan bahwa mereka diperlukan. Entah orang melakukannya "untuk pertunjukan", atau untuk melaporkan bahwa "mereka menerapkan tinjauan kode, semuanya baik-baik saja." Dan pada akhirnya mereka melupakannya.


Saya tidak ingin menjadi Cap, tapi tetap saja. Saat berkomunikasi dengan karyawan, perhatikan jawaban seperti "Karena sudah mapan" atau "Ini praktik terbaik, semua orang melakukannya". Anda sendiri sadar bahwa Anda tidak perlu menerapkan proses tanpa berpikir tanpa memahami mengapa hal itu diperlukan. Setiap proses harus dibenarkan dan diimplementasikan (jika perlu) disesuaikan dengan kebutuhan bisnis dan proyek, serta untuk masalah yang benar-benar ada dan yang benar-benar ingin Anda pecahkan. Kultus muatan di perusahaan dengan budaya rekayasa yang baik bukan milik.

Oleh karena itu, penting bagi manajer untuk menyampaikan kepada orang-orang ulasan kode yang “benar” yang perlu tepat dalam proyeknya. Dan sebelum ini, tentu saja, kriteria "kebenaran" harus dirumuskan untuk Anda sendiri, pilih alat yang tepat dan buat aturan yang sesuai. Dan sudah ada yang dekat dengan kontrol.

Ulasan kode salah

Jadi apa proses yang benar? Mari kita perbaiki. Di bawah ini akan ada banyak alasan pribadi saya, dan bagi mereka yang tidak sabar untuk mengetahui apa yang saya tulis semua ini, saya mengusulkan untuk segera pergi ke bagian "Tinjauan kode yang baik".

Kepada mereka yang tinggal, saya ucapkan terima kasih dan saya tetap mengusulkan untuk menentukan sendiri kebenaran ulasan, berdasarkan kebutuhan proyek Anda, dengan hati-hati mempertimbangkan segalanya. Dan saya hanya mencoba membantu Anda dengan ini.

Untuk menyoroti hal-hal penting dan perlu bagi diri Anda sendiri dalam proses apa pun, akan bermanfaat untuk memulai dengan memotong hal-hal yang jelas tidak perlu yang merusak budaya rekayasa. Jadi mari kita lakukan.

Berbagi pengetahuan

Untuk pertanyaan "Mengapa saya perlu proses peninjauan kode?" Saya telah mendengar jawaban " Untuk berbagi pengetahuan " berkali-kali. Memang hal yang bermanfaat dan perlu. Dan banyak yang setuju bahwa penting untuk memiliki proses dalam tim untuk pertukaran pengetahuan dan keahlian. Tetapi apakah Anda yakin ulasan kode sesuai untuk ini?


Saya telah berulang kali bertanya kepada orang-orang apa yang mereka maksud dengan "berbagi pengetahuan." Dan sebagai tanggapan saya mendengar hal yang berbeda.

Pertama, ini adalah demonstrasi kepada pendatang baru (dalam tim atau komponen yang terkena dampak) dari aturan dan praktik yang diterima: ini adalah kebiasaan bagi kami untuk melakukan ini, dan kami tidak melakukannya, itu sebabnya.

Kedua, ini adalah tampilan baru dari seorang pemula (lagi-lagi dalam tim atau komponen yang terpengaruh) tentang bagaimana hal-hal biasa dilakukan. Tiba-tiba mereka dilakukan dengan tidak efisien, dan akankah orang baru membantu menemukan ini?

Ketiga, ini hanya pengantar untuk beberapa bagian dari kode. Memang, jika di masa depan reviewer menghadapi dengan kebutuhan untuk mengubah bagian kode ini, itu akan jauh lebih mudah baginya.

Mari kita membahas semua poin dan mencoba menilai seberapa relevan mereka dalam proses peninjauan.

Ulasan kode sebagai alat pelatihan untuk pemula

Dalam hal ini, kita berbicara terutama tentang skenario seperti itu: seorang pemula diberikan tugas, ia melakukan itu, dan kemudian anggota tim yang berpengalaman (pemilik komponen) menunjukkan kesalahan yang ia buat. Proses ini penting dan perlu, saya tidak berpendapat - pemula harus entah bagaimana menunjukkan aturan yang diterima dalam tim.

Tapi jujur ​​saja: bukankah sudah terlambat? Tidakkah lebih benar untuk memberi tahu pemula tentang aturan-aturan ini sebelum mengakuinya pada kode? Lagi pula, harga kesalahan sangat tinggi - jarang pemula segera bekerja seperti yang Anda butuhkan. Jadi, tugas akan kembali dan kembali untuk revisi. Jadi, produk akan tersedia untuk pengguna lebih lambat dari yang seharusnya.

Ternyata dalam proses yang durasinya sulit untuk dievaluasi, kami menambahkan satu lagi, biaya waktu yang bahkan lebih tidak dapat diprediksi. Dengan demikian, kami menambah waktu yang diperlukan untuk mengirimkan tugas kepada pengguna dengan jumlah yang bahkan lebih tidak diketahui.

Tentu saja, kadang-kadang pelatihan pemula melalui proses kerja memiliki hak untuk eksis. Namun terkadang kita tidak memikirkan kekurangan dari pendekatan yang sudah menjadi kebiasaan. Dan untuk membuat kesalahan di sini bukan hanya mudah, tetapi sangat mudah.

Misalnya, jika perusahaan tidak memiliki proses pelatihan dan pembinaan yang efisien, manajer terpaksa "membuang ke dalam air" seorang pendatang baru. Pada saat yang sama, yang terakhir tidak punya pilihan: Anda harus "berenang" atau meninggalkan perusahaan. Seseorang benar-benar belajar dari situasi seperti itu, dan seseorang tidak berdiri. Saya pikir banyak yang mengalami masalah serupa sepanjang jalur profesional mereka. Pesan saya adalah bahwa waktu yang paling berharga dapat dihabiskan secara tidak optimal karena fenomena ini. Seperti halnya proses mengadaptasi karyawan baru dalam suatu tim, itu mungkin tidak optimal. Hanya karena tidak ada yang memiliki tangan untuk mengatur proses yang efektif untuk memperkenalkan karyawan baru ke dalam tim, dan manajer berpikir bahwa pendatang baru akan mempelajari segalanya pada tahap tinjauan kode. Tetapi pada kenyataannya, ini adalah dua proses yang berbeda, sangat perlu dan penting.

Tentu saja, bahkan di bawah kondisi bahwa aturan awalnya dijelaskan kepada pemula dan bahwa perusahaan memiliki proses pelatihan lainnya, proses mengadaptasi pemula perlu entah bagaimana dikendalikan. Tinjauan adalah salah satu proses yang dapat membantu. Tetapi kontrol dan pelatihan adalah dua hal yang berbeda, bukan? Selain itu, semua anggota tim perlu kontrol, dan bukan hanya pemula. Lagipula, kita semua bisa membuat kesalahan, melupakan perjanjian dan entah bagaimana mempengaruhi bagian dari sistem yang dimiliki seluruh tim (dalam hal ini, kode).

Kesimpulan apa yang bisa dibuat? Proses yang dijelaskan di atas bertujuan untuk mencapai tujuan yang berbeda: bukan untuk pelatihan, tetapi untuk kontrol. Dan kontrol yang sama ini diperlukan tidak hanya untuk pemula, tetapi untuk tim secara keseluruhan.

Semua ini mudah dirumuskan dalam tesis berikut: "Diperlukan peninjauan kode untuk memantau kepatuhan terhadap perjanjian dan aturan umum oleh semua anggota tim ." Dan pelatihan pemula dalam hal ini tidak lebih dari pengganti tiruan dari tujuan yang hanya akan membingungkan orang dan mengarahkan proses ke arah yang berbeda.

Tetapi bahkan dengan kesimpulan ini, yang, tampaknya, dirumuskan dengan benar, kayu bakar dapat dipatahkan. Peninjauan kode adalah fase yang dimulai ketika kode sudah ditulis. Dan mungkin terjadi bahwa kode yang ditulis tanpa mengikuti aturan umum sangat mahal untuk menyesuaikan dengan pola umum. Tugas kami adalah memberi tahu kontraktor bahwa ada yang salah sedini mungkin. Dan oleh karena itu, saya berpendapat bahwa terkadang tinjauan kode bukanlah proses yang paling tepat untuk memantau kepatuhan dengan aturan umum. Dalam banyak kasus, pemeriksaan kepatuhan dapat dan harus ditransfer ke tahap sebelumnya.

Misalnya, Anda dapat memeriksa pemformatan kode di kait sistem kontrol versi (serta penggunaan kelas aman, pengaturan lokasi file dalam folder terkait, penggunaan dependensi eksternal dan perpustakaan pihak ketiga, dll.). Ini meminimalkan waktu yang diperlukan untuk peninjauan kode.

Melanjutkan percakapan tentang pelatihan pemula dalam proses review kode, mari kita menggambar analogi. Misalkan Anda memproduksi beberapa jenis produk, misalnya, kue. Misalkan Anda menerima pesanan kue untuk pernikahan VIP. Apakah Anda mempercayakan "review" kue yang sudah jadi kepada pemula? Apakah Anda siap untuk pembuat manisan baru untuk bertanggung jawab atas rasa malu atau keberhasilan seluruh toko roti di pernikahan ini? Atau mungkin Anda ingin dia pada tahap ini untuk berkenalan dengan aturan yang diadopsi oleh tim (bagaimana memanggang kue, menyiapkan krim dan bersikeras cranberry pada cognac)? Jelas, baik proses memperkenalkan pemula ke aturan dan kontrol di pihaknya adalah hal yang agak aneh pada tahap ini: kue telah dipanggang. Jadi mengapa kita dapat bertindak berbeda dengan fitur dan kode? Atau fitur yang kami luncurkan tidak membawa malu atau kesuksesan tim kami di mata pengguna dan pelanggan?

Anda dapat keberatan, mengatakan bahwa kami tidak menyiapkan tugas "untuk orang-orang penting" setiap hari dan bahwa sangat mungkin bagi seorang pemula untuk dipercayakan dengan tugas yang tidak terlalu mendesak atau tidak terlalu penting. Dan kamu akan benar.

Tapi pertama-tama, apa yang dipelajari seorang pemula dari tugas-tugas sepele di mana ada sedikit perubahan kode (dan perubahan-perubahan ini tidak di tempat-tempat kritis dan untuk bisnis mungkin tidak begitu penting, karena tugas itu mendesak)? Bagaimana dia bisa belajar membuat kue jika dia mencambuk krim sepanjang waktu? Transisi dari sederhana ke kompleks, tentu saja, diperlukan. Tetapi perlu untuk melakukan ini, dengan hati-hati mengendalikan proses. Pemula perlu diajarkan, tidak berhenti belajar sendiri.

Dan kedua, bahkan pendekatan yang tampaknya bermanfaat dan benar seperti itu dapat membahayakan perusahaan. Untuk memahami ini sangat sederhana, menggunakan metode membawa ke titik absurditas untuk membuat kesimpulan sesederhana dan dapat dimengerti mungkin.

Bayangkan bahwa kita secara terbuka menyatakan bahwa tugas-tugas yang diberikan oleh manajer produk diperlukan untuk melatih pendatang baru. Mengapa Dan sama dengan ulasan kode: bagaimanapun, kami mempercayakan beberapa tugas sederhana dan tidak mendesak kepada pemula sehingga mereka belajar bagaimana bekerja dengan cara yang sesuai dengan kebiasaan kami.

Apa yang bisa terjadi pada akhirnya? Seorang pemain yang bersemangat yang dengan setia melakukan pekerjaannya dan percaya bahwa segala yang dilakukannya harus dilakukan sebaik mungkin, akan mengambil alih proses pembelajaran. Dia dapat mengatur tugas untuk membuat beberapa implementasi alih-alih satu, sehingga nantinya dia dapat menunjukkan kepada siswa kelemahan dan kelebihan dari berbagai pendekatan. Dia dapat memberikan kuliah, membandingkan pendekatan dan praktik terbaik yang digunakan di perusahaan dan di luarnya. Dia dapat melakukan lebih banyak untuk mendidik pemula. Akibatnya, waktu yang dibutuhkan untuk menyelesaikan tugas akan meningkat, karena alih-alih berkembang, kami fokus pada pelatihan .

Dalam kasus review kode, karyawan yang bersemangat memulai diskusi panjang dalam komentar untuk review tentang manfaat dan bahaya implementasi tertentu, posting potongan kode dengan Stack Overflow, menunjukkan bahwa ada ide lain di kepala lain, memberikan tautan ke artikel dan buku yang harus siswa baca untuk memahami bahwa implementasinya tidak sempurna.

Ini adalah proses belajar normal yang bisa ada, tetapi harus dilakukan dengan benar. Dan itu jauh dari selalu layak untuk diintegrasikan ke dalam proses penyelesaian masalah bisnis. Karena ini adalah dua proses yang berbeda. Biarkan pemula membuat komponen kue yang berbeda, biarkan dia membuat beberapa pilihan, biarkan sesuatu merusak dan membuangnya. Biarkan seseorang yang lebih berpengalaman menunjukkan kepadanya bagaimana bertindak dan menceritakan kembali resep lama. Tetapi belajar "di jalur produksi" yang menghasilkan produk Anda untuk pelanggan bukanlah ide yang baik. Dan jika Anda sudah memutuskan ini, maka "pimpin pendatang baru" dengan pegangan, tidak membiarkannya mengganggu proses produksi selama pelatihannya.

Jika perusahaan Anda bukan lembaga, bukan sekolah, bukan sekolah teknis atau lembaga pendidikan lainnya, maka pelatihan bukanlah tanggung jawab langsung Anda. Bisnis telah mempekerjakan Anda untuk menyelesaikan masalah lain dan mencapai hasil lainnya.

Ngomong-ngomong, itu sebabnya kami tidak menambahkan fungsionalitas ke Codeisok untuk mengunggah gambar, mengetik, menyoroti kode dalam komentar, meskipun telah dan masih ada banyak permintaan untuk fitur-fitur tersebut. Kami mempromosikan gagasan bahwa tinjauan kode bukan blog pribadi, bukan messenger, dan bukan layanan pelatihan. Sebuah alat dibutuhkan untuk alat lainnya. Memang, untuk menunjukkan kelemahan dalam kode, komentar teks biasa lebih dari cukup.

Ulasan kode sebagai tampilan baru pada kode

Mari kita lanjutkan. Skenario "pertukaran pengalaman" berikut ini adalah ini: kita melakukan sesuatu dalam tim, mengamati perjanjian internal, dan mata kita kabur, dan kemudian orang baru datang (dari perusahaan lain atau dari komponen lain) - dan mungkin dia akan melihat kekurangan dalam diri kita. organisasi kerja.

Idenya bagus, kedengarannya masuk akal. Memang, bagaimana jika kita melakukan sesuatu yang salah?

Tetapi sekali lagi, kembali ke kehidupan tugas dan permulaan fase ulasan kode. Apakah sudah terlambat? Kue sudah dipanggang, kue diolesi dengan krim, mawar dilem. Harga kesalahan sangat tinggi. Dan kemudian kita menemukan bahwa di toko roti lain di kue tambahkan soda, disiram dengan jus lemon, untuk kemegahan. Jadi apa Apa yang harus dilakukan Merombak kembali?

Jelas tidak, karena: 1) kami selalu melakukannya tanpa soda, dan hasilnya tidak buruk; 2) mungkin saja pelanggan mengambil kue dari kami, dan bukan dari toko roti lain, karena mereka tidak menyukai rasa soda; 3) kue sudah siap, pernikahan sudah malam ini, dan kita tidak akan punya waktu untuk membuat kue baru.

Lalu mengapa ini semua? Perlu berbagi pengalaman. Diperlukan tampilan segar. Tetapi, bagi saya, pada tahap yang berbeda. Misalnya, sebelum membuat kue, Anda dapat menanyakannya kepada seorang pemula: “Dan bagaimana Anda melakukan ini sebelumnya? Mengapa metode ini lebih baik? " Dan, mungkin, ada baiknya memanggang beberapa kue dengan cara lama dan baru untuk mencoba pelanggan reguler kami dan mendapatkan pendapat mereka.

Penerapan praktik terbaik yang dipikirkan secara cermat yang terlihat dalam artikel atau laporan dapat membahayakan perusahaan dan produk. "Soda ditambahkan ke kue oleh semua pemain utama:" Bugle "," Tracebook "," Rile.ru "," Yumdeks ". Semua orang melakukannya. " Jadi apa Karena itu, haruskah Petya segera menangani pembuatan kembali tugas yang sudah siap?

Saya yakin tidak. Jika pada awalnya, sebelum menyelesaikan masalah, Anda tidak setuju bahwa "akan ada soda dalam kue", maka sangat rabun untuk meminta penambahannya pada tahap tinjauan kode. Bisnis Anda tidak memiliki tujuan "minum soda dalam kue." Jika kue Anda sudah laris manis, maka tidak masalah apakah mereka memiliki soda atau tidak.

Anda perlu memahami bahwa pertukaran pengalaman adalah proses lain yang tidak terikat pada tinjauan kode dengan cara apa pun. Ini mungkin terjadi lebih awal, nanti, atau paralel dengannya, tetapi berbeda. Anda dapat mengatur kelas master bersama dengan pesaing. Beberapa dari mereka mencoba mencuri resep super rahasia dan teknik mencambuk krim ultra modern dengan perforator. Seseorang berusaha memata-matai ide orang lain dan meningkatkan proses mereka dengan bantuan mereka. Tetapi aneh untuk melakukan ini pada konveyor yang berfungsi, pada tahap ketika produk Anda hampir siap, dan harga konversi sangat tinggi.

Bagaimanapun, kita berbicara tentang tahap peninjauan. Ulasan kode yang telah ditulis dan siap untuk langkah selanjutnya. Kode ini menunggu reviewer untuk mengklik tombol "Code is OK". Dan pelanggan Anda sama sekali tidak siap dengan kenyataan bahwa Anda akan menyiapkan kue panggang dengan koki baru untuk menunjukkan kepadanya bagaimana Anda membuat kue dan mendengarkan kritiknya.

Ulasan kode sebagai pengantar sepotong kode

Mungkin ini terlihat seperti bagian yang paling masuk akal dan dapat dimengerti, yang disetujui banyak orang. Skenario di sini dipahami sebagai berikut: satu programmer menulis kode tugas, sisanya melihatnya, mempelajarinya, dan sekarang mereka tahu cara bekerja dengannya. Dengan demikian, kami mengurangi risiko faktor bus : jika pengembang pergi, orang lain akan dapat berhasil bekerja dengan kodenya. Dan kami juga siap untuk fakta bahwa kode ini lain kali dapat "disentuh" ​​oleh orang lain, dalam hal ini ia sudah tahu cara bekerja dengannya.

Mari kita pikirkan apakah ini benar-benar berfungsi sebagaimana mestinya, dan apakah itu benar-benar membantu orang berbagi kompetensi dan pengetahuan tentang bagian spesifik dari kode.


Mari kita lihat situasi melalui mata orang yang menulis kode. , ?

, - (, , , ). , ? , . , , , .

, , , , . . , ?

, - . , - . , : , . , , , , .

, . , - ? — . , , .

, , , - . , . , , . , , , . . , - : , , .

? , , — . .

best practices « -» « , ». Jadi apa Best practices , , . , ? . , - , .

best practices, , . . — - , / — . « », « », « — , DI». ? ?

, , . , , — , .

, -, «», , - . ? - , , , . , . , .

-, « » «» , . -, . , , - , : ? . , , ( : , ).

, , . , , ( , ?).

— . , , . . ? bus factor , , - , .

, , , : , ?

— , , ?
— .
— ?
— .

. , ? , , , ? , , , — ?

, , , , , ?

, , , . , , .

, . , , , ( ), , ( , , , — , . .). , .

— , , , . ( , , . .) . — — .

Code review

« ?» . , , .

: - , , - , , . git blame , , , , , .

, , — , , , ( ) — . , , . . , ?


. ?

, , , . , , , . , - ( , ). , , — , , , .

, , . ? , .

, , , . , . , ? .

, , — , . ( )?

« - - » . , . .

: . .

, , . , . , .

, , — . , .

— . , . , . , .

, , :

? , , ? ? , , ? - , ? ? ? Dan sebagainya.

, . , . , .

, , . , , , . , , , .

, best practices, . , , , , . . , , . , .

,

. , , . - , , - .

, , . , API- . , bus factor, .

, . .

- ? , . , . null , « ». .

, . , ? ?

-

Tahap pemeriksaan ini juga sangat penting, karena ditujukan untuk meningkatkan dukungan kode terkenal.

Banyak orang mengerti apa arti kode rawatan, tetapi tidak semua orang bisa menjelaskan apa itu kode. Dan jika demikian, bagaimana kemudian mengatur tugas kepada tim untuk mempertahankan pemeliharaan ini? Oleh karena itu, saya percaya bahwa pengembang yang berpikir tentang bagaimana kodenya akan diuji, apalagi menguji kodenya sendiri dan menulis autotest untuk pengujian otomatis, secara alami akan berusaha untuk memastikan bahwa kodenya memenuhi sebagian besar kriteria pemeliharaan kode. Memang, tanpa ini, menulis autotest hampir tidak mungkin.

Rekomendasi umum untuk setiap perubahan kode juga dapat menjadi dekomposisi tugas yang benar . Semakin kecil jumlah kode yang melewati pipa semua proses dari ide hingga produksi, semakin mudah kode ini untuk memeriksa kepatuhan, menguji, menggabungkan dengan kode tugas lain dan mengunggah. Ulasan kode tidak terkecuali. Tugas dengan sejumlah besar baris yang diubah dalam banyak file sangat sulit untuk dibaca dan dipahami (dan mengingat ketergantungannya). Risiko dan biaya perbaikan bug bisa sangat tinggi.

Kesimpulan

Faktanya, itu saja. Keempat poin ini justru hal-hal yang perlu diperiksa pada tahap peninjauan. Mereka mudah diformalkan, mudah disampaikan kepada pelaku, yang berarti tidak sulit untuk merumuskan kriteria verifikasi dan memprediksi durasi. Otomatisasi dan cara lain untuk meminimalkan waktu peninjauan lebih dari mungkin.

Dan akhirnya, saya akan memberikan beberapa tips lagi.

Penting untuk diingat bahwa setiap pengembalian kode untuk revisi tidak memengaruhi kualitas implementasi dengan cara terbaik. Bahkan jika semua orang bermaksud baik. Dalam kasus review kode, kerjanya seperti ini: pengembang memperbaiki kode, tetapi tidak mengujinya secara menyeluruh seperti pada iterasi pertama (mengapa? Setelah semua, ia sudah memeriksa semuanya dan mengubahnya sedikit saja). Pengalaman menunjukkan bahwa sebagian besar situasi ini berubah menjadi bug tepat di tempat-tempat di mana ada koreksi berdasarkan hasil tinjauan kode. Inilah cara kerja psikologi manusia.

Di awal artikel, saya menyarankan Anda menjawab tiga pertanyaan tentang perlunya dan kebenaran ulasan. Sekarang Anda memiliki algoritma untuk membantu Anda menemukan jawabannya. Mengetahui langkah-langkah kontrol dan mempertimbangkan ukuran tugas, sangat mungkin untuk merencanakan waktu yang diperlukan untuk peninjauan kode, setiap kali mencoba menguranginya semakin banyak.

Menerapkan proses apa pun, penting untuk mengingat tujuan yang kita tetapkan untuk diri kita sendiri dan masalah yang ingin kita selesaikan. Maka akan jauh lebih mudah untuk memisahkan butiran dari sekam dan merumuskan kriteria terukur untuk mengevaluasi efektivitas. Dan Anda perlu merumuskannya untuk diri sendiri dan tim Anda, yang juga sangat perlu untuk menyelesaikan masalah yang muncul, tetapi dapat memahaminya dengan cara mereka sendiri.

Ada satu hal yang lebih penting: proses, aturan dan nilai-nilai yang adil untuk satu perusahaan mungkin tidak begitu berguna dan bekerja di perusahaan lain. Apa yang saya gambarkan sebagai contoh ulasan yang benar berfungsi di perusahaan kami. Kami mempromosikan pengembangan cepat, sering rilis, dan meninjau untuk setiap tugas. Pikirkan tentang bagaimana ini berlaku untuk proyek Anda, dan bahwa tinjauan adalah salah satu proses yang tidak bisa dibiarkan begitu saja.

Tetapi keputusan, tentu saja, tetap ada pada Anda.