Глубокий спец vs Фулстек. Я наверное никогда не устану говорить об этой теме, потому что для меня фулстек это нормальное состояние разработчика, в смысле легко достижимое, а не история про то что это обязательно плохой спец во всем. Более того, для меня норма, когда разработчик:

- Может в бек в несколько языков
- Может во фронт
- Умеет и настраивает пайпланый от Docker Compose до Github Actions
- Может сетапить и настраивать облака

(дисклеймер: речь не о том, что таким должен быть каждый, а что это не рокет сайнс все это уметь на хорошем уровне, достаточным чтобы классно делать проекты)

Что обычно имеют ввиду под глубоким спецом? Что человек прямо досканально знает все, быстро дебажит, создает качественный и поддерживаемый код (это ведь подразумевается?).

Знает ли досконально все? Вообще не факт, а скорее всего нет. От того что человек занимается только чем-то одним, не означает что он сидит и как не в себя копает во внутрь по этой теме. Как правило я вижу другую картину, если делать долго и упорно одно и тоже, то в какой-то момент это все делается на автомате, а дальше человек просто останавливается в развитии (соседний фреймворк не считается) ну либо становится тем, о ком я пишу выше.

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

А качественный код? Вот тут вообще никакой корреляции. Да, мы все слышали, что приходят беки и пишут фронт, после которых надо все переписывать, но это не ситуация, которую я рассматриваю. Мы все таки говорим про фулстеков, то есть тех кто целенаправленно учит, а не пишет фронт, потому что попросили, а он не сечет и не планирует учиться писать правильно. Что касается в целом подходов, то люди с более широким кругозором и опытом пишут обычно лучше. Потому что качество кода проявляется не в мелких деталях, что вы например в курсе про более крутой хук. Это все локальные оптимизации. Качество оно про более высокий уровень.

На практике все чуть сложнее. Главный фактор, который вижу я, помимо “я не буду этого делать” - компания и команда в которой работает человек. Где-то это норма, где-то нет и в зависимости от этого и идет рост.

p.s. Больше про разработку я пишу в своем канале Организованное Программирование

Знаете как часто это бывает, когда разработчики говорят что мой код, который я написал полгода назад сейчас выглядит отвратительно. Знакомо? Через это проходят все, кто так или иначе начинает заниматься разработкой и нарабатывает опыт в свои первые годы. Но сколько это может продолжаться?

Я думаю, что если ваши первые годы прошли удачно, то есть вы попали в профессиональную команду с хорошей инженерной культурой, то за 3 года вы выйдете на уровень, когда старый код будет выглядеть нормально для тех задач и тех условий в которых он был написан. Да любой код устаревает это правда, но легаси не означает что код плохой, просто изменились обстоятельства. Этот процесс может занять и больше времени, но если после 5 лет разработки старый код по прежнему выглядит плохо, то здесь явно что-то надо менять в профессиональном плане.

Смотря назад, я понимаю что поворотным моментом в моей карьере стал период, когда я увлекся функциональными языками и курсом СИКП, по которому потом во многом строилось обучение на Хекслете. Произошло это так, я видел что вокруг меня, многие профессионалы, говорят и используют функциональные языки и какие-то связанные с этим подходы. В тот момент речь шла про erlang, scheme/racket (для сикпа), clojure и haskell, которые я в разной степени начал изучать. На эрланге даже получилось сделать проект codebattle.hexlet.io, который потом, спустя много лет переписали на elixir (это опенсорс).

Изучение этих языков многое перевернуло в моей голове и дело даже не в том что они функциональные, а в том, что в среде программистов на этих языках поднимались вопросы, с которыми я раньше не сталкивался. Я понял что смотрел на разработку не на том уровне. Весь мой предыдущий опыт был скорее в стиле вот чистый код, вот мартин, вот фаулер, вот ООП, вот паттерны. Как оказалось, несмотря на здравые мысли в этой части, все же это была оболочка, а не фундамент. А фундамент лежал в таких областях как управление состоянием, изоляция побочных эффектов, конечные автоматы, statefull/stateless части системы и тому подобное.

Во время чтения и решения книги СИКП я реализовал свое ООП, полностью поняв смыслы и как оно работает, в чем соль динамической диспетчеризации особенно множественной, чего не рассказывают в обычных книгах по ООП. Оказалось, что многое о чем пишут в классике (аля книги по java), это лишь поверхностные вещи или особенности работы конкретных языков, а не фундаментальные концепции.

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

p.s. Делюсь опытом программирования в своем телеграм-канале организованное программирование

Функциональное ядро, императивная оболочка

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

Предположим, что мы создаем линтер для проверки исходного кода на соответствие стандартам кодирования. Какие побочные эффекты возможны в случае линтера? В первую очередь это чтение файлов с исходным кодом. Во вторую может быть запись, если линтер умеет автоматически исправлять ошибки. Весь остальной код, по сути, чистый, так как проверка на соответствие правилам не меняет ничего в окружающем мире. И этого кода подавляющее большинство в исходниках линтера. Как бы в таком случае мог работать программный код линтера? Что то в таком духе

const linter = new Linter(/* сюда передаем набор правил */);
const result = linter.lint('список файлов');

Такой код вполне допустим, но он смешивает побочные эффекты с логикой работы. Почему это проблема?

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

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

• Работа с файлами сразу добавляет задачу по работе с файловыми исключениями

Всего этого можно было бы избежать, если бы побочные эффекты были вынесены за пределы ядра:

const linter = new Linter(/* сюда передаем набор правил */);
const filesData = readFiles(); // С учетом исключений и добавлением метаданных
const result = filesData.map((data) => linter.lint(data));

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

Теперь мы можем значительно упростить процесс тестирования, легко добавлять новые способы работы и интегрировать линтер даже в браузер.

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

p.s. Делюсь опытом программирования в своем телеграм-канале организованное программирование

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

На самом деле, большинство пунктов так же применимо и к другим языкам. Большая их часть универсальна, так же проста (js, php или ruby не сильно отличаются на этом уровне) и в целом универсально подходит для всего (php конечно тут выпадает). Реальная же причина популярности кроется в неожиданном аспекте. Питон уже давно основной язык изучения Computer Science в университетах по всему миру. Я не скажу сколько точно это добавляет пунктов, но если посмотреть использование питона в разрезе конкретных направлений, то видно что разрыв резко уменьшается. Та же django, внезапно, проигрывает rails в веб разработке. А это довольно серьезная часть проектов на Python. И даже лидерство в аналитике достигается скорее за счет числа людей, которые с питоном соприкасаются, но надо понимать, что реального программирования там мало и объемы кода в аналитике не идут ни в какое сравнение с веб-разработкой.

В каком-то смысле, питону некисло повезло, что он оказался в таком положении. От этого он не становится хуже, но факт остается фактом, в реальных проектах его меньше чем может показаться на первый взгляд. Пруф.

p.s. Делюсь опытом программирования и предпринимательства в своем телеграм-канале организованное программирование