Мы собираемся поднять этот вопрос на ученом совете. Суровость же наказания за говнокод, будем компенсировать величиной поощрения за код приличный и успехи, лучшие студенты получили ценные призы, денежное поощрение, отличительные знаки и хорошую работу.
JavaScript это язык, на котором очень просто написать плохой код, он почти такой же опасный, как С. Но студенты должны учиться контролировать себя и свой код, пока они у меня учатся, я и мои асистенты будут бить их по рукам вместо компилятора. А после меня они или будут писать приличный код или будут отчислены.
Я имел в виду именно анемичные модели. Что же делать, если язык только ООП поддерживает, но программисту в задаче ООП не нужен. А бизнес-логика предметной области может находиться не в классах, если использовать не ООП. Это же не серебрянная пуля. Вот недавно с медиума статья по ООП:
Автор резок, а мое мнение, что самое здоровое — это мультипарадигменное программирование с элементами процедурного, функционального, реактивного, асинхронного, событийного, декларативного и управляемого данными, объектного, структурного, обобщенного и метапрограммирования.
Согласен, в статье некомпетентно нагоняют на ООП, у меня к ООП совсем другие претензии, в основном связанные с тем, что модель предметной области в информационных системах не может иметь методов, потому, что моделируются не объекты реального мира, а лишь их информационная составляющая, например, vehicle.driveTo(address) имеет смысл только если у нас система, приводящая в действие автомобиль, но если мы работаем только с данными, и не занимаемся автоматизацией железа, то нам нужно job = { vehicle, address }. Тут vehicle и address это только только данные, практически стракты, а вот у logisticsService могут быть методы, в которые передается job, например: logisticsService.execute(job). Грубо говоря, за неимением страктов, в некоторых языках vehicle, address нужно делать классами и объектами. Для этого даже есть название «анемичные классы» и «анемичные объекты», которые не имеют поведения, только данные.
В npm почти нет пакетов с использованием ООП и на TypeScript, а среди распространенных библиотек их вообще нет. Есть так же мнение, что ООП провалилось, http://blogerator.ru/page/oop_why-objects-have-failed Я же думаю, что его просто не умеют правильно использовать. ООП прекрасно подходит для GUI и для обертки объектов операционной системы, как то сокеты, файлы и т.д. Но вот для моделирования предметной области ООП нужно по возможности избегать и использовать структуры данных и функции, к сожалению так нельзя сделать везде, вот в Java придется все писать на ООП, а в ноде лучше писать на мультипарадигменном подходе, применять функционально и реактивное программирование, прототипное наследование, data-driven программирование, событийное и асинхронное программирование, а не лепить объекты куда угодно к месту и не к месту.
Почти ни кто на node.js не используют ООП, а управление зависимостями происходит на уровне модулей. vm.createScript тяжелая, а vm.createContext не очень тяжелая, а в этом случае скорость исполнения вообще не важна, потому, что связывание зависимостей происходит при старте приложения.
DI можно применять не только к ООП, а к классическим модулям. Вот в ноде модули это не классы, а контексты. В контексте зависимость используется не как
context.logger
а как
logger.write('string');
serviceLocator.get('logger')
и
logger.write('string');
отличаются существенно, первый получает ссылку на зависимость, а второй использует зависимость.
Сервис-локатор это когда программный компонент запрашивает у локатора ссылку на другой программного компонент (модуль, класс, интерфейс). А тут все иначе, служебный код (управляющий код, среда запуска или фреймворк) незаметно для управляемого кода (библиотеки, прикладной программы) создает контекст и внедряет в него нужные зависимости. Из контекста теперь зависимости не нужно брать через require (DL).
И тестировать модули нужно группами, они же часто формируют технологические стеки, и что ломается, так это совместимость модуля в стеке, потому, что его автор не формировал стек, а его модуль взяли в стек, о чем он даже не задумывается. И такой стек должен тестироваться целиком (много модулей), перед выкладыванием в репозиторий каждого модуля, в него входящего.
Мои студенты не дадут соврать, я 3 недели назад на лекции в КПИ рассказывал, что NPM имеет много проблем, а 99% модулей — полоный треш, ничего не тестируется на совместимость, и что нам нужен новый менеджер пакетов в ноде с новой стратегией, ибо так не может быть дальше.
Да там вообще много нужно переписать говнокодища, http и cluster никуда не годятся, только с таким подходом, что нельзя ничего трогать и всех изменений по минимуму, проще новый язык сделать уже, не то, что новый рантайм.
Патч развивается, все можно почитать на странице с пул-реквестом: github.com/nodejs/node/pull/2534 Это слишком нежное место ноды, чтобы вот так сразу все включить в релиз. Сейчас решение уже немного другое, чем было при написании статьи, потому, что нужно еще восстанавливать обычный таймаут, если за время keepAliveTimeout восстановится активность в сокете и подобные нюансы. Сейчас уже все в порядке, все тесты проходят, ждем склейки.
Проектов таких у меня несколько, их можно разделить на три группы:
1. Телевизионные интерактивные шоу на принципе второго экрана (уже все готово),
2. Телеметрия технологических процессов и серверных инфраструктур (внедряется и на подходе еще),
3. Финансовая аналитика и корпоративные информационные системы реального времени (в работе).
Если между нодовским ws сервером и браузером ничего не стоит, то это хорошо. А статика отдается из nginx с другого порта, а лучше — с CDN. Если использовать CORS, то все ок. Но я люблю так: без CORS, нода отдает ws + API + HTML, а вот всю остальную статику отдает nginx или CDN. Конечно нода тоже должна уметь отдавать статику, чтобы ее забирал и кешировал CDN, раздавая потом ее с поддомена, например static.domainname.com. Если отдавать ws с того же хоста и порта, что и HTML, то можно обойтись и без CORS.
Для этого случая ни как не влияет. Но тут можно существенно оптимизировать, убрав nginx из цепочки. В такой конфигурации от него нет смысла, кроме двойного использования ресурсов и задержки.
Только косвенно: на сервере обычно параллельно идут HTTP API запросы и WS запросы, чем лучше освобождается память и прикрываются соединения от API запросов, тем лучше для вебсокетов. По сути, запросы, висящие 2 минуты, не отличаются от WS по использовнию ресурсов и когда они быстрее завершаются, это хорошо.
Кстати, таймеры для таймаута сокетов сделаны через enroll/unenroll, которые не приводят к созданию отдельного таймера для каждого сокета. Мне это понравилось, потому, что при 2.5 млн одновременных соединений мне сложно представить, сколько бы CPU уходило на таймеры.
https://medium.com/@cscalfani/goodbye-object-oriented-programming-a59cda4c0e53#.1ox7s5qd2
Автор резок, а мое мнение, что самое здоровое — это мультипарадигменное программирование с элементами процедурного, функционального, реактивного, асинхронного, событийного, декларативного и управляемого данными, объектного, структурного, обобщенного и метапрограммирования.
и отличаются существенно, первый получает ссылку на зависимость, а второй использует зависимость.
А тут пример с декларативным описанием зависимостей модулей: https://github.com/HowProgrammingWorks/InversionOfControl/tree/master/dependencyInjection/ru
Это все только примеры использования, вся реализация уже встроена в ноду, только мало кто знает.
1. Телевизионные интерактивные шоу на принципе второго экрана (уже все готово),
2. Телеметрия технологических процессов и серверных инфраструктур (внедряется и на подходе еще),
3. Финансовая аналитика и корпоративные информационные системы реального времени (в работе).