Домой Полезные советы Мои главные принципы после 20 лет программирования

Мои главные принципы после 20 лет программирования

130
Мои главные принципы после 20 лет программирования
Мои главные принципы после 20 лет программирования

Мои главные принципы после 20 лет работы.

Я занимаюсь программированием с 1999 года, и в этом году я программирую, официально, уже более 20 лет. Я начал с Basic, но вскоре перешел на Pascal и C, а затем изучил объектно-ориентированное программирование (ООП) на Delphi и C++. В 2006 году я начал с Java, а в 2011 году — с JavaScript. Я работал с широким кругом компаний — от робототехники, финансовых технологий, медицинских технологий до СМИ и телекоммуникаций. Иногда у меня была другая роль — исследователя, технического директора, TPM (технического менеджера продукта), преподавателя, системного архитектора или TL (технического лидера), но я всегда занимался программированием. Я работал над некоторыми продуктами, которые послужили миллионам людей, и над некоторыми, которые провалились еще до их выпуска. Я работал консультантом и даже имел свой собственный стартап. Я провел много времени в проектах с открытым исходным кодом, проектах с закрытым исходным кодом и внутренних проектах с открытым исходным кодом (собственный код, разработанный сообществом внутри компании). Я работал с небольшими микроконтроллерами, мобильными и настольными приложениями, облачными серверами и, в последнее время, с бессерверными системами.

