🧑‍💻 Миф про разделение учебы, работы и жизни — максимально деструктивная позиция для вас, как профессионала и человека. Например, сначала обучился, а потом работаешь, но работаешь только на работе, а живешь только вне работы. Нет, дорогие мои, так не работает, это рецепт — как плохо учиться, а потом застыть в знаниях и ненавидеть работу, стараясь сбежать из нее в жизнь, и обкрадывать жизнь, вырезая из нее время работы. Я за то, чтобы все это максимально объединить, учишься всегда, работаешь всегда, живешь всегда. Никак не разорвать.

Каким должен быть хороший учебный проект? Для разработчиков информационных систем или data-aware (а это большинство программистов), систем где есть базы данных, пользовательский интерфейс, сервер приложений и взаимодействие по сети, модель предметной области и бизнес-процессы. Сюда прекрасно ложится и веб и энтерпрайз. Так вот, учебный проект лучше начинать не позднее чем через полгода после начала обучения и он должен быть сложный и желательно групповой, делаться несколько лет, постепенно с усложнением, включать не менее половины из: логирование, конфигурация, аутентификация и система прав, отложенные задачи, роутинг запросов, генерация отчетов, миграции, юнит-тесты, интеграционные и системные тесты, автоматическая сборка, телеметрия и сбор статистики, потоковое вещание, очереди, балансировка или оркестрация, интеграция с другими системами, интернационализация, резервное копирование и восстановление, распределенное хранение и обработка данных, коллаборативное редактирование, парсинг, система плагинов, многопоточность или асинхронность, многоуровневое кэширование, сессии, несколько разнотипных СУБД (например postgresql и redis), кодогенерация, обработка метаданных и метапрограммирование, многослойность, изоляция (запросов, пользователей, модулей и т.д.), межпроцессное взаимодействие и удаленный вызов процедур, транзакции и блокировки, рассылка почты и прочих нотификаций.

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

— Учишься в ВУЗе на программиста? На какой специальности?
— Я специалист в области обхода двумерных матриц, сортировки массива пузырьком, могу выводить на экран коэффициентов многочлена любым способом: через std::cout, при помощи модуля crt, и даже через alert(), отлично знаю типы всех моих переменных

Я сторонник того, чтобы давать людям на собесах возможность листать доки, гуглить и даже спрашивать у нейронок. Что должен проверять собес? Эффективность, способность решать задачи, а не задротство, зубрежку и феноменальную память. Если вы начнете это делать, то внезапно для себя выявите, что даже при этом многие люди не справляются, полный интернет шедевров говнокода, оверинженеринга и архитектурного маразма. Еще мне важно, чтобы человек показал свое субъективное мнение, даже эмоциональную позицию по отношению к конкретным решениям и технологиям, именно это он будет проявлять в работе. А что сейчас на собесах происходит: эффект ивентлупа — люди вызубрили и могут наизусть рассказать фазы и красиво объяснить, а применить для принятия решений в коде не смогут, т.е. оно ничего не дает им в каждодневной работе.

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

🧑‍💻 Прикладной программист пишет продуктовый код, занимается моделированием предметной области и автоматизацией процессов в ней. Прикладному программисту нужно знать node.js как инструмент, его возможности, концепции, преимущества и недостатки, но не нужно глубоко погружаться в код платформы, не нужно строить прослойку между node.js и прикладным кодом, не нужно изобретать фреймворки (внутри продукта), изобретать обобщенные инструменты и библиотеки, не имеющие отношение к предметной области. Если это происходит, то он выполняет две роли - системную и прикладную, они должны быть максимально отделены: отдельные репозитории, отдельное рабочее время и должность, отдельные цели и задачи. Чтобы писать системные вещи смотри вопросы в следующем разделе.

👨‍🔧 Системный (платформенный) программист пишет код, не связанный с предметной областью: фреймворки, сетевые протоколы, транслятор, компиляторы, интерпретаторы, библиотеки, занимается вещами, которые могут быть переиспользованы в сотнях и тысячах разных проектов. Это называется производство средств производства. Систем программисту нужно знать node.js гораздо глубже, не только, его возможности, концепции, преимущества и недостатки, но и недокументированные возможности и даже баги, особенности платформы, которые очень редко используются, потому, что он строит прослойку между node.js и прикладным кодом, а прослойка эта позволяет делать прикладной код более абстрактным и приближенным к предметной области.

✨ К вопросам на собес по 🐢 #NodeJS 🚀 добавил еще 30 и их уже 100 там ✨ https://github.com/tshemsedinov/NodeJS-Interview-Questions

