Стараюсь отделять бизнес логику от решений, стараюсь делать модули (методы) более независимыми, каждый метод мал и выполняет маленькую задачу, только ту ради которой он создан.
В общем вопрос в чем, какие Вы используете подходы, как выбираете, что учитываете, какие правила используете при создании/поддержке и самое главное есть ли у Вас тулзы помогающие решать такие задачи (в своей работе использую только сборщики и препроцессоры через Grunt)? Может быть есть какие-то новые подходы помогающие решать задачи? В общем любой совет, которым Вы руководствуетесь при работе.
Спасибо!
Объемный вопрос.
Я не планирую архитектуру в виде конечного результата. Она скорее вырисовывается сама, как результат обоснованных (стремлюсь обосновать (не путать с объяснить) себе каждое решение). Эволюция. Инструмент не должен мешать эволюционировать архитектуре.
Пока можно обойтись без функций, пишу все одним текстом (например command line утилиты)
Проверку тестов пишу прямо assert-aми с самом коде модуля, надо больше тестов - подключаю тестовый фреймверк.
Конфигурации мало - держу ее в самом файле. Как только начинает конфигурация надобится в нескольких местах, выношу ее в модуль.
Пока можно обойтись функциям (действия), оставляю их, как только появляются сущности (объекты, выполняющие действия) ввожу понятие классов.
Требования к архитектуре:
изолировать модули (в js для этого приходится прилагать дополнительные усилия), в том числе html, css
слабая связанность (редактирование одного модуля не должно влиять на другие неожиданным образом),
низкая запутанность (чем меньше я явнее связи, тем лучше), проще понимать код. Например единая точка входа для получения данных.
масштабирование (чаще всего заключается в разбиении уже существующих модулей на подмодули)