Мы наткнулись на какую-то дурку на StackOverflow, что, мол, сначала ты пишешь код абы как, потом много комментируешь, потом обкладываешься формальными конструкциями, потом ещё что-то, а на вершине профессионального роста — снова абы как. Мы хихикнули, а потом задумались — а как оно на самом деле. И вот что получилось.
Самое начало: лишь бы работало
Когда человек только начинает осваивать кодинг, его главный принцип звучит так: лишь бы работало и запустилось. Из-за этого в ход идёт всё подряд:
- готовые фрагменты кода со StackOverflow;
- примеры из материалов и учебников;
- избыточные и громоздкие конструкции;
- переменные, которые объявляются, но так и не используются.
👉 Код или выглядит предельно просто и «в лоб», или состоит из безумных конструкций и решений, разобраться в которых крайне сложно.
На этом этапе полезно изучать лучшие практики программирования, подключать готовые библиотеки и применять проверенные паттерны и алгоритмы. Так разработчик переходит на следующий этап.
Правильный код
Спустя некоторое время программист набивает руку и начинает писать «правильный код»:
- использовать общепринятое форматирование;
- оставлять самому себе комментарии, чтобы вспомнить, почему тут сделано именно так;
- использовать встроенные возможности языка, а не изобретать, например, свой способ работы с классами или массивами;
- выбирать названия всех переменных, классов и методов в едином стиле, так, как принято в этом языке программирования.
Обычно на этом этапе программисту кажется, что он полностью разобрался в языке и может использовать все его возможности. Но тут он узнаёт про библиотеки и фреймворки.
👉 Код выглядит как образец программирования: идеальные комментарии, всё логично и стройно. Нет ни одного решения, которое бы вызывало вопросы «А почему это сделано именно так».
Библиотеки и фреймворки
Поначалу программисту достаточно встроенных возможностей языка, но со временем он понимает, что часть задач можно решить быстрее и проще с помощью внешних библиотек. И тут начинается:
- поиск самой лучшей библиотеки и фреймворка;
- куски чужого кода в своей программе, скопированные из блога разработчика фреймворка;
- переписывание старых программ под новый фреймворк.
Если увлечься, дело доходит до того, что программист не берётся за решение никакой задачи, пока не найдёт для неё специальный фреймворк. Если это JavaScript-программист, то на этой стадии он может зависнуть на годы или навсегда — новые js-фреймворки выходят каждую неделю.
👉 Код выглядит как код хакера из фильмов: сложные конструкции, понятные только избранным; неочевидные решения, которые продиктованы логикой фреймворка; очень много команд из внешних библиотек.
Совместимость, комьюнити и внешние сервисы
К этому времени у разработчика уже много опыта:
- он умеет решить большинство задач, которые возникают в разработке;
- знает, что и как применить, чтобы получить нужный результат;
- его код работает сразу и почти без ошибок.
Когда программист выходит на такой уровень, он понимает, что личная и самостоятельная разработка — это хорошо, но для серьёзных продуктов нужна поддержка со стороны, совместимость с другими сервисами и умение работать с API. В код добавляются функции для поддержки всех этих возможностей, он разрастается, и разобраться в нём становится очень сложно. Также код обрастает разными манифестами, декларациями, лицензиями, открытой и закрытой частями и поддержкой внешних сервисов.
👉 Разобраться в этом коде сможет только программист с такой же квалификацией. Остальные смотрят, кивают и идут дальше заниматься своими делами. Поддерживать этот код могут 1–2 человека в компании.
15 лет практики: лишь бы работало
Спустя годы непрерывной практики программист понимает, что всё это суета и тлен, а задачи можно решать намного проще. Он настолько в своём познании преисполнился, что ему уже не нужно думать о совместимости, библиотеках или названиях переменных. Всё, что делает программист на этом этапе, — просто пишет рабочий код так, как ему удобно. При этом в его коде можно встретить:
- фрагменты кода из StackOverflow, потому что так быстрее;
- переменные из одной буквы, потому что так проще;
- избыточные команды, потому что так быстрее, а при компиляции компьютер всё равно это оптимизирует;
- один-два комментария на весь код, потому что остальное и так понятно, чего тут ещё объяснять?
👉 Код на этом последнем этапе выглядит почти так же, как код на первом этапе, за одним исключением: в отличие от новичка, этому программисту мир абсолютно понятен. Он здесь ищет только одного — покоя, умиротворения и вот этой гармонии от слияния с бесконечно вечным, от созерцания этого великого фрактального подобия и от вот этого замечательного всеединства существа.
