Это распространенная модель, которая сдерживает молодых разработчиков.

Вы получаете требования к новой функции и сразу же погружаетесь в детали. Часто мелкие связанные вопросы заводят вас в длинные косвенные тупики.

Сотрудничая с менее опытными разработчиками, я понимаю, чего им не хватает. Но это сложная концепция для обучения. Это эссе — моя попытка объяснить, почему общая картина всегда важнее мелких деталей.

Получите правильную общую картину, и детали станут тривиальными.

Разве кодирование не связано с деталями?

Да и нет.

Отсутствие крошечной детали, безусловно, может привести к плохому поведению в коде. Но небольшие ошибки также легко проверить. Их легко исправить.

Реализация запроса функции включает в себя реализацию пользовательских историй. Иногда эти требования могут быть весьма специфическими. Но самый важный вопрос не в том, «О чем говорится в требованиях?»

Самый главный вопрос:

Что пытается сделать пользователь?

Иногда требования не имеют смысла

Часто требования не совпадают с тем, что пытается сделать пользователь.

Или есть более простой способ достичь той же цели. Ваша работа как инженера-программиста состоит в том, чтобы находить эти более простые решения. Быть ценным разработчиком — значит повышать ценность для пользователей.

Лучшие инженеры — это те, кто понимает общую картину. Они сосредоточены на решении потребностей пользователей. Как только они поймут требования высокого уровня, детали кодирования могут разобраться сами собой.

Никогда не задумывались, почему опытные разработчики часто открывают такие маленькие PR?

Это потому, что они достаточно осведомлены о пользовательской истории, чтобы понять точную степень необходимых изменений. Опытные разработчики не обязательно боги программирования. Вместо этого они действительно хороши в хирургическом внедрении функций, которые имеют смысл для пользователя.

Один подарок: постоянное переключение

Если вы обнаружите, что открываете много вкладок во время написания кода, пришло время подвергнуть сомнению ваш подход.

Конечно, чтобы найти точную точку реализации, вам нужно пройти по трассировке до правильной логики. Но опасность отвлекает внимание на детали в других частях кода. Прыгание во время решения проблемы ограничивает вас.

Я был свидетелем этого из первых рук с неопытными разработчиками, когда мы работали в паре. Они открывают много вкладок! Они постоянно отслеживают пути кода. Я должен остановить их и сказать: «Давайте вернемся к тому, что мы рассматривали три вкладки назад».

Я напоминаю им: «Что мы пытаемся сделать?»

Это хорошая мантра, которую нужно помнить. Что я пытаюсь сделать? Как я могу выполнить это с самым чистым следом?

Ограничение области

Вы всегда найдете код, который мог бы использовать рефакторинг.

Всегда есть области, которые можно реализовать лучше.

Важный урок для молодых инженеров: если что-то реализовано не идеально, это не значит, что его нужно рефакторить.

Не проводите рефакторинг кода, который работает, не ограничивает новую разработку и обрабатывает крайние случаи.

Время, потраченное на то, что не является узким местом, потрачено впустую.

Дополнительные ресурсы

Я пишу ежедневный список адресов электронной почты для разработчиков программного обеспечения, строящих значимую карьеру. Присоединяйтесь к нам!

Join Medium for $5 - Access all of Medium + support me & others!