Отже, виходячи з наданих деталей ОП, це звучить як запитання: "як я дізнаюся власний код, щоб, коли мене попросили знайти X або пояснити Y, я міг швидко відповісти".
При кодуванні потрібно витратити час на вивчення та розуміння власного коду. Це може бути те, що ваша TL намагається натрапити на вас не так багато слів. Будучи TL в поточному проекті, я робив багато оглядів коду за останні 11 місяців, і я помічаю практику деяких розробників шукати "приклад коду" або в нашій власній базі коду, або деінде (google і т. д. ...) і скопіюйте / вставте його. Особисто я не витримую цього, оскільки, хоча їхній код проходить прості одиничні тести, вони не розуміють, що він насправді робить, тому ми ніколи не гарантуємо, що цього немає " t деякий граничний випадок або очікуваний стан відмови, який може статися.
Як наслідок попереднього твердження, якщо вам доведеться скопіювати / вставити, спробуйте скопіювати / вставити лише той код, який Ви раніше писали, і який ви розумієте. Безумовно, добре "запозичити" ідею інших людей, але в цьому випадку перепишіть їх код за рядком, тому що, як ви пишете його, ви отримаєте краще розуміння того, що він робить. Якщо ви використовуєте зовнішні API, навіть якщо у вас є приклад, який використовує цей API, все одно знайдіть кілька хвилин, щоб знайти посилання та дізнатися, як працює цей API. Не припускайте просто, що якщо він працював раніше, він також буде працювати у вашій ситуації.
Прочитайте і навчіться любити принцип DRY . Багато разів те, що ви спокусилися скопіювати / вставити, може бути розміщене у загальному місці (окрема функція, окремий клас, окрема бібліотека ...)
Прочитайте і навчіться любити принципи SOLID, і поки ви до цього, перегляньте KISS, про який вже згадував mouviciel. Ці принципи орієнтовані на створення дуже короткого, чистого та модульного коду. Якщо у вас є великі класи та великі функції в них, то, очевидно, буде набагато складніше знайти речі, а крім цього спробуйте пояснити, що робить код. З іншого боку, якщо ви дотримуєтесь (або принаймні намагаєтесь слідувати) SRP та зробите для кожного класу / функції відповідальним лише за одне, ваш код буде малим і дуже читабельним.
Візьміть копію чистого коду . Дуже гарна книга. У ньому йдеться про написання коду, який пояснюється самостійно і легко читається, підтримується та розширюється. Якщо ви практикуєте написання коду, який легко читати, у вас не повинно виникнути проблем з читанням власного коду в оглядах коду. І це найсмішніша частина. Я попросив людей прочитати власний код або просто сказати мені, що представляють змінні, і вони не змогли відповісти, хоча написали цей код (абсолютно нові класи, а не спадщина) лише тиждень тому . Гарне називання проходить довгий шлях.
Якщо після всього спрощення та рефакторингу у вас все ще є функція, яка повинна виконувати якийсь алгоритм, який не дуже очевидний, знайдіть час і напишіть блок коментарів у цій функції, що пояснює алгоритм. Це буде не тільки корисно, коли вам доведеться змінити цю функцію через 2 місяці, але якщо ви отримаєте засідку в огляді коду, ви зможете просто прочитати назад те, що ви написали.
Якщо після всіх вищезазначених пунктів ви все ще опинитесь у біді? Ви новачок у команді та просили працювати з багатьма застарілими кодами? У такому випадку, можливо, ваш TL є A $$, і ви можете бути ініціативними, попросивши його перед зустріччю пройти легко і не витрачати час усіх, хто бере участь. Коли нові люди приєднуються до команди, TL потребує достатнього терпіння, оскільки робота в новій платформі, новому продукті, нових людях, новому середовищі вимагає великої концентрації у нової людини, і цій людині не вистачить деяких деталей на початку. Працює як розроблено, і ваш TL повинен просто прийняти це.
Якщо після всіх пунктів вище, ви все ще відчуваєте, що у вас є жахливі відгуки про код. Поговоріть зі своїм TL. Іноді люди відчувають себе погано через характер зустрічей з переглядом коду, коли насправді TL абсолютно задоволений тобою. Коли я роблю огляди коду, моя мета - виділити те, що потрібно змінити, переконайтесь, що ви розумієте зміни та рухаєтесь далі. Багато разів я не встигаю бути ввічливим, а деякі люди захищаються і намагаються відповісти на кожен мій коментар. У таких ситуаціях зустріч з перегляду коду припиняється, тому я схильний їх переривати і рухатись далі. Як правило, після зустрічі я б поговорив з новими хлопцями, щоб переконатися, що вони розуміють процес, і що це нічого особистого. Після кількох оглядів коду людям, як правило, набагато комфортніше.