День 2760. #Карьера
Основные Правила Разработки ПО. Начало
Я уже не раз приводил здесь подобные советы от опытных разработчиков. Gérald Barré (aka meziantou) также составил свой список.
1. Вам платят не за код, а за решение проблем
Написание кода — не цель, а средство её достижения. Ваша ценность как инженера в понимании бизнес-проблем и предоставлении решений, которые создают ценность для пользователей и организации.
Иногда лучшее решение - отсутствие кода. Возможно, изменение процесса сработает лучше, существующий инструмент можно настроить по-другому, а может проблему и не нужно решать. Прежде чем приступать к реализации, уделите время пониманию сути проблемы, проанализируйте ситуацию, исходя из желаемого результата, и рассмотрите все возможные подходы.
2. Нет «лучшего» решения, есть только компромиссы
Разработка ПО – это принятие решений на основе неполной информации. У каждого вашего выбора есть плюсы и минусы, и то, что подходит для одного проекта, может оказаться ужасным для другого.
- Микросервисы? Зависит от размера команды, потребностей в масштабируемости и операционной сложности, которая вам под силу.
- SQL/NoSQL? Зависит от структуры данных, шаблонов запросов и требований к согласованности.
- TDD? Зависит от контекста, опыта команды и ограничений проекта.
Опытный инженер не ищет «лучшее» решение. Он оценивает компромиссы, исходя из текущих ограничений: навыков команды, сроков, бюджета, потребностей в масштабируемости и требований к сопровождению. Задокументируйте, почему вы выбрали тот или иной вариант. В будущем вы (или коллеги) оценят понимание контекста, лежащего в основе принятых решений. Всегда знайте, что именно вы оптимизируете: производительность, удобство сопровождения, время выхода на рынок, скорость работы команды и т.п.
Когда вы ходите по кругу, не находя чёткого «хорошего решения», это обычно означает, что вы недостаточно определили ограничения для проблемы. Добавьте больше ограничений: бюджет, дедлайн, размер команды, допустимый уровень технического долга, ожидаемый масштаб.
3. Чем меньше кода, тем лучше
Больше кода - больше работы по поддержке, тестированию, отладке и поиску ошибок. Лучший код часто тот, который вы не написали. Каждая строка должна оправдывать своё существование.
Прежде чем добавлять новую функцию или абстракцию, спросите себя: действительно ли это необходимо? Могу ли я решить это с помощью существующего кода? Решаю ли я существующую проблему или ту, которая, как я думаю, может возникнуть в будущем? Немедленно удаляйте неиспользуемый код. Мёртвый код создает путаницу, увеличивает нагрузку на поддержку и создаёт ложное представление о том, что система на самом деле делает.
4. Каждая зависимость — это обуза
Зависимости могут быть заброшены, содержать уязвимости безопасности, незаметно ломаться при обновлениях или приводить к появлению транзитивных зависимостей, которые вы никогда не планировали включать, а также могут препятствовать обновлению других пакетов из-за несовместимости.
Регулярно проверяйте зависимости. Удаляйте неиспользуемые. Оценивайте состояние проектов, от которых вы зависите (последние коммиты, активные сопровождающие, история безопасности). Учитывайте общую стоимость владения, а не только первоначальное удобство.
5. Выпускайте рано, итерируйте часто
Идеальность — враг завершённости. Чем дольше вы оттягиваете выпуск, тем дольше откладываете получение реальной обратной связи от пользователей. Сначала сделайте, чтоб работало, затем сделайте это правильно, а затем сделайте это быстрым.
Ранние релизы помогают проверить предположения, выяснить, что действительно нужно пользователям (в отличие от того, что вы думаете, что им нужно), и скорректировать курс. Выбрасывать код больно, но ещё больнее потратить полгода на создание неправильного продукта.
Опросы пользователей, прототипы и моки могут проверить идеи до написания кода. Иногда простой разговор показывает, что запланированная вами функция совсем не то, что нужно пользователям. Внедряйте механизмы обратной связи в процесс разработки, чтобы расти как инженер.
6. Проектируйте с учётом изменений, т.к. ПО никогда не бывает завершённым
Потребности пользователей и технологии меняются, платформы обновляются, и обнаруживаются уязвимости безопасности. Сделайте так, чтобы ПО было легко модифицировать, расширять и поддерживать. Создавайте с учётом расширяемости и ясности. Проводите рефакторинг непрерывно и постепенно, а не ждите «большой переработки». Сочетайте принцип YAGNI с продуманным проектированием, которое не загонит вас в тупик. Делайте изменения по возможности обратимыми, чтобы вы могли быстро откатить их, если возникнут проблемы. Помните о техническом долге и погашайте его постепенно, прежде чем он начнёт накапливаться.
7. Пишите код в первую очередь для людей
Код читается гораздо чаще, чем пишется. Вы можете потратить час на написание функции, но десятки разработчиков могут прочитать её сотни раз за годы. Пишите код, с которым другим разработчикам будет приятно работать.
Поддерживаемость означает чёткое именование, простую логику, хорошую структуру и соответствующие комментарии. Выбирайте ясность, а не хитрость, описательное именование, а не поясняющие комментарии. Избегайте хитрых трюков, которые экономят две строки, но требуют пяти минут для понимания. Это означает думать о разработчике, который будет отлаживать это в 2 часа ночи, когда прод лёг.
8. Сложность губит проекты — сохраняйте простоту
Умная абстракция, которой вы так гордитесь, сложный паттерн проектирования, который вы реализовали… У сложности есть цена. Каждый уровень абстракции, каждое косвенное обращение, каждый «гибкий» дизайн делают систему сложнее для отладки и анализа. Предпочитайте скучные, простые решения, которые легко понять. Создавайте системы, которые можно объяснить на доске. Абстракция должна скрывать сложность, а не создавать её. Соблюдайте принцип наименьшего удивления: код должен вести себя так, как того ожидают от него другие разработчики.
Вообще, оверинжиниринг — часть пути разработчика. Нужно пройти через это, чтобы начать ценить простоту. Но как только вы это сделаете, вы никогда не захотите вернуться назад.
9. Устраняйте причины, а не симптомы
Когда вы обнаруживаете ошибку, сопротивляйтесь желанию быстро её исправить. Уделите время, чтобы понять, почему это произошло. Временные решения приводят к хрупким системам с нагромождением исправлений.
Найдите причину. Исправьте её должным образом. Да, это займет больше времени и может потребовать рефакторинга. Но вы предотвратите связанные ошибки и построите более надёжную систему. Исправление класса ошибок в корне гораздо эффективнее, чем многократное устранение отдельных симптомов. См. также: «Я исправил ошибку. Что дальше?»
10. Поймите «почему», прежде чем двигаться дальше
Когда что-то не работает или ведёт себя иначе, чем вы ожидали, не просто меняйте что-то, пока не заработает. Это заманчиво, но опасно. Вы получаете код, который не понимаете, потенциальные скрытые ошибки и упущенные возможности для обучения.
Убедитесь, что вы понимаете, почему код вёл себя именно так. Какое предположение было неверным? Что вы неправильно поняли о фреймворке, библиотеке или языке? В чём была реальная причина неожиданного поведения? Без понимания причин вы не развиваете свои навыки и не создаёте надёжное ПО.
Уделите время исследованию. Читайте документацию. Задавайте вопросы. Проводите эксперименты для проверки своих гипотез. Полученное понимание поможет избежать подобных проблем в будущем и углубит ваши знания используемых инструментов.
11. Не влюбляйтесь в свой код
Ваш код — не отражение вашей ценности как разработчика. Это инструмент для решения проблемы, и, если есть лучший инструмент или лучший способ, вы должны быть готовы отказаться от своего.
Эмоциональная привязанность к коду вынуждает вас защищаться во время код-ревью, сопротивляться изменениям и не замечать лучших решений. Хорошие инженеры регулярно удаляют свой код, рефакторят свои проекты и признают, когда их подход был не лучшим.
Продолжение следует…
Источник: https://www.meziantou.net/essential-rules-of-software-engineering.htm
9
1August 21, 2026 919 2 20
