Тимур Шемсединов

Лучше всего написать что-то сложное и страшное и выложить в открытом коде, такое, чтобы от задачи дух захватывало, или присоединиться к уже существующуму проекту в открытом коде, даже если из этого ничего не выйдет, то Вы поймете ноду изнутри. Посмотрите мою лекцию и другие видео в списке, надеюсь, они помогут https://www.youtube.com/watch?v=Try7lmWikao&index=...

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

Полезно поднять старых авторов, потому, что все уже было в веках, например, "Заметки по структурному программированию" Дейкстра и "Алгоритмы + структуры данных = программы" Вирта. Послушать лекции таких людей, как Александр Степанова:
"Преобразования и их орбиты"
Часть 1 https://youtu.be/QmuMHtbO4ug и Часть 2 https://youtu.be/uCGifwlgAQg
"Наибольшая общая мера последние 2500 лет"
Часть 1 https://youtu.be/Dx1MZh6KYCk и Часть 2 https://youtu.be/zqETgaYxlt0

Полезно приступить к новой сложно задаче, принципиально другой. Вот Вы занимались веб-сервисами, а возьмите проект, в котором это не подходит, где нужна связь, основанная на UDP протоколе или RPC, и с поддержкой состояния (STATEful) соединения между клиентом и сервером через шину событий или различные конструкции паттернов комуникации, см. ZeroMQ zguide.zeromq.org/page:all Если занимались корпоративными системами, то возьмите промышленную автоматизацию, она разрушит Вашу уверенность в железобетонных подходах. Если занимались вебом, то возьмите распределенные вычисления или системное программирование.

Перейти к новым парадигмам, например к функциональному программированию, реактивному, манадам и т.д. Если привыкли делать все по накатанной, то можно перейти от программирования к метапрограммированию и придется все переосмыслить. Тут мои статейки по этому поводу: habrahabr.ru/post/137446 и habrahabr.ru/post/227753

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

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

Передача хендлов сокетов в дочерние процессы тут находится во встроенной библиотеке cluster и скрыта от разработчика. Так же все процессы пишут и читают из редиса (см в коде вызовы incr/decr, zrem/zadd). Процессы подписываются на редисовские каналы (см в коде conn.on('message'...) и conn.on('subscribe'...) ). Код в этом репозитории уже три года не изменялся, масштабирование только на несколько процессов на одной машине, ничего уникального не написано, весь этот функционал сидит в редисе, будет тратиться много ресурсов, чтобы обеспечить межпроцессовое взаимодействие ноды с ним, даже не интересно смотреть эту реализацию. Это устаревший хлам, за три года нода уже изменилась, а как изменилась инфраструктура и возможности дополнительных пакетов...

Идея/концепция к проектированию не относится, это отдельный предварительный этап. Для проектов побольше, и в общем случае, проектирование включает такие шаги, многие из которых, конечно, можно пропустить или сократить до минимума, если задача не сложная:
1. Системный анализ и изучение предметной области
2. Формирование требований к разрабатываемой системе
3. Архитектуная задача, которая сводится к простой формуле: разделять, называть и связывать подсистемы
3.1. Декомпозиция сложных задач
3.2. Слои (построение слоев абстракций)
3.3. Планирование топологии системы, программной и серверной инфраструктур
3.4. Решение вопроса интеграции подсистем, программные интерфейсы, контракты и связывание
3.5. Интеграция с унаследованными приложениями
3.6. Минимизация изменений, для случаев, когда постоянно происходят изменения в предметной области
4. Выбор инструментов решения
4.1. Выбор парадигм программирования и языков
4.2. Выбор технологий и платформ
4.3. Выбор моделей данных, алгоритмов и библиотек
4.4. Выбор топологий и протоколов
4.5. Выбор паттернов программирования
5. Предварительные исследования
5.1. Проверка гипотез, эксперименты
5.2. Изучение особенностей технологий
5.3. Прототипирование
6. Задачи обеспечения надежности
6.1. Планирование безопасности и защиты от несанкционированного доступа
6.2. Планирование отказоустойчивости
6.3. Планирование мер по обслуживанию системы в режиме эксплуатации
6.4. Задачи высоких нагрузок, балансировки и масштабирования, если таковые предполагаются
7. Организация процесса разработки
7.1. Жизненный цикл программной системы
7.2. Конвенции кода, соглашения и стандарты
7.3. Оценка необходимых временных и финансовых ресурсов для разработки системы
7.4. Календарный план
7.5. Анализ и минимизация рисков, выявление слабых мест технологий и коллектива
7.6. Закрепление принципов управления процессом разработки и корректировки задания в процессе
8. Сборка технического задания из результатов всех предыдущих пунктов

Почитайте этот вопрос и ответы на него: Как сделать возможность изменения кода приложений без перезагрузки основного приложения nodejs? Перегружать отдельные части приложения, даже если они не оформлены в модули при изменении их на винте можно при помощи fs.watch и require, предварительно удаляя их из кеша через delete require.cache[require.resolve('file-name')];
И у Вас очень опасная мысль развивается, отождествление модуля с контроллерами и моделями. Модуль не имеет ни какого касания к MVC, какие контроллеры, какие модели? Чтобы ощутить свю абсурдность этого подумайте про встроенные модули fs, http, stream и т.д. они контроллеры или модели? А внешние модули async, colors, request они контроллеры или модели? Почитайте habrahabr.ru/post/117791 и еще habrahabr.ru/post/204958

Вот тут подробно расписываю как для API распространено применение не подходящих паттернов habrahabr.ru/post/204958 и как нужно делать.

Какое крутое признание, это действительно уникально что Вы понимаете, что в этом что-то не так. Большинство разработчиков что не сделают, все контроллером зовут. Я думаю, что нужно больше читать и развивать словарный запас, кругозор и сознание, даже не обязательно англоязычную литературу, научно-техническая лексика по большей части интернациональна. Читать можно конечно и статьи в научно-популярных журналах и художественную литературу, но мне ближе и я советую ученых, программистов и философов: Дональд Кнут, Гради Буч, Декарт, Кант, Марк Аврелий, Лао Цзы, Спиноза, Паскаль, Платон, Аристотель, Мамардашвили, Пятигорский, Шантидева, Рассел, Хомский, Норберт Винер, Глушков, Канторович, Лебедев, фон Берталанфи, Уильям Эшби, Дейкстра, извините, если кого не вспомнил, кто вот первый вдруг на ум пришел.