Что представляет из себя правильная декомпозиция javascript кода?
Вечер добрый!
Столкнулся с темой unit-тестирования и понял, что мой код не так хорош, каким должен быть. Зависимости, много кода в одном компоненте/классе, не все методы построены в функциональном стиле(input/output) — все это дало мне понять, что нужно переписывать свой код и выпрямлять руки.
Но встает вопрос: что нужно выносить в отдельные модули, а что нет? Если с view компонентами все давно ясно, то вот как разбивать логику - не до конца. Взять в пример класс/компонент: какие методы оставить внутри, а какие вынести в отдельные модули, чтобы внутри этого класса/компонента уже импортировать нужные модули и использовать внутри? Надеюсь на искренний ответ и на советы, которые помогут при написании разбитого тестируемого кода. Спасибо!
Выучите наизусть принципы SOLID. Серьёзно. Юнит тесты пойдут как по маслу. Еще разузнайте поподробнее про separation of concerns - это тоже про разбивку на модули. В общем-то если принимать решения руководствуясь правилами SOLID и постоянно думать о separation of concerns, то дела пойдут на поправку. Только не ждите скорого озарения, пожалуйста. Придётся целенаправленно попрактиковать это годик-другой. Сужу по личному опыту, но признаюсь честно, я слегка туповат. Может у вас есть шанс осилить это дело быстрее.
Еще можно ознакомиться с тем что такое temporal coupling. Да и вообще coupling. Это про то как делать не нужно.
Еще можно наизусть выучить мантру "low in coupling and high in cohesion".
Еще можно попробовать сначала писать тесты, а потом код. Но так могут делать только те, кто способен превозмогать боль в течении долгого времени. Зато потом по-другому уже и не хочется. Да и не получается.
UPD
Забыл сказать, попробуйте писать такой код, который не стыдно выложить в npm. Если у вас получилось написать модуль, который можно подключить к любому проекту через npm, то это хороший признак того что модуль был написан по всем правилам. Да и вобще open source сильно помогает в прокачке "модульного мышления".
