HowProgrammingWorks - JavaScript and Node.js Programming

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

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

👉 Сократить до минимума инструменты.
👉 Сократить интеграции между ними.
👉 Исключить дублирующие способы коммуникации.
👉 Исключить дублирующие инструменты и форматы документов.
👉 Вместо того, чтобы иметь 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 и прочее дерьмо, подумайте, может оно вас больше отвлекает, чем дает что-то. Это вопрос привычки.

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

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

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

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

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

👩‍💻 Полагодив та перезалив деякі відео, посилання та приклади, маємо два плейлісти з курсом для початківців по #JavaScript україномовний та руськомовний
👩‍💻 Починил и перезалил некоторые видео, ссылки и примеры кода, имеем два плейлиста с курсом для начинающих по #JavaScript русскоязычный и украиноязычный

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

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

Некоторые товарищи душнят и придираются к концептуальным примерам кода, поэтому буду показывать вам примеры кода, к которым сложно придраться, это одновременно и то, что я используюю в работе, достаточно концептуальные, интересные по приемам, простые и умещающиеся в слайды, но необычные штуки. Начинаем смотреть с примеров использования, они же тесты. Код тут: https://github.com/metarhia/metasql

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

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

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

— Предлагаете переписать все с нуля?
— Просто переписывание не решит проблему, предлагаю переписать все два раза
— А можно делать это параллельно?
— Нет, только последовательно, первый раз мы поймем в чем проблема, а второй — уже сделаем хорошо

Хорошее запоминание знаний, сигнатур методов, паттернов, алгоритмов, не делает вас автоматически профессионалом. Знания в современном мире под ногами валяются и что... значение знаний сильно преувеличено, а чем же тогда отличаются профессионалы? Только опытом и гибкостью ума, т.е. способностью переносить опыт из одной области в другую, проще в смежную, а чем выше профессионализм, тем более дальние области он может связывать. Например, перенос знаний между языками программирования — просто, между парадигмами — чуть сложнее, а вот брать из механики и электроники в программирование и обратно — это уже существенно сложнее, связывать архитектуру зданий и программ — еще сложнее, но гораздо более плодотворно, а ведь есть общие принципы у мифологии и эстетики, которые хорошо применимы в программной инженерии. Вот как вы отличаете красивый код? Как вы строите свой рассказ о шаблоне проектирования? Вас поймут и поверят только если вы обратитесь к символам и архетипам, человек так устроен, он не понимает явления иначе как через сказку, историю, миф о явлении, пусть даже в форме рационального, инженерного и научного повествования. Например, мы слышим про "блокировки" (locking api) и сразу возникают ассоциации, даже без зная теории, мы уже начинаем как-то думать про "объект" перекрывающий путь к "цели" (ресурсу), а слыша "конкурентность", "параллельность", "асинхронность" мы уже подсознательно начинаем представлять себе это в пространстве, в динамике, прям иллюстрации возникают, думать про это, как про электроны в полупроводниках совершенно непродуктивно, а как про конкретные вызовы api в платформе — слабо переносимо в другие проекты, вот мы и думаем про это единственным универсальным способом — разделяя общее на части, давая названия, создавая классификацию (объединяя в группы) и устанавливая связи между этими именами.

В кодовой базе Метархии теперь будем использовать void для консистентности возврата. Это системный код, в прикладном я не советую использовать void, он непривычен людям, лучше пишите длинный вариант.