Tinjauan kode adalah praktik yang semakin umum di tim pengembangan. Ini adalah alur kerja di mana pengembang mengirimkan kode mereka untuk umpan balik sebelum menggabungkan cabang, atau menggunakan kode untuk produksi. Umpan balik ini biasanya diberikan oleh kolega, baik pengembang lain, manajer, atau pemimpin teknologi. Salah satu bentuk tinjauan kode yang paling dikenal adalah Github menarik permintaan, di mana pengembang meninggalkan komentar pada baris kode tertentu dan, akhirnya, menyetujui atau menolak perubahan yang diajukan.

Tinjauan kode didasarkan pada asumsi sederhana bahwa "dua kepala lebih baik dari satu". Kita semua memiliki blindspot ketika menulis kode: pendekatan yang tidak kita pertimbangkan, efisiensi yang tidak kita buat, dan bagian-bagian dari sistem yang kurang kita pahami dibandingkan yang lain. Tinjauan kode adalah upaya untuk menghilangkan titik-titik buta ini dan meningkatkan kualitas kode dengan memastikan bahwa setidaknya satu pengembang lain memiliki input pada setiap baris kode yang membuatnya menjadi produksi.

(Sebagai catatan, pemrograman pasangan terkadang dapat menyerupai bentuk ulasan kode 'langsung', di mana satu orang menulis kode dan ulasan lain di tempat.)

Walaupun peninjauan kode sering kali berarti kode membutuhkan waktu lebih lama untuk membuatnya menjadi produksi, banyak tim pengembangan mengatakan bahwa ini sepadan dengan waktu karena peningkatan kualitas kode secara keseluruhan. Tinjauan kode dipraktikkan dari perusahaan besar berkinerja besar, seperti Microsoft dan Google, untuk startup seperti Cerita lengkap. Bruce Johnson, salah satu pendiri di Fullstory, mengatakan bahwa perusahaannya melakukan tinjauan kode karena “mencegah lebih baik daripada mengobati” Singkatnya, tinjauan kode sering kali berarti lebih sedikit kesalahan yang membuatnya menjadi produksi.

Anda mungkin sudah melakukan tinjauan kode di tempat kerja. Namun, dalam pengalaman saya, sebagian besar pengembang melakukan ulasan kode sesuai dengan 'nyali perasaan' mereka. Mereka bereaksi terhadap setiap baris kode tanpa rencana yang jelas untuk apa yang akan mereka pertimbangkan selama tinjauan kode. Karena pendekatan ad hoc ini, aspek-aspek tertentu dari tinjauan kode sering diabaikan.

Dalam artikel ini, kami akan bertujuan untuk membangun keterampilan peninjauan kode Anda dengan menyarankan berbagai elemen yang harus Anda pertimbangkan ketika melakukan satu. Anda dapat menggunakan daftar ini sebagai daftar periksa untuk memeriksa ketika Anda meninjau kode. Jika daftar ini kelihatannya luar biasa, Codementor juga menawarkan ulasan kode sebagai layanan.

1. Keterbacaan alias 'Dapat dimengerti'

Keterbacaan dalam perangkat lunak berarti bahwa kode itu mudah dipahami. Dalam hal ini, memahami kode berarti dapat dengan mudah melihat input dan output kode, apa yang dilakukan setiap baris kode, dan bagaimana hal itu cocok dengan gambaran yang lebih besar. Saat membaca kode, relatif mudah bagi Anda untuk memahami peran fungsi, metode, atau kelas tertentu.

Kode menjadi kurang terbaca karena lebih banyak memori kerja Anda diperlukan untuk menahan setiap 'langkah' di pikiran Anda. Salah satu masalah yang paling sering terjadi pada kode adalah tidak dipecah menjadi potongan yang cukup kecil. Biasanya, ini mengarah ke kelas, metode atau fungsi yang terlalu panjang dengan tanggung jawab yang terlalu banyak. Dengan memecah kode menjadi potongan yang lebih kecil, lebih mudah untuk memikirkan dan membuat perubahan pada bagian tertentu dari sistem tanpa efek samping yang tidak diinginkan.

Aspek lain dari keterbacaan adalah penamaan variabel, fungsi, metode, dan kelas. Nama deskriptif yang bagus membuat kode lebih mudah dimengerti. Jangan ragu untuk memberikan umpan balik pada nama yang terlalu disingkat atau sulit dimengerti. Misalnya, walaupun mungkin jelas bagi pembuat kode asli itu op adalah singkatan options parser, mungkin tidak jelas bagi Anda atau orang berikutnya yang akan menulis kode. Nama yang baik menghemat waktu semua orang dan mengurangi beban kognitif saat membaca kode.

