Начиная новый проект, хорошо вспомнить полезные принципы программирования, которые помогут правильно расставить приоритеты и избежать многих ошибок. Рекомендациями от автора с опытом программирования в 20 лет делимся к старту курса по Fullstack-разработке на Python.
Официально я программирую с 1999 года. Начинал с Basic, вскоре перешёл на Pascal и C, а затем изучил объектно-ориентированное программирование на Delphi и C++. В 2006 году стал работать с Java, а в 2011-м — с JavaScript. Сотрудничал с компаниями из самых разных сфер — от робототехники, финансов и медицины до медиа и телекома.
Иногда я становился исследователем, техническим директором или менеджером продукта, преподавателем, разработчиком системной архитектуры или техническим руководителем проекта, но всегда писал код.
Я работал и над продуктами, которыми пользовались миллионы людей, и над теми, что терпели неудачу ещё до выпуска. Я работал консультантом и даже основал свой стартап. Я потратил много времени на проекты с открытым, закрытым кодом, а также внутренние Open Source проекты, то есть проекты с проприетарным кодом, который разрабатывается сообществом внутри компании.
Я работал над крошечными микроконтроллерами, мобильными и настольными приложениями, облачными серверами, а в последнее время — бессерверными технологиями. К двадцатилетию карьеры я составил список главных принципов, которыми руководствовался все эти годы:
-
Не боритесь с инструментами: библиотеками, языком, платформой и т. д. Используйте как можно более нативные конструкции. Не перегибайте с технологией и с задачей. Выберите подходящий инструмент для задачи, или придётся найти подходящую задачу для того инструмента, что есть.
-
Вы пишете код не для компьютера, а для своих коллег и для себя в будущем, если только это не пробный проект или ассемблер. Пишите его как руководство для младших коллег.
-
Любой значимый, ценный программный компонент — это результат совместной работы. Взаимодействуйте эффективно, сотрудничайте открыто. Доверяйте другим и добивайтесь доверия от них. Уважайте людей больше, чем код. Вдохновляйте своим примером последователей, превращая их в лидеров.
-
Следуйте принципу «разделяй и властвуй». Пишите изолированные модули с отдельными, слабо связанными задачами. Тестируйте каждую часть отдельно и все вместе. Проводите тесты в условиях, приближенных к реальности, но тестируйте и пограничные случаи.
-
Не задирайте нос и не считайте себя главным специалистом по коду. Оптимизируйте его так, чтобы другие могли найти свой способ исправить баги и добавить функционал. Освободитесь от кода, чтобы перейти к следующему проекту или компании. Не присваивайте код себе, иначе вы никогда из него не выберетесь.
-
Есть несколько уровней безопасности: каждый нужно оценивать индивидуально, а также по отношению к безопасности в целом. Риск — это бизнес-решение, напрямую связанное с уязвимостью и вероятностью событий. У каждого продукта/организации свой уровень риска, на который в организации готовы пойти ради ещё большей выгоды. Пользовательский интерфейс, безопасность, производительность — эти три задачи часто противопоставляются.
-
У всего кода есть жизненный цикл. Иногда код умирает в зачаточном состоянии, ещё до производственной среды. Умейте отпустить. Различаются четыре категории функционала, в которые нужно вкладывать время и силы.
Основа. Это как движок автомобиля. Без неё продукт не имеет смысла.
Необходимая часть. Похожа на запаску: редко используется, но определяет успех системы, когда требуется.
Дополнительные возможности. Это как подстаканник: ну есть и есть, хотя продукт вполне можно использовать и без него.
Уникальные свойства: почему стоит купить продукт у вас, а не у ваших конкурентов. Например, ваш автомобиль — лучший внедорожник. -
Не отождествляйте себя со своим кодом. И вообще не отождествляйте код с его автором. Поймите, что люди отделены от производимых ими артефактов. Не принимайте критику кода на свой счёт и будьте очень осторожны, критикуя чужой код.
-
Технические недоработки — это как фастфуд. Иногда допустимо, но, если к ним привыкнуть, они убьют продукт очень быстро и болезненно.
-
Определяясь с решением, при прочих равных условиях выбирайте такую приоритетность: безопасность > надёжность > практичность (доступность и пользовательское взаимодействие) > удобство сопровождения > простота (процесс разработки / впечатления от разработки) > лаконичность кода > финансы > производительность. Но не стоит слепо ей следовать: приоритетность зависит от характера продукта. Чем больше у вас опыта, тем скорее вы сможете найти правильный баланс для каждой конкретной ситуации. Например, при разработке игрового движка главный приоритет — производительность, но при создании банковского приложения — безопасность.
-
Баги размножаются копипастой. Всегда читайте то, что копируете, и всегда проверяйте, что импортируете. Баги любят сложность. Магия хороша в зависимостях, а не в коде.
-
Не пишите код только для хорошего сценария. Пишите сообщения об ошибках, где есть ответы на вопросы о том, почему они произошли, как были обнаружены и что можно сделать для их устранения. Проверяйте весь системный ввод (в том числе пользовательский): ранний сбой, но с восстановлением после ошибок, когда это возможно. Представьте себе опасного пользователя: вы приложите все силы, чтобы избежать проблем с ним!
-
Используйте зависимости, только когда они удовлетворяют требованиям и затраты на импорт, сопровождение, устранение пограничных случаев / багов и рефакторинг у них значительно меньше, чем у вашего кода.
-
Сторонитесь разработки, вокруг которой поднят ажиотаж. Но учитесь всему, чему можно научиться. У вас всегда должен быть ваш проект.
-
Выйдите из зоны комфорта. Учитесь каждый день. Учите других тому, чему научились. Изучайте другие языки, технологии, культуру и оставайтесь любознательными.
-
Хорошему коду документация не нужна, а отличный код хорошо документирован: любой, кто не участвовал в развитии и изменении кода методом проб и ошибок, а также требований, которые привели к его текущему состоянию, может продуктивно с ним работать. Недокументированный — значит несуществующий функционал. У такого функционала кода быть не должно.
-
Максимально избегайте переопределений, наследований и неявных трюков, демонстрирующих ваш ум. Пишите чистые функции, их проще объяснить. Любая функция, которая не является чистой, должна быть классом. Любая конструкция кода, имеющая другую задачу, должна отличаться именем.
-
Никогда не начинайте писать код (создавать решение), если не полностью понимаете задачу. Вполне нормально на её уяснение тратить больше времени, чем на ввод кода. Разберитесь в предметной области, затем приступайте к написанию кода. Задача подобна лабиринту: чтобы дойти до конца, нужно последовательно пройти цикл «код — тестирование — улучшение» и изучить пространство предметной области.
-
Не решайте проблему, которой не существует. Не занимайтесь спекулятивным программированием. Пишите код с возможностью расширения, только когда есть подтверждённое предположение, что он будет расширен. Ко времени расширения постановка задачи, скорее всего, будет другая.
Не усложняйте: занимайтесь текущей задачей и поиском эффективного решения с эффективной реализацией.
-
Разрабатывать ПО интереснее вместе. Создайте жизнеспособное сообщество. Слушайте. Вдохновляйте. Учитесь. Обменивайтесь опытом.
Я не претендую на то, чтобы считаться авторитетом в разработке ПО — всего лишь поделился своим опытом. Уверен, что через 20 лет этот список пополнится.
А пока автор дополняет список, мы поможем вам прокачать скиллы или с самого начала освоить профессию, актуальное в любое время:
Выбрать другую востребованную профессию:
Краткий каталог курсов и профессий
Data Science и Machine Learning
Python, веб-разработка
Мобильная разработка
Java и C#
От основ — в глубину
А также
Автор:
honyaki