🚶🏿 ⛩️ 🌁 Ulasan kode - meningkatkan proses 🖐🏻 🧔🏼 🖤

Bayangkan sebuah tim di mana tinjauan Kode tidak dilakukan. Pengembang menulis kode, dan tanpa memeriksa lakukan semua perubahan pada cabang utama. Setelah beberapa saat, fungsi memperluas atau bug ditemukan, mereka kembali ke kode asli, dan di sana semua variabel diberi nama dengan satu huruf, tidak ada mengikuti arsitektur, dan kualitasnya bukan yang terbaik. Kode berkualitas rendah ini akan terakumulasi dan suatu hari akan tiba saatnya ketika, dengan sedikit inovasi, proyek akan mulai berantakan: paling-paling, waktu pengembangan akan meningkat, paling buruk, dukungan untuk proyek menjadi tidak mungkin. Dan ini terlepas dari kenyataan bahwa pada suatu waktu tugas selesai dan semuanya bekerja dengan baik.

Bagaimana ini bisa dihindari?Jawaban atas pertanyaan dalam judul adalah ulasan Kode.

Peninjauan kode adalah pemeriksaan kode untuk kesalahan yang meningkatkan stabilitas dan kualitas kode.

Sekarang bayangkan tim di mana peninjauan Kode sudah berlangsung, tetapi dalam proses pengembang bersumpah di antara mereka sendiri, permintaan Tarik tidak disetujui untuk waktu yang lama, tugas mulai membeku. Proses dari awal tugas hingga kemunculannya dalam proyek ini diperluas, dan dengan itu semua pekerjaan diperlambat.

Permintaan tarik / permintaan Gabung adalah permintaan kepada tim proyek (orang atau sekelompok orang) untuk persetujuan dan penerapan perubahan pada cabang yang dipilih. Segera setelah permintaan Tarik dibuat, diskusi tentang kode tertulis dilakukan sebelum persetujuan. Perubahan dapat disarankan selama diskusi. Setelah disetujui, perubahan saat ini jatuh ke cabang yang dipilih.

Di bawah ini tercantum rekomendasi untuk membantu mempercepat tinjauan Kode dan meningkatkan kualitasnya.

Kami membagi pertanyaan menjadi tiga bagian dan mempertimbangkannya secara terpisah:

Bagian teknis: cara memeriksa kode dan apa yang harus dicari saat memeriksa?
Bagian komunikasi: bagaimana mencegah perselisihan dan mengurangi stres selama diskusi?
Bagian organisasi: apa yang dapat dilakukan untuk membuat proses peninjauan Kode menjadi efisien?

Bagian 1. Memeriksa kode

Jalankan kode penulis di rumah

Jalankan kode Anda sendiri dan lihat bagaimana perubahan bekerja bersama dengan kode lainnya. Ini membantu untuk menemukan area masalah yang tidak terlihat di antarmuka berbasis web. Cobalah untuk melihat kode secara komprehensif, hindari fokus hanya pada perubahan lokal. Jadi, Anda akan dengan cepat menemukan kode dan dengan cepat menemukan ketidakakuratan arsitektural, jika ada.

Ingat pengalaman pengguna

Perhatikan bagaimana perubahan dalam kode akan mempengaruhi pengguna akhir. Bahkan kode yang ditulis dengan indah dapat menjadi tidak berguna bagi pengguna, yang akan mengarah pada tugas tambahan, bug, dan juga dapat merusak reputasi perusahaan dan produk.

Kami melihat logika umum

Pengembang dapat berhasil memecahkan masalah mereka, tetapi merusak pekerjaan potongan kode lainnya. Untuk mencegah hal ini terjadi, lihat tidak hanya pada bagaimana tugas tertentu sedang diselesaikan, tetapi juga pada bagaimana perubahan akan mempengaruhi pekerjaan layanan lain, modul dan keseluruhan proyek secara keseluruhan.

Kami melihat arsitektur kode

Arsitektur kode menentukan berapa banyak waktu di masa depan yang akan kami habiskan untuk memperluas, menambah fungsionalitas, atau mengedit bug. Selain itu, arsitektur kode dapat memengaruhi potensi munculnya bug jika terjadi perubahan dalam proyek. Idealnya, memperluas dan menambah fungsionalitas baru tidak boleh mengarah pada refactoring.

Kami menulis lebih mudah

Perhatikan komplikasi ulang kode: semakin sederhana kodenya, semakin mudah dibaca dan lebih mudah dirawat. Singkirkan potongan kode yang rumit.

Multithreading

Jika proyek menyiratkan bekerja di beberapa utas, maka lihat apa yang terjadi jika ada keterlambatan selama pelaksanaan kode di salah satu utas, dan bagaimana kasus tersebut dikerjakan.

Optimalisasi berlebihan