2. Pemeliharaan

Salah satu alasan paling umum bahwa kode akhirnya menjadi menyakitkan untuk dikerjakan adalah karena kode tidak ditulis agar mudah diperluas dan diubah.

Berikut adalah beberapa tanda peringatan bahwa kode mungkin tidak mudah dipelihara di masa depan:

• Ini sangat erat digabungkan ke sistem lain.
• Konfigurasi adalah kode-keras.
• Ini berkontribusi pada utang teknologi dengan meningkatkan investasi dalam teknologi yang ingin dihapuskan oleh tim (misalnya, dengan menggunakan fungsionalitas dari versi lama perpustakaan).
• Itu bergantung pada kode lama yang telah dijadwalkan untuk dihapus atau diganti.

3. Keamanan

Kerentanan keamanan sering memasukkan basis kode karena pengembang menulis kode tanpa memikirkan keamanan. Ini mungkin berarti bahwa mereka menulis kode tidak aman yang memperkenalkan kerentanan ke dalam sistem, atau menggunakan perpustakaan dan alat-alat yang sudah ketinggalan zaman atau telah mengetahui masalah keamanan.

Selama tinjauan kode, masalah keamanan mungkin terabaikan jika pengembang lupa menempatkan diri pada posisi seseorang yang mencoba mengeksploitasi sistem. Misalnya, tanyakan pada diri Anda: jika saya mencoba untuk mendapatkan akses ke sistem atau mencuri data, bagaimana saya bisa mengeksploitasi kode ini?

4. Kecepatan dan Kinerja

Pertimbangkan kinerja di dua dimensi: kinerja untuk pengguna dan konsumsi sumber daya. Kinerja untuk pengguna mencerminkan fokus pada seberapa cepat kinerja kode Anda untuk pengguna akhir. Kueri basis data yang panjang, aset yang tidak dioptimalkan, dan beberapa permintaan API dapat bekerja untuk membuat kode Anda terasa lambat.

Jika memungkinkan, kode harus menggunakan pemuatan lambat, serta pemrosesan asinkron dan paralel. Ini harus menggunakan caching sebanyak mungkin dan tidak memuat apa pun yang tidak digunakan.

Dimensi kinerja lainnya adalah konsumsi sumber daya. Ini berarti tidak menugaskan server cloud yang lebih kuat dari yang dibutuhkan, tidak menjalankan laporan intensif lebih sering dari yang dibutuhkan, dan sebaliknya, tidak menempatkan sistem di bawah beban lebih dari yang seharusnya karena kode atau pilihan infrastruktur.

Sementara mengikuti praktik terbaik seperti ini, berhati-hatilah untuk tidak mengambil "kebutuhan akan kecepatan" ini terlalu jauh. Melakukannya dapat mengarah pada pengoptimalan prematur, yang merupakan optimasi yang tidak diperlukan, tidak terlihat oleh pengguna (atau dalam metrik Anda), atau tidak sepadan dengan investasi waktu. Jadilah praktis. Fokus pada 20% optimasi yang menghasilkan 80% hasil.

5. Dokumentasi

Periksa apakah kode yang Anda tinjau memerlukan dokumentasi tambahan. Jika ini adalah proyek baru, ini berarti memastikan ia memiliki readme yang memadai yang menjelaskan mengapa proyek itu ada dan bagaimana menggunakannya. Jika kode baru ditambahkan ke proyek yang sudah ada, ada baiknya memikirkan apakah readme proyek perlu diperbarui untuk mendokumentasikan fungsionalitas baru atau alat baru.

6. Menciptakan Kembali Roda

Apakah kode menggunakan fitur bahasa yang tepat untuk menyelesaikan pekerjaan? Ketika orang menulis kode dalam bahasa pemrograman yang belum mereka kuasai, mereka sering mengambil jalan panjang dengan kode. Misalnya, mereka mungkin dengan susah payah menulis fungsi untuk melakukan sesuatu yang sudah ada dalam bahasa yang mereka gunakan. Saat melakukan tinjauan kode, pastikan bahwa kode menggunakan semua fitur bahasa yang sesuai. Kode seharusnya tidak mengimplementasikan kembali fungsi yang sudah ada dalam bahasa atau pustaka yang digunakan proyek.

7. Keandalan

