День 2761. #Карьера
Основные Правила Разработки ПО. Продолжение
Начало
12. Прежде чем судить о чужом коде, стремитесь понять его
Глядя на чужой код, вы думаете, что всё бы сделали не так. Прежде чем судить, попытайтесь понять контекст. Какие были ограничения, требования, кодовая база? Часто то, что кажется плохим решением, обретает смысл, когда вы понимаете всю историю целиком. Поймите бизнес-логику кода. Технические решения обретают больше смысла, когда вы понимаете бизнес-проблемы, которые он решает.
Но, если код действительно проблемный, критикуйте код, а не разработчика. Делайте код-ревью с эмпатией, предлагайте улучшения уважительно. Ваш код тоже когда-нибудь станет для кого-то «унаследованным беспорядком».
13. Документируйте «почему» вы принимали решения
Через полгода вы уже не вспомните, почему выбрали этот подход, а не тот. Ваши коллеги тоже. Со временем дизайн и принятые решения теряют контекст.
Документируйте важные решения, особенно когда приходится выбирать между разумными альтернативами. Используйте ADR, комментарии или проектную документацию. Объясните контекст, рассмотренные варианты и почему вы выбрали именно этот. Не обязательно формально, просто чтобы освежить память позже.
Хорошая документация — это фиксация «почему» были приняты неочевидные решения, рассмотренные компромиссы и ограничения, с которыми вы работали.
Документация имеет мультипликативный эффект: она поможет коллегам, если они застрянут, ускоряет адаптацию и предотвращает повторение ошибок. Час, потраченный на документирование, может сэкономить команде десятки часов.
14. Пишите содержательные сообщения коммитов
История коммитов - это история проекта. Хорошие сообщения коммитов помогают понять, что изменилось и почему, что значительно упрощает отладку, проверку кода и адаптацию новых сотрудников. Опишите не только, что вы исправили, но и почему. Это предоставит контекст для будущих разработчиков.
Обеспечьте чёткую коммуникацию также в пул-реквестах, тикетах и документации. Делайте пул-реквесты небольшими и управляемыми, чтобы их было легче проверять, и чтобы снизить вероятность появления ошибок. Чёткая коммуникация — отличительная черта поведения опытного специалиста, и она приносит пользу всем членам команды.
ИИ сейчас может писать сообщения коммитов, анализируя изменения в коде, но всегда проверяйте и редактируйте их, чтобы обеспечить точность и ясность.
15. Автоматизируйте всё, что можно
Установите стандарты кодирования на раннем этапе, автоматизируйте их соблюдение с помощью форматеров и линтеров и двигайтесь дальше. Будьте последовательны в стандартах.
Автоматизируйте тестирование, развёртывание, сканирование безопасности, обновление зависимостей и любые повторяющиеся задачи. CI/CD — не опция, а основа надёжной доставки.
Создавайте конвейеры с защитой: автоматический откат и всестороннее тестирование, чтобы уменьшить радиус поражения потенциальных проблем. Забудьте о «это работает на моей машине». Если это работает в конвейере, только тогда это работает везде.
16. Код-ревью улучшает не только качество
Это один из лучших способов обмена знаниями внутри команды и улучшения как кода, так и людей, которые его пишут. Джуны изучают шаблоны и практики. Сеньоры остаются в курсе того, что происходит в разных частях кодовой базы. Все узнают о новых областях, в которых они раньше не работали. Уменьшается разрозненность знаний, и команда становится более устойчивой.
17. Никогда не прекращайте учиться и подвергать сомнению предположения
Технологии развиваются быстро. Фреймворки, языки и инструменты, которые вы знаете сегодня, через 5 лет изменятся. Непрерывное обучение — это обязательное условие.
Но это не только погоня за новыми технологиями; стремитесь к пониманию. Изучите основы: алгоритмы, структуры данных, сети, безопасность и принципы проектирования. Освойте смежные навыки: коммуникацию, наставничество, управление проектами.
Поддержка работающих производственных систем предоставляет лучшие возможности для обучения. Только преодолевая трудности вы будете расти. Сталкивайтесь со сложными проблемами, устраняйте неполадки в проде и учитесь на ограничениях реального мира.
18. Обращайтесь за помощью, когда застряли
Застрять на несколько часов, потому что стесняетесь попросить о помощи, — пустая трата времени. Коллеги хотят помочь. Они сталкивались с похожими проблемами. У них разные точки зрения, они могут сразу заметить то, что вы упускаете. Просьба о помощи — это сильная сторона, а не слабость.
Ключ к успеху — задавать правильные вопросы. Покажите, что вы уже пробовали. Объясните своё текущее понимание, предоставьте контекст. Это поможет им помочь вам.
19. Оценки никогда не бывают абсолютно точными
Оценка — сложная задача. Всегда есть неизвестные факторы, неожиданные сложности и задачи, которые оказались простыми лишь на бумаге. Относитесь к оценкам как к обоснованным предположениям, а не обязательствам. Учитывайте неопределённость в своих оценках. Сравнивайте свои оценки с фактическими результатами, чтобы со временем улучшать их. Сообщайте как можно раньше, если обнаружите, что оценка неверна. Чётко сообщайте о компромиссах .
Вместо: «Это займёт 3 дня», говорите: «Думаю, что это займёт 3-5 дней, при условии отсутствия проблем с интеграцией API стороннего сервиса, с которым я раньше не работал. Я сообщу вам, как начну работу, если обнаружу сложности».
20. Вы не можете управлять тем, за чем не наблюдаете
Производственным системам необходима наблюдаемость. Иначе вы действуете вслепую, когда что-то идёт не так, а это обязательно произойдёт. Ведите логи, но не чрезмерно. Добавляйте логи, метрики, трассировки и оповещения, которые имеют значение.
Проектируйте системы с учётом возможности наблюдения с самого начала. Инструментируйте свой код для отслеживания ключевых метрик, производительности, ошибок и поведения пользователей. Убедитесь, что вы можете ответить на вопросы: «Здорова» ли система? Где узкие места? Каков пользовательский опыт? Когда начались сбои?
Совершенство в работе системы — это разница между устранением проблем за минуты, а не за часы, и между знанием о проблемах до того, как о них узнают пользователи, а не из обращений в службу поддержки. Надёжность важнее новых функций. Всегда.
Окончание следует…
Источник: https://www.meziantou.net/essential-rules-of-software-engineering.htm
4
2August 22, 2026 897 4 17