Seperti yang ditulis klasik Donald Knuth, optimisasi prematur adalah akar dari semua kejahatan. Lebih baik hanya mengoptimalkan apa yang dibutuhkan di sini dan sekarang.

Kami menemukan kesalahan

Perhatikan bagaimana proyek akan berperilaku jika tidak mungkin untuk mengeksekusi baris kode, blok kode atau permintaan ke server. Seringkali, pengembang mengganggu eksekusi suatu fungsi tanpa output kesalahan, tetapi kasus-kasus seperti itu perlu diselesaikan.

Pemenuhan

Kode harus mematuhi perjanjian, gaya kode. Keseragaman kode bukanlah keinginan, tetapi suatu keharusan: kode seperti itu lebih mudah dipelihara, dan lebih mudah untuk memahami kode ini.

Nama dan penampilan

Ingat programmer lain yang harus memahami kode Anda. Kode yang dapat dibaca menyederhanakan dukungan lebih lanjut. Nama harus dapat dimengerti dan secara akurat menggambarkan kelas, objek, fungsi, dll.

Komentar Kode

Komentar harus menjawab pertanyaan: "mengapa ini dilakukan?", Dan bukan "bagaimana ini dilakukan?". Ingat ini.

Bagian 2. Kami membahas

Aturan diskusi utama: komentar apa pun harus ditujukan pada kode, dan bukan pada orang yang menulisnya. Ini bekerja berlawanan arah - jangan menganggap komentar sebagai kritik terhadap Anda secara pribadi. Tugas ulasan kode adalah membuat kode Anda lebih baik, karena apa yang Anda belum perhatikan mungkin diperhatikan oleh orang lain. Kolega dapat mengusulkan solusi alternatif, dan ini adalah potensi untuk pertumbuhan profesional. Penting untuk diingat bahwa pembahasan kode bukanlah kontes dalam kecerdasan atau pertunjukan "siapa yang tahu lebih banyak", oleh karena itu sarkasme, agresi tersembunyi, dan kekasaran tidak pantas di dalamnya.

Sebagai aturan, permintaan tarik dilakukan pada layanan hosting web khusus (github.com, bitbucket.org, gitlab.com, dll.), Di mana dimungkinkan untuk melihat perubahan dan meninggalkan komentar pada bagian kode tertentu.

Kami mematuhi perjanjian

Sekali lagi, kode harus mematuhi perjanjian. Namun, jika perjanjian semacam itu tidak ada, Anda tidak boleh meminta seorang kolega untuk menambahkan spasi atau indentasi dalam kode.
Di saat-saat yang kontroversial, Anda dapat menyetujui seluruh tim langsung dalam proses peninjauan kode, tetapi meminta untuk mengikuti aturan ini lebih baik di peninjauan kode berikut, sehingga akan lebih mudah bagi semua orang untuk menerimanya. Omong-omong, pedoman tertulis dalam gaya penulisan menghilangkan hampir semua perselisihan.

Kami menawarkan alternatif

Hindari pernyataan seperti "Anda salah ...", "mengapa, mengapa Anda menulis seperti itu?" dan lainnya, mereka dianggap sebagai kritik dan mengarah pada alasan. Lebih baik menulis komentar tentang isi kode, tanpa menggunakan identitas penulis. Juga cobalah untuk menghindari pesanan dan paksaan: orang tidak suka ketika seseorang memesannya, dan menganggap komentar tersebut negatif.

Anda dapat melanjutkan sebagai berikut:

Kami menulis apa yang salah dengan kode tersebut
Kenapa lebih baik tidak menulis
Kami menawarkan opsi alternatif

Kami tetap berada dalam kerangka masalah

Seringkali Anda dapat melihat komentar pada kode yang sebelumnya dan tidak menyentuh. Tidak perlu mengomentari apa yang tidak relevan dengan tugas tersebut. Pengeditan pihak ketiga mana pun dapat memakan banyak waktu, dan dapat dirasakan secara negatif, jadi lebih baik untuk melihat bagaimana seseorang menyelesaikan tugas saat ini, dan tidak memintanya untuk memperbaiki proyek.

Memuji

Jika Anda melihat solusi yang menarik atau keren, jangan ragu untuk memberikan pujian. Selain itu, merupakan motivasi yang hebat bagi kolega Anda untuk terus menulis kode yang baik di masa depan.

Semua komentar sama.

Sering terjadi bahwa satu programmer secara teknis tahu lebih banyak daripada yang lain, sebagaimana dibuktikan oleh gradasi tim junior, menengah, senior. Tidak perlu menyoroti komentar dari satu kelompok sebagai lebih penting. Ini merendahkan pendapat beberapa pengembang, yang dapat menyebabkan ketidakpedulian dan partisipasi formal dalam tinjauan kode. Ketika pendapat semua orang sama pentingnya, peninjauan kode lebih produktif.

Nyatakan pikiran Anda dengan jelas

