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

Данная статья является переводом. Оригинал доступен по ссылке.

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

Временами я занимал различные должности: исследователь, технический директор, TPM (менеджер по техническому продукту), преподаватель, системный архитектор и TL (технический руководитель), но при этом я всегда занимался программированием. Я работал и над продуктами, которыми пользовались миллионы людей, и над продуктами, которые провалились до того, как были выпущены. Я консультировал людей и у меня даже был свой стартап. Я потратил много времени на проекты с открытым, закрытым и внутренним (собственный код, разработанный внутри компании) исходным кодом. Я работал с крошечными микроконтроллерами, с мобильными и настольными приложениями для облачных серверов и впоследствии без серверов.

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

1. Используйте с умом различные программные средства

Используйте с умом различные программные средства: библиотеки, языки, платформы и т. д. Используйте как можно больше нативных конструкций. Не искажайте технологию, но и не искажайте проблему. Выберите правильное средство для работы, или вам придется найти правильную работу для средства, которое у вас есть.

2. Вы не пишете код для машин, вы пишете его для своих коллег

Вы не пишете код для машин, вы пишете его для своих коллег, для себя в будущем (если только это не одноразовый проект или вы пишете на ассемблере), а также для джуниоров, не забывайте об этом.

3. Эффективно общайтесь и активно сотрудничайте

Любой значимый и ценный кусочек программного обеспечения является результатом совместной работы. Эффективно общайтесь и активно сотрудничайте. Доверяйте другим и завоевывайте их доверие. Уважайте людей больше, чем код. Подавайте пример. Превратите своих последователей в лидеров.

Больше полезных материалов вы найдете на нашем телеграм-канале «Библиотека программиста» Интересно, перейти к каналу

4. Разделяй и властвуй

Пишите изолированные модули для отдельных слабосвязанных задач. Тестируйте каждую часть и отдельно, и совместно с другими частями. Старайтесь, чтобы тесты были максимально приближены к реальности, но также не забывайте проверять крайние значения.

5. Критикуйте себя

Не стремитесь быть единственным, кто знает код лучше всех. Оптимизируйте его, чтобы люди могли найти способ исправить ошибки и добавить функции в код. Освобождайте себя, чтобы перейти к следующему проекту/компании. Не привязывайте себя к коду, иначе вы никогда не вырастите выше этого уровня.

6. Риск — это деловое решение

Безопасность имеет несколько уровней, каждый уровень необходимо оценивать как отдельно, так и по отношению к целому. Риск — это деловое решение, имеющее прямое отношение к уязвимости и вероятности ее возникновения. У каждого продукта/организации свое отношение к риску, на который они готовы пойти ради получения выгоды. Часто UX, безопасность, производительность конкурируют между собой.

7. Научитесь отпускать

Поймите, что у каждого кода есть жизненный цикл, который заканчивается. Иногда он умирает в младенчестве до запуска. Умейте отпускать такие ситуации. Знайте разницу между 4 категориями функций и умело вкладывайте свое время и энергию:

1. Core: как двигатель в автомобиле. Продукт не имеет смысла без него.
2. Necessary: как запасное колесо автомобиля. Оно редко используется, но в случае необходимости его использование определяет успех системы.
3. Added value: как подстаканник в автомобиле. Хорошо, что он есть, но продукт вполне пригоден для использования без него.
4. Unique Selling Point: основная причина, по которой люди должны покупать ваш продукт, а не товары конкурентов. Например, ваша машина — лучший внедорожник.

8. Люди отделены от вещей, которые они создают

Не привязывайте свою личность к своему коду. Не привязывайте чью-либо личность к их коду. Поймите, что люди отделены от вещей, которые они создают. Не принимайте критику кода на свой счет, но будьте очень осторожны, критикуя чужой код.

9. Отставание от графика

Отставание по графику похож на фаст-фуд. Иногда это приемлемо, но если вы к этому привыкнете, это убьет продукт быстрее, чем вы думаете (и болезненным образом).