К 20-летию программирования я попытался перечислить основополагающие принципы, которые накапливались годами как мои главные принципы на протяжении всей моей карьеры:

  1. Не боритесь с инструментами: библиотеками, языком, платформой и т.д. Используйте как можно больше родных конструкций. Не гнушайтесь технологией, но и не гнушайтесь проблемой. Выберите подходящий инструмент для работы или вам придется найти подходящую работу для выбранного вами инструмента.
  2. Вы не пишете код для машин, вы пишете его для своих коллег и для себя в будущем (если только это не бросовый проект или вы пишете на ассемблере). Напишите его для неопытных в качестве справочника.
  3. Любая значимая и полезная часть программного обеспечения является результатом совместной работы. Эффективно общаться и открыто сотрудничать. Доверяйте другим и заслужите их доверие. Уважайте людей больше, чем код. Подавайте пример. Превратите своих последователей в лидеров.
  4. Разделяй и властвуй. Пишите изолированные модули с отдельными обязанностями, которые слабо связаны между собой. Протестируйте каждую часть отдельно и вместе. Приближайте тесты к реальности, но тестируйте и крайние случаи.
  5. Откажитесь от себя. Не будьте тем человеком, к которому можно обратиться за кодом. Оптимизируйте его для того, чтобы люди могли найти свой путь, исправляя ошибки и добавляя функции в код. Освободите себя, чтобы перейти к следующему проекту/компании. Не владейте кодом, иначе вы никогда не сможете развиваться дальше.
  6. Безопасность имеет несколько слоев: каждый слой должен оцениваться отдельно, но также и по отношению к целому. Риск — это бизнес-решение, которое напрямую связано с уязвимостью и вероятностью. У каждого продукта/организации свой уровень риска (риск, на который они готовы пойти ради более высокой прибыли). Часто эти 3 проблемы борются друг с другом: UX, безопасность, производительность.
  7. Поймите, что каждый код имеет свой жизненный цикл и когда-нибудь умрет. Иногда он умирает в зачаточном состоянии, так и не увидев свет в продакшене. Будьте готовы к этому. Знайте разницу между 4 категориями функций и то, на что следует тратить время и энергию:
    Ядро: как двигатель в автомобиле. Без него продукт не имеет смысла.
    Необходимая часть: как запасное колесо в автомобиле. Его редко используют, но когда оно необходимо, его функция решает успех системы.
    Добавленная стоимость: как подстаканник в автомобиле. Его приятно иметь, но продукт вполне можно использовать и без него.
    Уникальное торговое предложение: основная причина, по которой люди должны купить именно ваш продукт, а не ваших конкурентов. Например, ваш автомобиль — лучший внедорожник.
  8. Не связывайте свою личность с кодом. Не связывайте личность человека с его кодом. Поймите, что люди отделены от своих творений. Не принимайте критику кода близко к сердцу, но будьте очень осторожны, критикуя код других.
  9. Технологический долг — это как фастфуд. Время от времени это допустимо, но если вы привыкнете к этому, это убьет продукт быстрее, чем вы думаете (и болезненно).
  10. При выборе решения, при прочих равных условиях, остановитесь на этом приоритете: Безопасность > Надежность > Удобство использования (доступность и UX) > Ремонтопригодность > Простота (опыт разработчика/DX) > Краткость ( объем кода) > Финансы > Производительность. Но не следуйте этому слепо, потому что это зависит от свойств продукта. Как и в любой другой карьере, чем больше опыта вы приобретете, тем больше вы сможете найти правильный баланс для каждой ситуации. Например, при разработке игрового движка главным приоритетом является производительность, а при создании банковского приложения самым важным фактором является безопасность.
  11. Распространение ошибок вызывается копированием и вставкой. Так они размножаются. Всегда проверяйте то, что вы копируете, всегда проверяйте то, что вы импортируете. Баги укрываются в сложности. Magic» нормально работает в моих зависимостях, но не в моем коде.
  12. Не пишите код только для удачного сценария. Записывайте хорошие ошибки, которые могут ответить, почему это произошло, как это было обнаружено и что можно сделать для решения проблемы. Проверяйте весь системный ввод (включая пользовательский).
  13. Не используйте зависимости, если только стоимость импорта, поддержки, работы с их крайними случаями/ошибками и рефакторинга, когда они не отвечают потребностям, не будет значительно меньше, чем стоимость кода, который у вас уже есть.
  14. Держитесь подальше от разработки, вызванной шумихой. Но учитесь всему, чему можете. Всегда имейте домашние проекты.
  15. Выйдите из своей зоны комфорта. Учитесь каждый день. Преподавайте то, чему вы научились. Если вы — учитель, вы не учитесь. Познакомьтесь с другими языками, технологиями, культурой и оставайтесь любознательным.
  16. Хороший код не нуждается в документации, но отличный код хорошо документирован, так что любой, кто не был частью процесса эволюции, проб и ошибок и требований, которые привели к текущему состоянию, может продуктивно работать с ним. Недокументированная функция — это функция, которой не существует. Несуществующая функция не должна иметь кода.
  17. По возможности избегайте перезаписи, наследования и скрытого понимания. Пишите чистые функции. Их легче тестировать и рассуждать о них. Любая функция, которая не является чистой, должна быть классом. Любая конструкция кода, имеющая другую функцию, должна иметь другое имя.
  18. Никогда не начинайте программировать (создавать решение), если вы полностью не понимаете проблему. Вполне нормально тратить больше времени на изучени и чтение, чем на написание кода. Поймите суть дела, прежде чем приступать к кодированию. Проблема похожа на лабиринт. Вы должны постепенно пройти цикл «код-тест-улучшение» и исследовать проблемное пространство, пока не достигнете конца.
  19. Не решайте проблему, которой не существует. Не занимайтесь спекулятивным программированием. Позвольте коду быть масштабируемым только в том случае, если на это есть обоснованное предположение. Есть шанс, что при его масштабируемости определение проблемы будет отличаться от того, когда вы писали код. Не занимайтесь излишней инженерией: сосредоточьтесь на решении поставленной задачи и на эффективном, действенном решении.
  20. Программное обеспечение приносит больше удовольствия, когда оно создается вместе. Создайте устойчивое сообщество. Слушайте. Вдохновляйтесь. Учитесь. Делитесь.

Я не претендую на звание авторитета в области разработки программного обеспечения. Это просто мудрость, которую я приобрел на этом пути. Я уверен, что этот список будет более полным еще через 20 лет.