⭐️ Нода стала невыносимо сложной ☠️ вот что я понял, пока писал все эти вопросы для собеседований. Основная задача фреймворков - это снятие сложности. Так вот они не справляются с этим вообще. Если человек пишет на фреймворке, то он находится под давлением сложности NodeJS, сложности JavaScript, асинхронного программирования + еще сложность фреймворка + сложность предметной области. Это совершенно невыносимо, друзья. В тех компаниях, где я CTO, архитектор или эдвайзор, я пытаюсь распределить эту сложность хотя бы по разным людям, поэтому разделил роли прикладного (продуктового) и системного (платформенного) программиста, но этого мало. У них ве равно есть достаточно большое перекрытие сфер компетенции, да и сами компетенции, даже разделенные пополам, уже переросли когнитивные способности среднего программиста. Вы заметили, что во всех проектах появляется прослойка между нодой и доменом? Сначала оно легковесное, а за год оно становится совершенно неподъемным, а будучи смешанным с продуктом это просто смерть для компании. Можно делить платформу и продукт на разные репы, можно делить команды, роли, рабочее время разделять, но если не внедрена культура открытого и свободного программного обеспечения, то сложность захлестывает. Вот берите этот свой платформенный код, свои библиотеки и фреймворки и выкладывайте их в Open source, они все равно не являются конкурентным преимуществом бизнеса. Так нет же, вы ссыте, и не хотите заниматься их поддержкой, постоянным обновлением, багфиксами, тайпингами, тестами, доками, комьюнити, не хотите, чтобы кто-то пришел и обругал весь ваш платформенный код за то, что он ужасен, не хотите открытого сравнения с другими библиотеками и фреймворками. Это что касается бекенда на Nodejs. Кто там занимается фронтом, скажите, что там у вас со сложностью, что с культурой?

⛔️ Как жить то?

👉 Сократить до минимума инструменты.
👉 Сократить интеграции между ними.
👉 Исключить дублирующие способы коммуникации.
👉 Исключить дублирующие инструменты и форматы документов.
👉 Вместо того, чтобы иметь 10-15 инструментов, можно иметь 3-4.

1️⃣ Современные Github и Gitlab умеют: тасктрекинг, багтрекинг, планирование проектов и времени, майлстоуны и канбан, база знаний проекта в виде discussions и wiki, все это органично связано, для всего можно делать шаблоны, так, что заведение issue может превратиться в заполнение формы, а отправка в запуск автоматизированного процесса трекинга задачи или бага вплоть до лендинга pull/merge реквестов, с использованием специальных тегов и ключевых слов в коммитах, ведение чеклистов для каждой операции, скриптов, запускаемых на машинах разработчиков и на CI, которые выполняют все, что менеджеры каменного века руками калапацали.

2️⃣ Мессенджер — это личный инструмент, вообще не подходит для продуктов и компаний. Мессенджеры — это место, где навсегда теряются знания, идеи, договоренности, потому, что лежат в виде соплей, размазанных по тредам, очень плохо перелинковываются и их неудобно включать в автоматизированные процессы, это место полнотекстового поиска, это превращает внутренние процессы компании в аналог слабосвязанного интернета, где нужен поисковик, вы наталкиваетесь на битые ссылки, что-то удалено, к чему-то залито в виде запароленного зипа в файловое хранилище, которое Вася перенес в облако и перегруппировал папки, а теперь у всех сообщений до прошлого года картинки не отображаются.

3️⃣ Надеюсь, все понимают принцип "инфраструктура как код", но проектная документация и все вспомогательные файлы (PNG, YAML, блок-схемы в JSON или XML и что угодно) тоже должны стать частью кодовой базы. Всевышний Аллах, безмерной милостью своей дал нам git и MD-файлы (markdown), которые могу автоматически форматироваться, собираться из частей, автоматически генерироваться и компилироваться в PDF и другие форматы. Более того, документация может автоматически публиковаться в HTML формате и выкатываться в виде удобного Web интерфейса, но за всем этим должен стоять единый источник правды - git репозиторий.

⚠️ Если у вас на проектах есть инструментарий подобный Jira, Slack, Trello, Confluence, Microsoft Teams и прочее дерьмо, подумайте, может оно вас больше отвлекает, чем дает что-то. Это вопрос привычки.

Такими темпами JavaScript начнут преподавать в синагоге

На MDN есть статья, как писать на Node.js без фреймворков, с примерами кода из моего бесплатного курса. Но сейчас мы пошли еще дальше, как писать так, чтобы переезд с фреймворка на фреймворк занимал максимум пару часов. https://developer.mozilla.org/en-US/docs/Learn/Server-side/Node_server_without_framework

Решение задачек про велосипедиста при помощи релятивистской механики — это как везде пихать ООП, а при помощи квантовой механики — это как пихать ФП. Люди, очнитесь, пишите простой процедурный код, зачем вам это чувство превосходства над массами?