10. Приоритеты

При принятии решений при прочих равных следуйте следующему правилу приоритетов: Безопасность → Надежность → Удобство использования (доступность и UX) → Обслуживаемость → Простота (опыт разработчика/DX) → Краткость (длина кода) → Финансы → Производительность. Но не следуйте этому правилу слепо, потому что все зависит от характера продукта. Как и в любой профессии, чем больше опыта вы нарабатываете, тем лучше вы находите баланс для каждой конкретной ситуации. Например, при разработке игрового движка наивысший приоритет имеет производительность, но при создании банковского приложения безопасность является наиболее важным фактором.

11. Копипаста

Все проблемы начинаются с копировать и вставить. Всегда читайте то, что копируете, всегда проверяйте то, что импортируете. Ошибки прячутся в сложности. Например, «магия» хороша в моей зависимости, но не в моем коде.

👶 🌍 10 советов начинающему веб-разработчику

12. Не пишите код только для хорошего развития событий

Напишите ошибки, которые помогут понять, почему они произошли, как они были обнаружены и что можно сделать для их устранения. Проверяйте все входные данные системы (включая ввод пользователя), а также возможность ее восстановления после сбоя. Предположим, что пользователь держит пистолет: приложите достаточно усилий, чтобы убедить его стрелять не в голову, а во что-то другое!

13. Не используйте зависимости

Не используйте зависимости, если только стоимость импорта, обслуживания, устранения их пограничных случаев/ошибок и рефакторинга, когда они не удовлетворяют потребностям, значительно меньше стоимости кода, которым вы владеете.

14. Хайп

Держитесь подальше от hype-driven development. Но учитесь всему, чему можете. Пусть у вас всегда в портфолио будут pet-проекты.

15. Выходите из своей зоны комфорта

Выходите из своей зоны комфорта. Учитесь каждый день. Учите тому, что вы изучаете. Если вы мастер, вы не учитесь. Откройте для себя другие языки, технологии, культуру и оставайтесь любопытными.

16. Документация

Хороший код не нуждается в документации, а отличный код имеет отличную документацию, так что любой, кто не участвовал в развитии проекта, может продуктивно работать с ним. Незадокументированная функция — это несуществующая функция. У несуществующей функции не должно быть кода.

17. Пишите понятные функции

Насколько это возможно, избегайте переопределения, наследования и неявно определенных «хитростей». Пишите понятные функции. Их легче проверить и обосновать. Любая непонятная функция должна быть классом. Любая конструкция кода, имеющая другую функцию, должна иметь другое имя.

✅ 10 советов начинающему инженеру QA

18. Разберитесь в предметной области, прежде чем начинать программировать

Никогда не приступайте к программированию (разработке решения), если вы полностью не понимаете проблему. Вполне нормально тратить больше времени на понимание и чтение документации, чем на ввод кода. Разберитесь в предметной области, прежде чем начинать программировать. Проблема подобна лабиринту. Вам нужно постепенно проходить цикл «код-тест-улучшение» и исследовать проблемные места, пока не дойдете до конца.

19. Не решайте проблему, которой не существует

Не занимайтесь спекулятивным программированием. Делайте код расширяемым только в том случае, если есть уверенность, что он будет расширяться. Скорее всего, к тому времени, когда он будет расширен, определение проблемы будет выглядеть иначе, чем когда вы писали код. Не переусердствуйте: сосредоточьтесь на решении существующей проблемы и грамотном внедрении эффективного решения.

20. Слушайте. Вдохновляйте. Учите. Делитесь

Разработка программного обеспечения приносит больше удовольствия, когда оно создается вместе. Создайте устойчивое сообщество. Слушайте. Вдохновляйте. Учите. Делитесь.

***

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

Материалы по теме

• 👶 🌍 10 советов начинающему веб-разработчику
• ✅ 10 советов начинающему инженеру QA
• 7 советов о том, как лучше учить английский язык