Из программиста в инженера-программиста

Не так давно я написал три статьи на эту тему: первая, вторая и третья. В данной статье я лишь обобщу всё то, что писал там. Если желаете подробностей - смотрите там; тут же я лишь соберу основные советы с краткой сопроводительной информацией

Схематичный инженер, который ещё и программист

1. Чек-лист того, что надо сделать с кодом или приложением, чтобы не пропустить ничего важного;
2. Инструментарий поддержки приложения: использование системы контроля версий, автосборки, тестирования, автоматизации процессов (преимущественно, через утилиты командной строки);
3. Инструменты совершенствования качества кода: анализаторы кода, линтеры, нулевая терпимость к предупреждениям;
4. Писать понятный, прежде всего, человеку код;
5. Не ждать идеальной проработки задачи, а начинать что-то делать уже сейчас: в процессе много чего может поменяться;
6. Автодокументация и внятные комментарии, объясняющие почему принято такое решение - сильно упрощают процесс поддержки кода;
7. Писать код, который требуется сейчас, а не тот, который может потребоваться в будущем (при таком подходе будущее может не наступить);
8. Хранить в актуальном состоянии все используемые ресурсы проекта (схемы, скрипты, временные данные и прочее), можно даже вместе с проектом в системе контроля версий;
9. Менять код по чуть-чуть; от простого к сложному, от малого к большому;
10. Обрабатывать исключения: не всегда это кажется нужным, но в дальней перспективе всегда оказывается оправданным;
11. Замерить цикломатическую сложность своего кода и стараться поддерживать его не выше определённого значения (скажем, 7 или 10);
12. Упростить свою кодовую базу: один метод отвечает за что-то одно - принцип единой ответственности ("S" из SOLID);
13. Пусть имена и типы входных и выходных данных сообщают информацию о методе, даже если его имя ещё не задано;
14. Цель работы - результат, процесс - лишь средство достижения результата: если процесс мешает достижению результата, от процесса можно и отступить (для случаев, когда решение нужно вчера, а процесс требует 2 месяца на тестирование);
15. Планировать и резервировать методы/классы/компоненты под будущий функционал в мастер-ветке, несмотря на то, что код ещё не готов (как будет готов - удалить код, требующий директиву компилятора/переменную окружения/флаг приложения для запуска);
16. Ещё раз: большие изменения следует делать по чуть-чуть, хотя бы для того, чтобы фатально не обрушить приложение;
17. Заниматься производительностью надо тогда, когда это уместно: не всегда усилия, потраченные на совершенствование метода оправданы, т.к. выигрыш в одном месте может быть заблокирован другим;
18. Обеспечивать минимальный уровень безопасности своего кода (прочее потребуют соответствующие специалисты);
19. Выполнять, при возможности, поведенческий анализ кода: он не станет прямо пещерой Али-бабы с открытиями, но вполне сойдёт как повод для улучшения кодовой базы.