Kode yang dapat diandalkan adalah kode yang toleran terhadap kegagalan. Ketika ada kesalahan dalam kode yang dapat diandalkan, pengalaman pengguna terlindung dari dampak sebanyak mungkin. Kode yang dapat dipercaya ditulis dengan asumsi bahwa segala sesuatu akan gagal, bahwa aset terkadang tidak dimuat, permintaan API kadang-kadang akan menghasilkan 500 kesalahan, dan catatan basis data akan hilang. Ketika tingkat kegagalan tertentu diantisipasi, itu dapat ditangani dengan elegan. Kode yang mengasumsikan tidak ada yang salah umumnya berakhir dengan kegagalan serempak.

8. Skalabilitas

Pertimbangkan skalabilitas dengan membayangkan apa yang mungkin terjadi pada kode yang Anda tinjau jika diletakkan di bawah beban yang tidak terduga. Apa yang terjadi pada beranda Anda jika itu viral dan dipukul dengan lusinan permintaan per detik? Apa yang terjadi jika pengguna dengan ribuan aktivitas di aplikasi Anda memutuskan untuk melihat log aktivitas lengkap mereka? Apa yang terjadi jika produk Anda muncul di berita dan 100 orang mencoba untuk membelinya sekaligus? Penting untuk mempertimbangkan apa yang mungkin terjadi pada kode di bawah periode penggunaan yang sangat tinggi ketika melakukan tinjauan kode. Bagaimanapun, waktu terburuk untuk menemukan masalah skalabilitas adalah ketika mereka membuat situs web / aplikasi / layanan Anda offline.

9. Dapat digunakan kembali

Periksa apakah kode tersebut ditulis dengan mempertimbangkan kemungkinan kasus penggunaan di masa mendatang. Misalnya, jika Anda meninjau kode untuk pasar yang dengan cepat memperluas rangkaian produknya, pastikan bahwa kode tersebut dapat dengan mudah diperbarui untuk mendukung jenis produk baru di masa mendatang.

Dengan cara yang sama, pastikan bahwa kode tidak mengambil terlalu jauh dengan mencoba menjelaskan kasus penggunaan yang tidak mungkin terjadi. Kita semua telah melihat kode di mana penulis berusaha untuk membuktikan ciptaan mereka di masa depan, sehingga mereka akhirnya menambahkan fitur tambahan yang tidak akan pernah digunakan untuk kode mereka. Kode yang tidak pernah digunakan adalah kode warisan segera. Karenanya, penting untuk menemukan keseimbangan antara kode yang dapat digunakan kembali dan kode yang melanggar Prinsip YAGNI: Anda tidak akan membutuhkannya.

KERING adalah salah satu maksim pertama yang dipelajari oleh programmer. Itu artinya, Jangan Mengulangi Diri Anda Sendiri. Dengan kata lain, jangan menduplikasi kode atau fungsionalitas. Salah satu peningkatan tercepat yang dapat Anda lakukan selama peninjauan kode adalah mengidentifikasi kode berulang dan menyarankan fungsi atau kelas yang dapat digunakan kembali untuk menggantinya.

Peringatan: dimungkinkan untuk mengambil reusability terlalu jauh dan menghasilkan kode yang sangat abstrak dan mencoba mengakomodasi begitu banyak kasus penggunaan potensial sehingga tidak ada satupun yang dapat digunakan dengan baik. Ini sama dengan mencoba menciptakan perkakas dapur yang merupakan garpu, pisau, sendok, dan piring semuanya menjadi satu. Itu belum selesai, yang merupakan pertanda bahwa itu mungkin bukan ide yang bagus!

10. Pola

Pertimbangan lain saat menambahkan kode baru ke basis kode adalah apakah cocok dengan pola yang sudah dibuat oleh tim Anda. Basis kode Anda kemungkinan sudah memiliki gaya sendiri, dan mungkin memiliki panduan gaya khusus. Kode baru tidak boleh menyimpang dari pola yang ada tanpa alasan yang kuat.

11. Cakupan Tes dan Kualitas Tes

Tinjauan kode sama pentingnya untuk pengujian seperti halnya untuk kode yang diuji. Ini karena tes yang cacat lebih berbahaya daripada tidak memiliki tes. Lulus tes memungkinkan pengembang merasa aman dan bersedia mendorong kode baru ke produksi. Tetapi bagaimana jika salah satu tes lulus karena alasan yang salah, atau tidak menguji apa yang seharusnya diuji? Tes semacam ini bisa menjadi bom waktu, memungkinkan bug untuk menyelinap ke basis kode Anda.