Untuk komunikasi yang produktif, tulis sejelas mungkin dan jelaskan setiap detail. Setiap orang memiliki tingkat pengetahuan yang berbeda, dan sejauh ini belum ada yang belajar membaca pikiran.

Menanyakan pertanyaan

Jangan ragu untuk bertanya kepada kolega Anda mengapa opsi yang mereka usulkan lebih baik daripada pilihan Anda saat ini. Ini adalah kesempatan bagus untuk mempelajari sesuatu yang baru dan tumbuh secara profesional.

Kami menyelesaikan konflik

Kebetulan seseorang tidak menerima semua argumen dan tidak dapat menawarkan argumennya sendiri, menolak untuk melakukan sesuatu. Beberapa kiat praktis untuk kasus ini:

Sebagian besar situasi konflik dapat diselesaikan dengan berbicara langsung, dengan nada bersahabat.
Anda dapat mengakui, karena Anda tidak dapat menulis kode saat Anda berperang.
Anda dapat menarik seluruh tim dan memutuskan bersama bagaimana cara terbaik untuk menulis kode.
Dalam ulasan kode saat ini, biarkan semuanya apa adanya, dan buat masalah kontroversial memisahkan tugas untuk refactoring, yaitu tugas, karena kata-kata "lalu perbaiki", sebagai suatu peraturan, tidak pernah hidup kembali.

Bagian 3. Memperbaiki proses

Kami menggambarkan apa yang mereka lakukan

Kami menjelaskan esensi tugas di tajuk permintaan tarik (atau membuat komentar terpisah) dan langkah apa yang telah diambil untuk menyelesaikannya.

Bagilah permintaan tarik menjadi beberapa bagian

Sebagian besar akan diawasi untuk waktu yang lama, dibahas untuk waktu yang lama dan diperbaiki untuk waktu yang lama. Bagilah kode menjadi beberapa bagian logis kecil - dengan cara ini proses akan berjalan lebih cepat.

Balas ke semua komentar

Dianjurkan untuk menanggapi setiap komentar sehingga tim tidak memiliki ambiguitas. Pengembang lain harus memahami bahwa Anda membaca komentar mereka, melakukan pekerjaan yang diperlukan, dan membuat koreksi. Terus-menerus membuka permintaan tarik dan melihat apa yang sudah diperbaiki dan apa yang tidak, sangat tidak nyaman dan menghabiskan waktu.

Cari semua?

Ada berbagai pendekatan - untuk mencari yang maksimal dari yang mungkin atau pertama mengomentari momen arsitektur penting, dan setelah koreksi, perhatikan hal-hal kecil.
Kedua metode memiliki hak untuk hidup. Saya percaya bahwa opsi kedua lebih memakan waktu: bayangkan bahwa setelah koreksi Anda perlu meninjau kembali kode sepenuhnya, komentar dan tunggu koreksi lagi. Jauh lebih cepat untuk dengan hati-hati membaca kode sekali, meninggalkan komentar dan kemudian memeriksa koreksinya.
Jika ada ketidakakuratan arsitektural dan jelas bahwa kesalahan kecil itu sendiri akan hilang setelah memperbaiki arsitektur, Anda tidak perlu membuang waktu untuk mengomentari perincian di bagian kode ini.

Menunggu semua orang?

Anda tidak bisa menunggu sampai semua orang menyetujui permintaan tarikan dan menyetujui bahwa persetujuan 80% dari pengulas cukup untuk menutup tugas. Ini akan mempercepat masuknya kode ke cabang utama, yang tidak diragukan lagi lebih menguntungkan untuk proses bisnis, tetapi dapat menyebabkan ketidaksepakatan dalam tim dan ketidakpedulian terhadap tinjauan kode.

Opsi kedua adalah menunggu persetujuan dari semua pengembang yang terlibat. Kualitas kode akan meningkat, tetapi proses itu sendiri akan melambat secara signifikan. Pilihan yang mendukung kecepatan atau kualitas, setiap tim harus membuat pilihan mereka sendiri.

Hal-hal kecil

Jika tidak ada komentar serius pada kode, maka Anda tidak perlu menunggu sampai semua ketidakakuratan kecil dihapus. Mereka dapat ditunjukkan dalam komentar dan segera menyetujui permintaan tarik - penulis kode akan merasa lebih tenang, kesetiaannya kepada tim akan meningkat, ia akan merasa bahwa ia dipercaya. Dan, tentu saja, kecepatan permintaan tarik akan meningkat.

Kesimpulan

Tinjauan kode merupakan bagian penting dari proses pengembangan, yang memengaruhi proyek secara keseluruhan, sehingga berbahaya untuk mengabaikannya. Beberapa rekomendasi ini akan membantu mempercepat tinjauan kode, beberapa di antaranya akan membuatnya lebih baik. Saya berharap pengalaman dan pengetahuan saya akan bermanfaat bagi pembaca artikel ini.

Ulasan kode - meningkatkan proses