Таким образом, исходя из предоставленных подробностей OP, звучит вопрос: «Как мне узнать свой собственный код, чтобы, когда меня попросили найти X или объяснить Y, я мог быстро ответить».
При кодировании вам нужно время, чтобы выучить и понять свой собственный код. Это может быть то, что ваш TL пытается донести до вас не так много слов. Будучи TL для текущего проекта, я сделал много обзоров кода за последние 11 месяцев, и я заметил, что некоторые разработчики ищут «пример кода» в нашей собственной кодовой базе или где-то еще (Google и т. д.) и скопировать / вставить его. Лично я не могу этого вынести, потому что, хотя их код проходит простые модульные тесты, они не понимают, что он на самом деле делает, поэтому мы никогда не гарантируем, что его нет t некоторый граничный случай или ожидаемое условие отказа, которое может произойти.
Как следствие предыдущего заявления, если вам нужно скопировать / вставить, попробуйте скопировать / вставить только тот код, который вы написали ранее и который вы понимаете. Конечно, можно «заимствовать» чужую идею, но в этом случае переписывайте их код построчно, потому что по мере написания вы будете лучше понимать, что он делает. Если вы используете внешние API, даже если у вас есть пример, который использует этот API, все равно потратьте несколько минут, чтобы найти ссылку и узнать, как работает этот API. Не просто предполагайте, что если это сработало раньше, это также сработает в вашей ситуации.
Читайте и учитесь любить принцип СУХОЙ . Много раз то, что вы склонны копировать / вставлять, может быть помещено в общее место (отдельная функция, отдельный класс, отдельная библиотека ...)
Читайте и учитесь любить ТВЕРДЫЕ принципы, и пока вы это делаете, просмотрите KISS, который уже упоминал mouviciel. Все эти принципы ориентированы на создание очень сжатого, чистого и модульного кода. Если у вас есть большие классы и большие функции внутри них, то, очевидно, будет гораздо сложнее находить вещи, и вдобавок ко всему попытаться объяснить, что делает код. С другой стороны, если вы будете следовать (или хотя бы попытаться следовать) SRP и сделать каждый класс / функцию ответственной только за одну вещь, ваш код будет небольшим и очень читабельным.
Возьмите копию Чистого кода . Очень хорошая книга. В нем говорится о написании кода, который говорит само за себя и легко читается, поддерживается и расширяется. Если вы практикуете написание легко читаемого кода, у вас не должно возникнуть проблем с чтением собственного кода в обзорах кода. И это забавная часть, я попросил людей прочитать их собственный код или просто сказать мне, что представляют собой переменные, и они не смогли ответить, даже если они написали этот код (совершенно новые классы, а не устаревшие) только неделю назад , Хорошее именование имеет большое значение.
Если после всех упрощений и рефакторинга у вас все еще есть функция, которая должна выполнять какой-то алгоритм, который не очень очевиден, найдите время и напишите в этой функции блок комментария, объясняющий алгоритм. Мало того, что это будет полезно, когда вам нужно будет изменить эту функцию через 2 месяца, но если вы попадете в засаду в обзоре кода, вы сможете просто прочитать то, что написали.
Если после всех вышеперечисленных пунктов у вас все еще есть проблемы? Вы новичок в команде и попросили поработать с большим количеством устаревшего кода? В этом случае может случиться так, что ваш TL будет A $$, и вы можете проявить инициативу, попросив его перед встречей пройти спокойно и не тратить время всех участников. Когда новые люди присоединяются к команде, TL нужно иметь достаточно терпения, потому что работа над новой платформой, новым продуктом, новыми людьми, новой средой требует большой концентрации от нового человека, и этот человек вначале упустит некоторые детали. Работает как Designed, и ваш TL должен просто принять это.
Если после всех вышеперечисленных пунктов вы по-прежнему чувствуете, что у вас есть ужасные отзывы кода. Поговорите с вашим TL. Иногда люди чувствуют себя плохо из-за характера встреч, посвященных проверке кода, когда на самом деле TL совершенно доволен вами. Когда я делаю обзоры кода, моя цель - выделить то, что необходимо изменить, убедиться, что вы понимаете изменения и двигаться дальше. Часто у меня нет времени быть вежливым, и некоторые люди начинают защищаться и пытаются ответить на каждый мой комментарий. В этих ситуациях встреча по пересмотру кода прекращается, поэтому я стараюсь прервать их и двигаться дальше. Вообще, после встречи я бы поговорил с новыми парнями, чтобы убедиться, что они понимают процесс и что в этом нет ничего личного. После нескольких обзоров кода люди, как правило, чувствуют себя намного комфортнее.