День 2762. #Карьера
Основные Правила Разработки ПО. Окончание
Начало
Продолжение
21. Никогда не доверяйте пользовательскому вводу
Пользователи допускают ошибки, а злоумышленники активно пытаются взломать вашу систему. Никогда не доверяйте пользовательскому вводу, будь то из форм, API, при загрузке файлов или в параметрах URL.
Проверяйте все входные данные: типы, форматы, диапазоны и допустимые значения. Очищайте данные, чтобы предотвратить атаки инъекцией. Используйте параметризованные запросы, кодирование и проверенные библиотеки безопасности, а не разрабатывайте собственные решения.
22. Ошибки должны приводить к громкому и немедленному сбою
Тихие сбои — кошмар отладки. Когда что-то идёт не так, сделайте это очевидным. Сообщайте об ошибках быстро, громко и предоставляйте чёткие сообщения об ошибках, которые помогут быстро выявить проблему.
Не игнорируйте исключения. Не возвращайте null при сбое. Не продолжайте работу, записав в лог. Когда не выполняется предусловие, данные невалидны, необходимый сервис недоступен, остановите выполнение и чётко сообщите о проблеме.
Хорошая обработка ошибок подразумевает быстрое выявление и устранение неполадок с чёткими сообщениями, предоставлением контекста о том, что пошло не так и почему, а также упрощением отслеживания источника ошибки. Это экономит часы отладки.
23. Сначала измерьте, потом оптимизируйте
Преждевременная оптимизация — корень всех зол. Разработчики часто тратят время на оптимизацию кода, который на самом деле не является узким местом, усложняя его без существенного повышения производительности.
Перед оптимизацией профилируйте приложение. Выявите реальные, а не предполагаемые узкие места. Вы можете обнаружить, что медленная часть вовсе не там, где вы думали. Оптимизируйте проблемные области и снова проведите измерения, чтобы проверить улучшение.
Не игнорируйте производительность полностью. Пишите достаточно эффективный код изначально, но не жертвуйте ясностью и удобством сопровождения ради микрооптимизаций. Знайте, что вы оптимизируете: задержку, пропускную способность, память или время разработки.
24. Меняйте по одной вещи за раз
При отладке или оптимизации сопротивляйтесь желанию изменять несколько вещей одновременно. Так вы не будете знать, какое именно изменение исправило ошибку или улучшило производительность. Внесите одно изменение, измерьте результат, а затем продолжайте. Такой дисциплинированный подход может показаться медленнее, но он экономит время, предоставляя чёткие причинно-следственные связи. Вы построите мысленную модель того, что действительно важно, и избежите разочарования от отмены целого ряда изменений, потому что одно из них сломало что-то другое.
Аналогично при рефакторинге изменяйте либо структуру, либо поведение, но не то и другое одновременно. При развертывании выпускайте по одной функции за раз, чтобы изолировать проблемы.
25. Создавайте API, которые легко использовать правильно и сложно неправильно
Хороший дизайн предотвращает ошибки до их возникновения. При проектировании функции, класса или интерфейса сервиса подумайте о том, как они будут использоваться и как их можно использовать неправильно.
Используйте типы для обеспечения ограничений (обязательность, допустимые диапазоны, разрешённые состояния). Сделайте недопустимые состояния непредставимыми. Используйте чёткие имена, указывающие на назначение и поведение. Предоставляйте хорошие значения по умолчанию. Сделайте распространённые случаи простыми, а сложные — возможными. Возвращайте содержательные ошибки, которые помогут разработчикам правильно использовать API.
Отдавайте предпочтение композиции перед наследованием. Композиция более гибкая и создаёт меньше проблем со связностью. Минимизируйте связь между компонентами и максимизируйте их согласованность. Каждый модуль должен иметь чёткое назначение.
26. Будьте хорошим человеком важнее технических навыков
Разработка — командный вид спорта. Техническое мастерство ничего не значит, если с вами трудно работать, вы неэффективно общаетесь или не поддерживаете своих коллег.
Будьте добры, терпеливы, делитесь заслугами, признавайте ошибки, помогайте другим расти, больше слушайте, уважайте разные точки зрения и стили работы. У каждого есть трудности, которых вы не видите. Ваше отношение и навыки сотрудничества важнее для вашей карьеры, чем любые технические навыки.
Поддерживайте коллег, когда у них возникают трудности. Отмечайте их успехи. Создавайте среду, где люди чувствуют себя комфортно, задавая вопросы, признавая, что чего-то не знают, или высказывая свои опасения. Это укрепляет доверие и побуждает людей сообщать о проблемах на ранних стадиях, а не скрывать их.
27. Думайте о последствиях, а не только о решениях
Большинство инженеров оптимизируют решения. Архитекторы оптимизируют последствия. Обе роли важны, но они решают разные классы проблем.
Сеньоры задаются вопросом: «Как построить это хорошо?» Архитекторы: «Что произойдёт, если мы ошибаемся?» Этот сдвиг в перспективе меняет то, что вы оптимизируете. Вместо того чтобы фокусироваться на локальной производительности или качестве реализации, минимизируйте возможный ущерб, оптимизируйте обратимость и долгосрочные эксплуатационные расходы.
Ваш прогресс как архитектора – это учитывание последствий необратимых решений, компромиссов в выборе инструментов, ограничений в выборе возможностей и побочных эффектов. Уменьшайте сложность не только внутри функции, но и в командах и организации в целом.
Архитектура — это не рисование диаграмм. Это выбор того, с какими последствиями вы готовы смириться, и принятие ответственности за этот выбор.
Итого
Это не строгие законы, а рекомендации, основанные на опыте, ошибках и извлечённых уроках. Возьмите то, что вам близко, адаптируйте к своему контексту и помните, что разработка ПО — это в равной степени код, люди и коммуникация.
Лучшие инженеры — не те, кто пишет самый умный код, а те, кто приносит пользу, эффективно сотрудничает, постоянно учится и делает лучше всех вокруг себя. Развивайте свои принципы, основываясь на собственном опыте. Каждый проект, каждая команда и каждое испытание учат вас чему-то новому.
Источник: https://www.meziantou.net/essential-rules-of-software-engineering.htm
5
1August 23, 2026 865 24 12
