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