5 простых советов младшим разработчикам, чтобы получать меньше комментариев к вашим PR
На полпути к тому, чтобы стать веб-разработчиком (инженером-программистом, разработчиком переднего плана, программистом — называйте это как хотите), я присоединился к небольшому технологическому стартапу для стажировки.
Я справлялся со своими задачами быстро и довольно эффективно, я многому научился и большую часть времени чувствовал себя довольно хорошо — или, по крайней мере, до тех пор, пока мне не пришлось запрашивать проверку кода. У разработчика, который контролировал меня, были высокие стандарты, и иногда мне казалось, что я никогда не смогу сделать что-то правильно и слить свой код без множества комментариев.
В то время меня разочаровывало то, что я молодой и новый разработчик, спешащий «сделать». Теперь, будучи более опытным программистом, когда я просматриваю код, написанный младшими разработчиками, я намного лучше понимаю своего наставника по стажировке. Иногда мы, разработчики, настолько сосредоточены (и увлечены) написанием кода, который на самом деле работает, что легко забываем обо всем остальном.
Итак, вот несколько вещей, которые я узнал не только из безжалостного… рецензирования моего кода, но и из анализа запросов на включение (PR) других разработчиков.
1. Читайте свой собственный код
Я знаю, я знаю, это звучит очевидно. Но мне потребовалось некоторое время, чтобы вникнуть в эту практику. После того, как вы поднимете свой PR, просто откройте вкладку «файлы» и представьте, что вы теперь код-ревьюер, а не разработчик, который его написал. Пролистайте все строки и будьте критичны. Ты что-то забыл? Что-то похоже на то, что это должно быть реорганизовано? Поверьте мне, вы почти всегда гарантированно заметите что-то сами раньше, чем это сделают другие.
2. Наведите порядок
Вещи, которые вы должны удалить, прежде чем предоставить свой код рецензентам, должны включать:
- консольные операторы,
- Комментарии «todo» — обычно старайтесь избавиться от как можно большего количества комментариев. Если вы дали своим функциям и переменным правильные имена, в большинстве случаев вам на самом деле не нужен этот комментарий, объясняющий, что делает функция. Их все равно никто читать не будет и они только наведут бардак в кодовой базе,
- избыточные функции, которые больше не используются после вашего рефакторинга,
- избыточные переменные, которые больше не используются после вашего рефакторинга,
- избыточный импорт модулей, которые вы больше не используете,
- несколько строк, импортирующих разные модули из одного и того же файла, например:
импортировать {myFunction} из «./util.js»;
импортировать {mySecondFunction} из «./util.js»;
следует переписать в
импортировать {myFunction, mySecondFunction} из «./util.js»;
3. Сократите все, что можете
Существуют разные способы решить, является ли размер вашего PR разумным или он слишком велик, чтобы рецензент мог сосредоточиться. В общих правилах упоминается обычно не более 400 строк. Я думаю, что это уже много, и лично я, если нет действительно уважительной причины, не утруждайте себя просмотром PR с более чем 10 файлами (да, я смотрю файлы, а не строки).
Я помню, как однажды кто-то попросил меня просмотреть PR, состоящий из 35 файлов. Он протолкнул целую функцию, несколько страниц функциональности (sic!), и все это за один раз. Чтобы просмотреть его код, мне пришлось устроить демо-встречу с этим разработчиком, а презентация плюс его объяснение заняли более получаса, после чего мне еще предстояло просмотреть реальный код. Подумайте о том, какая это пустая трата времени как для рецензента, так и для владельца кода!
Правило «чем меньше, тем лучше» применимо и к функциям, которые вы пишете. Пока вы проводите самопроверку, прежде чем отдать свой код этим безжалостным гарпиям, также известным как ваши товарищи по команде, попробуйте реорганизовать свои функции в ~5 строк. Дайте им осмысленные имена тоже. Если вы сомневаетесь, возможно ли это — да, возможно. Каждый раз, когда вам нужно написать условие, у вас есть возможность извлечь код из этого условия в отдельную функцию.
Итак, из «спагетти-кода» вот так:
вы можете извлечь дополнительные пятьфункций, которые более удобочитаемы:
Приведенный выше код может показатьсядлиннее и как будто на его написание уходит слишком много времени. Однако его легче пересматривать и поддерживать в будущем, когда придут изменения, а поскольку мы все работаем в Agile, изменения придут.
4. Называйте вещи так, как вы это имеете в виду
Как человек, написавший этот код, вы знаете, что такое «r» и почему его нужно добавлять к «t», чтобы вернуть «g» через функцию «rToG». Но рецензент этого не узнает. Поэтому, если область действия переменной не является только одной строкой, например, например:
const longName = allNames.find((n) => n.length › 1);
обязательно дайте ему имя, которое будет понятно другим разработчикам.
Сокращение длинных имен до буквенных — тенденция прошлого. Теперь у нас есть продвинутые компиляторы и транспиляторы, чтобы убедиться, что наш код не будет занимать слишком много места, поэтому вы можете расслабиться и заменить «r» на «response», а «t» на «blogTitle».
Тот же совет относится и к именам функций. Если ваша функция извлекает данные, добавьте к ней префикс «получить». Если он где-то присваивает данные, добавьте к ним префикс «set». Если у вас есть логическое значение, добавьте к нему префикс «is», например. «ИсПейджАктив». Чем больше вы объясните своими именами, тем меньше вопросов возникнет у ваших рецензентов.
5. Следуйте стандартам организации
Я пишу этот совет последним не только потому, что он самый очевидный, но и потому, что, к сожалению, не в каждой организации есть хорошо документированные стандарты кодирования. Однако, если у вас есть, важно следовать им.
Некоторые компании предоставляют своим разработчикам настройки для линтеров, некоторые имеют программное обеспечение (например, Sonar Cube) для проверки качества кода. Обязательно следуйте и выполняйте все, что требует от вас ваша организация.
Каков ваш опыт создания и/или пересмотра PR? На что вы обращаете внимание при ревью кода? Что помогло вам улучшить собственный код? Давайте обсудим в комментариях!
