Ada dua masalah penting dalam pertanyaan, bagian yang bijaksana , dan batas waktu yang akan datang . Ini adalah masalah yang berbeda - yang pertama adalah masalah komunikasi dan dinamika tim, yang kedua adalah masalah perencanaan dan prioritas.
Tactfully . Saya berasumsi Anda ingin menghindari ego yang disikat dan pushback negatif terhadap ulasan. Beberapa saran:
- Memiliki pemahaman bersama tentang standar pengkodean dan prinsip-prinsip desain.
- Jangan pernah mengkritik atau meninjau pengembang , hanya kodenya . Hindari kata "Anda" atau "kode Anda", cukup bicarakan kode yang sedang ditinjau, terlepas dari pengembang mana pun.
- Masukkan kebanggaan Anda pada kualitas kode yang telah dilengkapi , sehingga komentar ulasan yang membantu meningkatkan hasil akhir dihargai.
- Sarankan peningkatan daripada permintaan. Selalu berdialog jika Anda tidak setuju. Cobalah untuk memahami sudut pandang lain saat Anda tidak setuju.
- Biarkan ulasan berjalan dua arah. Yaitu memiliki orang yang Anda tinjau meninjau kode Anda selanjutnya. Tidak memiliki ulasan "satu arah".
Bagian kedua adalah penentuan prioritas . Anda memiliki banyak saran untuk perbaikan, tetapi karena tenggat waktu semakin dekat, hanya ada waktu untuk menerapkan beberapa.
Yah, pertama-tama Anda ingin menghindari ini terjadi di tempat pertama! Anda melakukan ini dengan melakukan ulasan yang terus menerus dan bertahap. Jangan biarkan pengembang bekerja selama berminggu-minggu pada fitur dan kemudian meninjau semuanya pada saat terakhir. Kedua, ulasan kode dan waktu untuk menerapkan saran ulasan harus menjadi bagian dari perencanaan dan perkiraan rutin untuk tugas apa pun. Jika tidak ada cukup waktu untuk meninjau dengan benar, ada yang salah dalam perencanaan.
Tetapi mari kita asumsikan ada sesuatu yang salah dalam proses, dan Anda sekarang dihadapkan dengan sejumlah komentar ulasan, dan Anda tidak punya waktu untuk mengimplementasikan semuanya. Anda harus memprioritaskan. Lalu pilih perubahan yang paling sulit dan paling berisiko untuk diubah nanti jika Anda menunda.
Penamaan pengidentifikasi dalam kode sumber sangat penting untuk keterbacaan dan pemeliharaan, tetapi juga cukup mudah dan berisiko rendah untuk berubah di masa depan. Sama dengan pemformatan kode. Jadi jangan fokus pada hal-hal itu. Di sisi lain, kewarasan antarmuka publik harus menjadi prioritas tertinggi, karena mereka sangat sulit untuk berubah di masa depan. Data persisten sulit diubah - jika Anda pertama kali mulai menyimpan data yang tidak konsisten atau tidak lengkap dalam database, sangat sulit untuk memperbaikinya di masa mendatang.
Area yang dicakup oleh unit-test berisiko rendah. Anda selalu dapat memperbaikinya nanti. Area yang tidak, tetapi yang bisa diuji unit berisiko lebih rendah daripada area yang tidak bisa diuji unit.
Katakanlah Anda memiliki sejumlah besar kode tanpa uji unit dan semua jenis masalah kualitas kode termasuk ketergantungan hardcode pada layanan eksternal. Dengan menyuntikkan ketergantungan ini, Anda membuat potongan kode dapat diuji. Ini berarti Anda dapat menambahkan tes di kemudian hari dan memperbaiki masalah lainnya. Dengan dependensi hardcoded Anda bahkan tidak dapat menambahkan tes. Jadi lakukan perbaikan ini terlebih dahulu.
Tapi tolong coba untuk tidak berakhir dengan skenario ini sejak awal!