Как спроектировать JavaScript приложение?

Question

[Иван Антонов]

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

Answer 1

[Сергей Протько]

Для начала разберитесь с принципами объектно-ориентированного и функционального программирования. Штуки вроде "почему высокая связанность кода это плохо, зачем нужны MVC и т.д."

Паралельно можете поразбираться с типичными шаблонами проектирования под js: largescalejs.ru

Ну и еще - ES2015, активное использование модулей и штук вроде jspm/webpack для сборки. По сути все проблемы в js - кривое управление зависимостями (вся соль ООП в принципе состоит в инверсии зависимостей, функциональные подходы делают все еще лучше). Сейчас ситуация с этим всем намного лучше чем была скажем еще года 4 назад.

Опять же, когда речь идет о реально больших проектах, следует перестать писать на каждый чих свой велосипед. Нужна библиотека для организации маршрутизации - берем готовую. Нужно работать с датами - берем moment.js и т.д. Сборщики вроде того же jspm умеют выдерать из популярных библиотек то что можно (если можно так сделать, скажем с angular2 выдрать только нужные модули можно. а вот с angular1 нет).

Comments

[Сергей Протько]

Макс Минимус: например программируя на Си мы загоняем себя в рамки процедурного программирования.

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

Да и в целом, не использовать ООП в js не выйдет, так как там все есть объект и так или иначе у вас будет взаимодействие объектов.

Если нормально зачетно грызть гранит науки то может быть и чужих фоеймворков не захочется

А если к этому добавить толику здравого смысла, то придет еще и осознание того, что один человек не в состоянии сделать что-то лучше и качественнее чем целое комьюнити, и что у одного человека (или даже команды) не хватит ресурсов что бы свое детище поддерживать без поддержки опенсурс комьюнити.

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

[Сергей Протько]

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

[Сергей Протько]

Макс Минимус: я не понимаю одного, в контексте вопроса небыло ровным счетом ничего о студентах.

Студенты и школьники должны снова и снова имплементить известные алгоритмы что бы разбираться в их сути, да они должны написать хотя бы пару велосипедов. Но, это только для себя. Потом все эти велосипеды надо сжечь и использовать готовое. А использовать самопис в коммерческой разработке (на себя или кого-то другого) - это в итоге выльется в большие расходы на поддержку.

Все программисты умеют писать сами и все программисты могут использовать свой код. Другое дело что далеко не все понимают когда нужно одно а когда другое. И еще большая проблема - отсутствие культуры разработки.

[Иван Антонов]

Макс Минимус: > Другие програмисты не умеют писать сами но умеют использовать готовое.
По-моему с развитием наших технологий скоро кодеры как таковые не нужны будут. И останутся в перспективе только программисты которые "умеют использовать готовое".

[Сергей Протько]

Макс Минимус: да и ковыряние в популярных решениях на определенном этапе будет давать намного больше опыта чем написание своих велосипедов.

[Сергей Протько]

Иван Антонов: мне всегда казалось что кодеры это и есть люди которые используют готовое... ну или реализуют то что на UML описал архитектор (что уже давно вымирает).

И не вымрут они. Джуниоры нужны всегда.

[Иван Антонов]

Сергей Протько: Кстати у меня была тема по UML мне ничего толковое так и не посоветовали.
> мне всегда казалось что кодеры это и есть люди которые используют готовое
с каждым годом появляются новые технологии позволяющее меньше писать код, поэтому у меня сомнения по поводу долгого существования слова - "кодер"

[Сергей Протько]

Иван Антонов: UML не нужен, все это дело заменили BDD-шные сценарии с примерами поведения, сторимэппинги и т.д. Модель теперь проектируется как можно ближе к языку предметной области, единственное что осталось - введение акторов разве что и юз кейсы.

[Иван Антонов]

Сергей Протько: что за BDD и сторимэппинги?

[Сергей Протько]

Иван Антонов: BDD - Behaviour Driven Design, движение которое основала горстка любителей аджайлов дабы невилировать стоимость перевода при обсуждении функционала в рамках команды (между клиентом, продукт оунером, менеджерами, бизнес аналитиками и разработчиками). Делают они это за счет составления спецификаций - то же моделирование что и с UML, только UML не так понятно для стэкхолдеров обычно, а спеки они почитать могут. Спеки состоят из примеров, типа "у нас есть что-то, я с ним делают еще что-то и выходит то что мы хотим". За счет дополнительных примеров мы можем получить нужный уровень деталезации функционала.

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

Answer 2

[Дмитрий Ковальский]

Писать хрень на любом языке одинаково просто. Поищите на тостере по словам "архитектура javascript". Ну или в поисковиках , добавив слово "приложений"