Sebagai seorang insinyur perangkat lunak junior, saya selalu membaca komentar ulasan kode yang saya terima untuk belajar bagaimana menjadi pembuat kode yang lebih baik. Tetapi ketika tiba saatnya bagi saya untuk mencoba review kode pertama saya, saya menyadari pengalaman saya tidak mempersiapkan saya untuk berada di sisi lain.
Saya mengembangkan kasus yang parah sindrom peniru, berputar ke bawah dengan pertanyaan: Haruskah saya mengomentari baris kode ini atau tidak layak? Haruskah saya menemukan artikel untuk mendukung setiap komentar? Apakah saya akan merusak situs dengan menyetujui ini? Apakah mereka akan membenciku? Oke, saya akui saya berputar cukup cepat. Tetapi setelah berbicara dengan beberapa rekan kerja, saya tahu saya tidak sendirian dalam kekhawatiran saya.
Insinyur perangkat lunak junior dapat dimasukkan ke dalam pengkajian kode dengan asumsi analog dengan “Anda tahu cara membaca buku sehingga Anda tahu cara menulis buku, yang tidak benar, ” kata Jessica Rudder, seorang insinyur pengalaman di GitHub.
Ada harapan yang datang dengan meninjau kode, dan prosesnya bisa sangat menegangkan. Jadi saya mewawancarai tujuh insinyur perangkat lunak lain untuk mengumpulkan kiat tentang cara membangun pola pikir peninjauan.
1. Pikirkan Tentang Dampak Keseluruhan
Secara umum, permintaan tarikan (PR) yang baik seharusnya hanya memengaruhi bagian terbatas basis kode. Namun, ruang lingkup terbatas seharusnya tidak mencegah Anda berpikir tentang perubahan kode dalam konteks basis kode yang lebih besar.
Nigel Munoz, mantan insinyur full-stack di The Muse dan insinyur perangkat lunak freelance saat ini, mendorong pengulas untuk berpikir tentang "bagaimana perubahan ini mempengaruhi gambar yang lebih besar dan lebih kecil." Mengingat gambar yang lebih besar termasuk menemukan utang teknis - cari kode yang diulang, non-modular, atau tidak mematuhi konvensi standar terbaru - serta menganalisis modifikasi pada arsitektur basis kode.
Sam Donow, pengembang inti di Hudson River Trading, percaya bahwa “tidak ada yang terlalu besar atau terlalu kecil untuk dikomentari. Saran untuk perbaikan kecil dapat mengarah pada peningkatan yang lebih besar di beberapa bagian basis kode. "
Anda dapat menggunakan komentar PR di GitHub untuk memberikan umpan balik positif serta menunjukkan di mana kode mungkin berbeda dari konvensi standar kerangka kerja Bereaksi.
Misalnya, selama salah satu ulasan kode saya sendiri, saya menerima komentar bahwa sifat-sifat tertentu pada komponen React membingungkan, yang memicu pertanyaan yang lebih luas tentang bagaimana komponen itu digunakan. Pada akhirnya, saya menghapus properti dari komponen asli dan membuat komponen terpisah untuk memperjelas perilaku masing-masing dan memastikan keduanya dapat digunakan di lebih banyak tempat.
2. Pertimbangkan Keamanan
Jangan lupa bahwa beberapa perubahan dapat berdampak lebih dari sekadar basis kode. Rudder merekomendasikan untuk mengevaluasi apakah pengguna “dapat menggunakan fungsi ini untuk melecehkan seseorang atau dapat menyalahgunakan sistem.” Misalnya, jika fitur baru dalam permintaan tarik mencakup entri pengguna, cari injeksi SQL, akses data, skrip lintas situs, dan kerentanan keamanan lainnya.
3. Fokus pada Bug
Rekan-rekan penyumbang kode Anda - tidak peduli seberapa kelihatan robotnya - adalah manusia, dan manusia dapat merusak atau melupakan fungsi. Jadi pastikan Anda "meninjau tes dengan kepentingan yang sama dengan kode lainnya, " saran Abhishek Pillai, pemimpin teknologi di Teachers Pay Teachers. "Mereka akan mencegah bug baru dan berfungsi sebagai bentuk dokumentasi untuk siapa pun yang mengerjakan ini di masa depan."
Membaca tes dapat membantu Anda memahami fungsionalitas fitur baru dan melihat berbagai kasus yang akan diperkenalkan, sementara menganalisis tes dapat membantu Anda menunjukkan kasus yang hilang dan menemukan fitur yang tidak terkandung dalam PR ini. Jika tidak ada tes yang disertakan dalam perubahan kode dan mereka tampaknya relevan, sudah tepat untuk meminta mereka dalam peninjauan.
Tetapi tes bukanlah segalanya. "Jangan terlalu percaya pada sistem, " Donow memperingatkan. "Hanya karena tes berjalan tidak berarti tidak ada bug."
Anda mungkin juga ingin “menjalankan aplikasi secara lokal untuk mengujinya secara fungsional dan memastikannya berfungsi. Jika tidak berhasil, maka tidak ada gunanya meninjau lebih lanjut, ”kata Ryan Verner, pengembang perangkat lunak di 8th Light. Meskipun beberapa pengulas tidak menganggap pengujian manual harus menjadi bagian dari proses peninjauan kode - sebagian karena waktu yang diperlukan - Verner percaya ini adalah cara cepat untuk menentukan apakah Anda harus menginvestasikan lebih banyak waktu untuk meninjau serta strategi untuk membantu mengurangi pertumbuhan backlog bug.
4. Jadilah Pemain Tim
Klise mengambil arti baru ketika datang untuk meninjau kode. "Luangkan waktu untuk meninjau karena ini basis kode semua orang, " kata Verner, yang mengadvokasi rasa "kepemilikan kolektif." Anda, sebagai peninjau, harus berupaya melindungi tumpukan bug dari tumbuh lebih besar dengan tujuan memberi Anda Tim kurang bekerja di telepon.
Pillai menggunakan gifs untuk merayakan PR yang disetujui dan siap bergabung dengan rekan timnya.
Pada saat yang sama, Charles Luxton, seorang pemimpin teknologi di The Muse, mendorong pengulas untuk memahami dan mengingat prioritas tim. Dengan tenggat waktu dan pertentangan yang semakin dekat semakin meluas, kadang-kadang membuat tugas yang harus dilakukan untuk jaminan simpanan yang memastikan perbaikan akan dilakukan di masa depan dan memberikan komentar pada kode yang dipertanyakan sementara itu adalah Band-Aid yang Anda butuhkan untuk buat tim Anda senang.
Akhirnya, bertanya pada diri sendiri apakah kode itu masuk akal bagi seseorang yang baru saja bergabung dengan tim dan membacanya dalam beberapa minggu pertama mereka akan membantu menjaga kode Anda dapat dibaca dan dimengerti.
5. Gunakan Proses untuk Belajar dan Berbagi Pengetahuan
Proses peninjauan memberi semua orang yang terlibat tempat untuk mendapatkan lebih banyak wawasan tentang basis kode, bahasa, kerangka kerja, dan praktik terbaik.
Matt Jeffery, seorang pemimpin teknologi di The Muse, menyarankan pengulas untuk "memahami perubahan secara arsitektur. Salah satu caranya adalah membaca nama file karena mereka membantu memberikan konteks. Misalnya, jika Anda melihat perubahan pada lapisan akses data Anda tahu Anda tidak berurusan dengan logika bisnis atau UI. "
Anda dapat menggunakan komentar PR di GitHub untuk berbagi dokumentasi.
Ketika Anda belajar dari perubahan kode, Anda juga memiliki kesempatan untuk berbagi pengetahuan. "Yang terbaik untuk menjelaskan pendapat Anda dan mendukungnya dengan dokumentasi, " kata Luxton. Tautan yang Anda berikan ke bukti pendukung dan artikel yang dapat dipercaya tidak hanya membantu peninjau dan penulis kode mengeksplorasi berbagai pendekatan saat mereka membuat keputusan akhir, tetapi juga meningkatkan pengetahuan mereka tentang pemrograman.
Sementara Anda mengingat tip-tip ini dalam pikiran, ingat juga bahwa meninjau adalah waktu untuk melatih keterampilan orang-orang Anda. "Beri orang-orang manfaat dari keraguan bahwa mereka memikirkan pendekatan mereka dan tunjukkan kemungkinan yang berbeda ketika mencoba untuk mengusir sikap defensif, " kata Rudder. "Saya memberikan komentar dan komentar penutup - inilah yang bagus, inilah yang dapat diperbaiki, inilah yang perlu diubah sebelum bergabung."
Dengan pendekatan semacam ini, Anda tidak hanya akan melindungi basis kode dari hutang teknologi, ancaman keamanan, dan bug, tetapi Anda juga akan membangun tim Anda.
