20 вещей, которые я вынес за 20 лет в программировании

Программист Schibsted Алекс Эвелёф в блоге на Medium рассказал о главных правилах и принципах, которые вывел для себя за многие годы работы в ИТ. Публикуем перевод статьи.

12 комментариев
20 вещей, которые я вынес за 20 лет в программировании

Программист Schibsted Алекс Эвелёф в блоге на Medium рассказал о главных правилах и принципах, которые вывел для себя за многие годы работы в ИТ. Публикуем перевод статьи.

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

Некоторыми из продуктов, в разработке которых я поучаствовал, пользовались миллионы людей, а некоторые были похоронены ещё до релиза. Я работал консультантом и даже пробовал вырастить стартап. Кучу времени посвятил проектам с открытым исходным кодом, с закрытым кодом, inner source-проектам (когда методологии open source-разработки используются в создании проприетарного софта сообществом внутри компании). Доводилось работать с крошечными микроконтроллерами, с мобильными и десктопными приложениями, облачными серверами и бессерверными архитектурами.

Подводя черту под 20 годами программирования, я составил список «золотых правил», к которым постепенно пришёл за это время и которыми руковожусь в работе.

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

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

Горячие события

Конкурс EY Entrepreneur Of The Year 2020
31 мая — 31 мая

Конкурс EY Entrepreneur Of The Year 2020

GoWayFest 4.0
11 июля — 11 июля

GoWayFest 4.0

Минск

Читайте также

Москвичей с коронавирусом хотят контролировать с помощью приложения
Москвичей с коронавирусом хотят контролировать с помощью приложения

Москвичей с коронавирусом хотят контролировать с помощью приложения

Калькулятор белорусов считает вероятных носителей вируса в компаниях
Калькулятор белорусов считает вероятных носителей вируса в компаниях

Калькулятор белорусов считает вероятных носителей вируса в компаниях

3 комментария
Белоруссий стартап – партнёр Google – отдаст весь доход на борьбу с вирусом
Белоруссий стартап – партнёр Google – отдаст весь доход на борьбу с вирусом

Белоруссий стартап – партнёр Google – отдаст весь доход на борьбу с вирусом

2 комментария
Новый сервис помогает сравнивать цены в минских магазинах
Новый сервис помогает сравнивать цены в минских магазинах

Новый сервис помогает сравнивать цены в минских магазинах

12 комментариев

Обсуждение

3

20 вещей, которые я вынес за 20 лет

Звучит как исповедь клептомана

2

ага, думал сча будет пара жестких дисков, пара упаковок чая, корректор, упаковку пластиковых стаканчиков

ret
ret Junior Clojure Developer в Targetprocess
2

я программирую более 20 лет, но каждый год встречаю подобные статьи :)

0

Напишите тогда свою :) может правила будут в чем-то отличаться

0

Вы пишите код не для машин

Поправьте, пожалуйста. Глаз режет.

0

Многое банально. Понравились пункты 1, 12 и 19 .

6

Солнце всходит и заходит

1

емко пересказали содержание статьи

0

Повезло чуваку - он никогда не попадал на проблемы с кириллической "с". :)

2

20 вещей, которые я вынес за 20 лет в программировании

Блокноты, ручки, провода, один раз моник...

0

А я бы не хихикал. Если учесть, что основа всех современных ОС -- Unix появилась более 60 лет назад, то я бы про "заход и восход солнца" промолчал.

За свои 27 лет опыта работы "программистом", могу сказать, что я встречал не много моментов в своей практике, которыми я мог бы сказать - это шаг вперед. Как правило, это "сборка" велосипеда, а не поиск новой конструкции.

0

Да ну что вы. Только почему-то сайты 10 лет назад и сейчас - это две большие разницы. Как же так? Ведь ничего же технологически не изменилось?