Jadi berdasarkan perincian yang diberikan OP, sepertinya pertanyaannya adalah, "bagaimana saya mempelajari kode saya sendiri sehingga ketika diminta untuk menemukan X atau menjelaskan Y, saya dapat merespons dengan cepat."
Saat membuat kode, Anda perlu meluangkan waktu untuk mempelajari dan memahami kode Anda sendiri. Ini bisa menjadi apa yang TL Anda coba sampaikan kepada Anda dengan tidak banyak kata. Menjadi TL pada proyek saat ini, saya telah melakukan banyak tinjauan kode dalam 11 bulan terakhir dan saya melihat ada praktek dari beberapa pengembang untuk mencari "contoh kode" baik di basis kode kita sendiri, atau di tempat lain (google , dll ...) dan salin / tempel. Secara pribadi, saya tidak tahan karena ketika kode mereka melewati tes unit sederhana, mereka tidak mengerti apa yang sebenarnya dilakukan, jadi kami tidak pernah dijamin bahwa tidak ada t beberapa kasus batas atau kondisi kegagalan yang diharapkan yang dapat terjadi.
Sebagai konsekuensi wajar dari pernyataan sebelumnya, jika Anda harus menyalin / menempel, cobalah hanya menyalin / menempelkan kode yang sebelumnya telah Anda tulis dan yang Anda pahami. Tentu saja tidak apa-apa untuk "meminjam" ide orang lain tetapi dalam kasus itu, menulis ulang kode mereka baris demi baris karena ketika Anda menulisnya, Anda akan mendapatkan pemahaman yang lebih baik tentang apa yang dilakukannya. Jika Anda menggunakan API eksternal, bahkan jika Anda memiliki contoh yang menggunakan API itu, luangkan beberapa menit untuk menemukan referensi dan mempelajari cara kerja API itu. Jangan hanya berasumsi bahwa jika berhasil sebelumnya, itu juga akan berfungsi dalam situasi Anda.
Baca dan belajar untuk mencintai prinsip KERING . Sering kali Anda tergoda untuk menyalin / menempel dapat ditempatkan di lokasi yang sama (fungsi terpisah, kelas terpisah, perpustakaan terpisah ...)
Baca dan belajar untuk mencintai prinsip - prinsip SOLID dan ketika Anda berada di sana, tinjau KISS yang sudah disebutkan oleh mouviciel. Prinsip-prinsip ini semuanya berorientasi pada pembuatan kode yang sangat ringkas, bersih dan modular. Jika Anda memiliki kelas besar dan fungsi besar di dalamnya, jelas akan jauh lebih sulit untuk menemukan hal-hal dan di atas itu cobalah menjelaskan apa yang dilakukan kode. Di sisi lain, jika Anda mengikuti (atau setidaknya mencoba mengikuti) SRP dan membuat setiap kelas / fungsi bertanggung jawab untuk satu hal saja, kode Anda akan kecil dan sangat mudah dibaca.
Ambil salinan Kode Bersih . Buku yang sangat bagus. Ini berbicara tentang menulis kode yang cukup jelas dan mudah dibaca, dipelihara dan diperluas. Jika Anda berlatih menulis kode yang mudah dibaca, Anda seharusnya tidak memiliki masalah membaca kode Anda sendiri dalam ulasan kode. Dan ini bagian yang lucu, saya meminta orang untuk membaca kode mereka sendiri atau hanya memberi tahu saya apa variabel mewakili dan mereka tidak bisa menjawab meskipun mereka menulis kode itu (kelas baru, bukan warisan) hanya seminggu yang lalu . Penamaan yang baik sangat membantu.
Jika setelah semua penyederhanaan dan refactoring, Anda masih memiliki fungsi yang harus melakukan beberapa jenis algoritma yang tidak terlalu jelas, meluangkan waktu dan menulis blok komentar di fungsi yang menjelaskan algoritma. Tidak hanya akan membantu ketika Anda harus memodifikasi fungsi itu 2 bulan dari sekarang, tetapi jika Anda disergap dalam tinjauan kode, Anda akan dapat dengan mudah membaca kembali apa yang Anda tulis.
Jika setelah semua item di atas, apakah Anda masih menemukan masalah? apakah Anda baru di tim dan diminta bekerja dengan banyak kode lama? Dalam hal ini, bisa jadi TL Anda menjadi A $$ dan Anda bisa proaktif dengan memintanya sebelum rapat agar mudah dan tidak membuang waktu semua orang yang terlibat. Ketika orang baru bergabung dengan sebuah tim, TL perlu memiliki kesabaran yang cukup karena bekerja di platform baru, produk baru, orang baru, lingkungan baru membutuhkan banyak konsentrasi dari orang baru, dan orang itu akan kehilangan beberapa detail di awal. Berfungsi sebagai Dirancang dan TL Anda seharusnya menerimanya.
Jika setelah semua item di atas, Anda masih merasa bahwa Anda memiliki ulasan kode yang mengerikan. Bicaralah dengan TL Anda. Kadang-kadang orang merasa buruk karena sifat pertemuan peninjauan kode padahal sebenarnya TL sangat senang dengan Anda. Ketika saya melakukan review kode, tujuan saya adalah untuk menyoroti apa yang perlu diubah, pastikan Anda memahami perubahan dan melanjutkan. Banyak kali saya tidak punya waktu untuk bersikap sopan dan beberapa orang bersikap defensif dan berusaha menjawab setiap komentar saya. Dalam situasi tersebut, pertemuan tinjauan kode berhenti, jadi saya cenderung menyela mereka dan melanjutkan. Secara umum, setelah pertemuan saya akan berbicara dengan orang-orang baru untuk memastikan mereka memahami prosesnya dan itu bukan masalah pribadi. Setelah beberapa ulasan kode orang umumnya lebih nyaman.