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