Sebagai jurutera perisian junior, saya selalu meneliti kod kajian ulasan yang saya terima untuk belajar bagaimana menjadi coder yang lebih baik. Tetapi apabila tiba masanya untuk saya mencuba kajian kod pertama saya, saya menyedari pengalaman saya tidak menyiapkan saya untuk berada di sisi lain.
Saya telah membangunkan kes sindrom penderaan yang teruk, yang merosot dengan soalan: Sekiranya saya memberi komen mengenai barisan kod ini atau adakah ia tidak berbaloi? Sekiranya saya mencari artikel untuk menyokong setiap ulasan? Adakah saya akan merosakkan tapak dengan meluluskan perkara ini? Adakah mereka benci saya? Okay, saya akui saya berputar dengan cepat. Tetapi selepas bercakap kepada beberapa rakan sekerja, saya tahu saya tidak bersendirian dalam kebimbangan saya.
Jurutera perisian junior boleh dibuang ke dalam kod kajian dengan anggaran yang serupa dengan "anda tahu bagaimana membaca buku supaya anda tahu cara menulis buku, yang tidak benar, " kata Jessica Rudder, jurutera pengalaman di GitHub.
Terdapat jangkaan yang datang dengan mengkaji semula kod, dan prosesnya boleh menjadi saraf. Oleh itu, saya menemubual tujuh jurutera perisian lain untuk mengumpul petua mengenai bagaimana untuk membina pemikiran semula.
1. Pikirkan Mengenai Kesan Keseluruhan
Secara amnya, permintaan menarik yang baik (PR) hanya boleh menjejaskan bahagian terkurung dari basis kod. Bagaimanapun, skop terhad tidak menghalang anda daripada memikirkan perubahan kod dalam konteks asas kod yang lebih besar.
Nigel Munoz, seorang bekas jurutera penuh di The Muse dan seorang jurutera perisian lepas lepas, menggalakkan pengulas berfikir tentang "bagaimana perubahan ini memberi kesan kepada gambar yang lebih besar dan lebih kecil." Memandangkan gambar yang lebih besar termasuk mencari apa-apa hutang teknikal mencari kod yang diulang, tidak modular, atau tidak mematuhi konvensyen standard yang paling terkini-serta menganalisis pengubahsuaian kepada seni bina asas.
Sam Donow, pemaju utama di Hudson River Trading, percaya bahawa "tidak ada terlalu besar atau terlalu kecil untuk memberi komen. Cadangan untuk penambahbaikan kecil boleh membawa kepada penambahbaikan yang lebih besar dalam pelbagai bahagian dalam pangkalan data. "
Anda boleh menggunakan komen PR pada GitHub untuk memberi maklum balas yang positif serta menunjukkan di mana kod mungkin berbeza daripada konvensyen standard rangka kerja React.
Sebagai contoh, semasa salah satu kajian kod saya sendiri, saya menerima komen bahawa sifat-sifat tertentu pada komponen Reacta mengelirukan, yang mencetuskan persoalan yang lebih luas tentang bagaimana komponen itu digunakan. Akhirnya, saya mengeluarkan sifat-sifat dari komponen asal dan membuat komponen berasingan untuk menjelaskan kelakuan masing-masing dan memastikan kedua-duanya boleh digunakan di lebih banyak tempat.
2. Pertimbangkan Keselamatan
Jangan lupa bahawa beberapa perubahan boleh memberi kesan lebih daripada sekadar kod dasar. Rudder menyarankan untuk mengevaluasi jika pengguna "boleh menggunakan fungsi ini untuk mengganggu seseorang atau boleh menyalahgunakan sistem." Sebagai contoh, jika ciri baru dalam permintaan menarik termasuk kemasukan pengguna, cari suntikan SQL, akses data, skrip silang tapak, dan kelemahan keselamatan yang lain.
3. Fokus pada Bugs
Penyumbang kod rakan anda-tidak kira bagaimana robot mereka mungkin kelihatan-adalah manusia, dan manusia boleh memecahkan atau melupakan fungsi. Oleh itu, pastikan anda "mengkaji semula ujian dengan kepentingan yang sama seperti yang lain daripada kod, " menasihati Abhishek Pillai, peneraju teknologi di Teachers Pay Teachers. "Mereka akan menghalang pepijat baru dan berfungsi sebagai satu bentuk dokumentasi kepada orang lain yang bekerja pada masa ini."
Membaca ujian boleh membantu anda memahami fungsi ciri baru dan melihat kes-kes yang berbeza yang akan diperkenalkan, sementara menganalisis ujian boleh membantu anda menunjukkan kes yang hilang dan mencari ciri yang tidak terkandung dalam PR ini. Sekiranya tiada ujian yang termasuk dalam perubahan kod dan mereka kelihatan relevan, adalah sesuai untuk meminta mereka dalam semakan.
Tetapi ujian bukan semuanya. "Jangan letakkan terlalu banyak kepercayaan pada sistem ini, " Donow memberi amaran. "Hanya kerana ujian berlari tidak bermakna tiada bug."
Anda juga mungkin mahu "menjalankan aplikasi secara tempatan untuk menguji secara fungsinya dan pastikan ia berfungsi. Jika ia tidak berfungsi, maka tidak ada gunanya mengkaji semula, "kata Ryan Verner, pemaju perisian pada 8th Light. Walaupun sesetengah pengulas tidak berfikir ujian manual harus menjadi sebahagian daripada proses semakan kod-sebahagian kerana masa yang diperlukan-Verner percaya ia adalah cara yang cepat untuk menentukan sama ada anda perlu melabur lebih banyak masa meninjau serta strategi untuk membantu mengurangkan pertumbuhan serangga pepijat.
4. Menjadi Pemain Pasukan
Klise mengambil makna baru apabila mengkaji semula kod. "Luangkan masa untuk meninjau kerana ia adalah asas semua orang, " kata Verner, yang menyokong "pemilikan kolektif". Anda, sebagai penyelidik, harus berusaha untuk melindungi tunggakan pepijat daripada semakin besar dengan matlamat untuk memberikan pasukan kurang bekerja di garisan.
Pillai menggunakan gif untuk meraikan PR yang diluluskan dan bersedia untuk bergabung.
Pada masa yang sama, Charles Luxton, ketua teknologi di The Muse, menggalakkan pengulas memahami dan mengingati keutamaan pasukan. Dengan tarikh akhir yang cepat dan perbezaan pendapat yang berlimpah-limpah, kadang-kadang membuat item tugasan untuk tunggakan yang memastikan peningkatan akan dibuat pada masa akan datang dan memberi ulasan pada kod yang dipersoalkan dalam masa yang sama adalah Band-Aid yang anda perlukan untuk pastikan pasukan anda gembira.
Akhirnya, tanya diri anda jika kod itu masuk akal kepada seseorang yang baru saja menyertai pasukan dan membacanya dalam beberapa minggu pertama akan membantu memastikan kod anda dibaca dan difahami.
5. Gunakan Proses Pembelajaran dan Perkongsian Pengetahuan
Proses semakan memberikan semua orang yang terlibat dengan tempat untuk mendapatkan lebih banyak maklumat tentang asas bahasa, bahasa, rangka kerja, dan amalan terbaik.
Matt Jeffery, peneraju teknologi di The Muse, menasihatkan pengulas untuk "memahami perubahan arsitektur, satu cara adalah untuk membaca nama fail kerana mereka membantu memberi konteks. Sebagai contoh, jika anda melihat perubahan dalam lapisan akses data anda tahu anda tidak berurusan dengan logik perniagaan atau UI. "
Anda boleh menggunakan komen PR pada GitHub untuk berkongsi dokumentasi.
Apabila anda belajar dari perubahan kod, anda juga mempunyai peluang untuk berkongsi pengetahuan. "Adalah lebih baik untuk menerangkan pendapat anda dan menyokongnya dengan dokumentasi, " kata Luxton. Pautan yang anda berikan kepada bukti sokongan dan artikel yang boleh dipercayai tidak hanya membantu pengulas dan penulis kod meneroka pendekatan yang berbeza ketika mereka membuat keputusan muktamad, tetapi juga meningkatkan pengetahuan mereka tentang pengaturcaraan.
Semasa anda menyimpan petua ini, ingat juga bahawa semakan adalah masa untuk menggunakan kemahiran orang anda. "Berikan orang manfaat dari keraguan bahawa mereka memikirkan pendekatan mereka dan menunjukkan kemungkinan yang berbeza ketika cuba menghilangkan defensif, " kata Rudder. "Saya meninggalkan komen sepanjang dan menyusun komen-inilah yang hebat, inilah yang boleh diperbaiki, inilah yang perlu diubah sebelum bergabung."
Dengan pendekatan seperti ini, bukan sahaja anda akan melindungi asas kod anda dari hutang teknologi, ancaman keselamatan, dan pepijat, tetapi anda juga akan membina pasukan anda.