Persyaratan yang sama untuk kode produksi juga harus berlaku untuk pengujian. Tes harus dapat dibaca, dipelihara, performan, dan mematuhi pola yang ditetapkan. Ketika tiba waktunya untuk memperbarui atau memelihara kode yang ada, pengujiannya kemungkinan merupakan hal pertama yang perlu diubah. Karena itu, sangat penting bagi mereka untuk bekerja dengan tim Anda.

Terakhir, jangan berhenti memeriksa tes yang ada. Pikirkan baik-baik apakah ada tes yang hilang. Apakah ada kasus tepi yang belum diuji?

12. Cocok untuk Tujuan

Kode mungkin berfungsi, tetapi apakah itu berfungsi seperti yang diharapkan oleh Manajer Produk, CEO, atau pengguna Anda? Sebelum kode didorong ke produksi, sebaiknya periksa ulang apakah kode benar-benar menyediakan fungsionalitas yang seharusnya disediakan. Jika Anda tidak memiliki proses penjaminan kualitas yang ditentukan untuk fungsionalitas baru, peninjauan kode mungkin satu-satunya kesempatan Anda untuk mengonfirmasi hal ini.

13. Perhatikan Apa yang Hilang

Peninjauan kode dapat mendorong bias mempertimbangkan hanya apa yang ada di depan Anda. Anda meninjau kode yang telah Anda berikan. Tetapi bagaimana dengan kode yang tidak ada di sana? Misalnya, penting untuk memikirkan kasus tepi, input yang tidak terduga, dan skenario penanganan kesalahan yang mungkin tidak dipertimbangkan oleh pembuat kode. Apa yang terjadi ketika API yang diandalkan oleh kode akan dimatikan? Apa yang terjadi ketika pengguna menekan tombol kirim dua kali berturut-turut dengan cepat? Apa yang terjadi ketika browser pengguna tidak didukung?

14. Perkecil

Salah satu risiko dengan tinjauan kode adalah mendorong fokus pada detail kode, daripada gambaran yang lebih besar. Apa yang terjadi ketika permintaan tarik diajukan yang berisi ratusan baris kode, namun, pendekatan untuk menyelesaikan masalah lebih rendah? Mungkin tidak efisien, atau rapuh, atau tidak dirancang dengan baik? Ini bisa menjadi umpan balik yang sangat sulit untuk diberikan, terutama ketika pengembang telah menghabiskan beberapa hari mengerjakan solusi sebelum meminta peninjauan kode.

Namun, umpan balik semacam ini penting karena permintaan tarik yang semestinya tidak disetujui seringkali menjadi poin rasa sakit di basis kode Anda. Anda harus merasa nyaman menyarankan pendekatan yang sama sekali baru jika permintaan tarikan cacat secara mendasar.

Salah satu cara terbaik untuk membuat ini lebih realistis adalah untuk memastikan bahwa permintaan tarik tidak terlalu besar. Jika pengembang bekerja dalam isolasi selama berhari-hari dan akhirnya mengirimkan permintaan tarikan yang besar, ini merupakan anti-pola. Permintaan tarikan harus kecil dan sering terintegrasi. Matikan fitur, terkadang juga disebut flag fitur, dapat membantu dengan ini. Mereka alat pintar untuk memungkinkan potongan pekerjaan yang lebih besar untuk dipecah menjadi kumpulan permintaan tarik tambahan. Mereka memungkinkan kemajuan konstan pada fungsionalitas dalam basis kode Anda tanpa memaparkannya kepada pengguna sampai Anda siap.

Beri tahu kami: Apa lagi yang Anda pertimbangkan ketika meninjau kode?

Kami berharap ini telah berfungsi sebagai daftar periksa yang berguna untuk Anda pertimbangkan selama tinjauan kode. Bahkan jika Anda tidak merujuk ke setiap item dalam daftar setiap kali Anda meninjau kode, mungkin berguna untuk mencatat aspek-aspek tinjauan kode yang cenderung Anda abaikan. Ini akan berbeda untuk semua orang, dan akan tergantung pada latar belakang atau pengalaman Anda. Namun, semua aspek kode ini sangat penting untuk kualitas dan tidak boleh dilewati.

Apa lagi yang menurut Anda penting untuk dipertimbangkan saat melakukan tinjauan kode? Kami ingin mendengar dari Anda di komentar.

Sumber: https://www.codementor.io/blog/code-review-checklist-76q7ovkaqj