Модульный код
Когда меня друзья спрашивают, что такое модульный код, чем он лучше, и почему я так от него кайфую, я показываю эту картинку. На что они говорят, что судя по лицу последнего, преимущество сомнительное :)
Когда меня друзья спрашивают, что такое модульный код, чем он лучше, и почему я так от него кайфую, я показываю эту картинку. На что они говорят, что судя по лицу последнего, преимущество сомнительное :)
Каждая функциональность имеет n модулей, которые как-то увязаны. Красные верёвки - как раз эти "связи", если декомпозировать целостный проект до уровня модулей.
Сам по себе модуль подразумевает высокую связность (сфокусирофанность на решении конкретной задача), чёткие, концептуальные границы и лаконичный интерфейс, который позволяет окружению взаимодействовать с этим модулем. Тогда и код, основанный на использовании модулей, будет чистым, понятным и с внятной иерархией. Так что на доске тоже хуйня какая-то, а не модульный код, потому что там не модули, а просто бессистемные куски кода, только собранные не в одном месте, а распиханные по наборам файлам.
А с чего вы взяли, что код не "чистый, понятный и с внятной иерархией"? Иерархия, кстати, вовне вовсе не обязана быть внятной.
Потому что при чёткой иерархии модули организуются уже в более высокоуровневые сущности (как пример, слои), понять взамосвязи между которыми становится уже проще. Грубо говоря, ты начинаешь анализ системы с таких высокоуровневых слоёв и их взаимосвязей, далее, расковыривая изолированно каждый слой, спускаешься вниз по иерархии. Код на доске более характерен для систем, где нет чёткой иерархии, а есть просто набор кодяры, нарезанный на куски (типа модули) и каждый такой кусок использует и сам является используемым каким годно другим куском. Все эти бессистемные линии во все направления намекают на это.
и каждый такой кусок использует и сам является используемым каким годно другим кускомЯ имел в виду иное - те линии, что вы относите к взаимному использованию, я посчитал собственно функциональностью.
Абсолютно верно. Я так и не въехал в суть этого поста, потому что это какая то хуйня, так никто не делает, за такие модули руки надо откручивать.
Не, не будет там никакого лаконичного интерфейса. Обычно ничто не мешает программисту заиспользовать публичный метод из твоего модуля, насрав на то как там оно должно быть, хотя по факту он публичный только в рамках этого модуля, т.к. язык не дает разграничить доступ на разных уровнях. Микросервис решает эту проблему.
язык не дает разграничить доступ на разных уровнях.
Если какой дурачок полезет работать с модулем в обход, например, фасада этого модуля (читай интерфейс), то и результат получит соответствующий - неработающий код. А получив неработающий код, далее уже придёт к "официальному" способу работы.
Чой-то получит неработающий код. Ему ничто не мешает по отдельности импортировать классы. Или просто отнаследоваться от фасада и расширить его в другом модуле.
Хех, чел ты хоть раз на проде код писал? Просто рассказываешь сказки из страны где единороги блюют радугой, и которые к реальности никакого отношения не имеют. В монолите вообще наследование под запретом быть должно.
Не, это просто опыт, современные парадигмы разработки и язык go. А касательно велосипедов, ты можешь все то же самое делать через композицию, и не будет никакого волшебства, и никакой неявной связности.
Код будет чистым пока не доходит до взаимодействия между компонентами. Потому что в один момент можно охуеть гонять туда-обратно состояния компонентов и запутаться в событиях. Но в любом случае для серьезного проекта это лучше, чем городить всё в одну портянку. Так что поныли немного и дальше будем модули пилить
Модули - да, должны. Однако что мешает "связям" на самом деле быть потоками инфы, передающейся из одного модуля другому в рамках функциональности?
Я не говорил, что модули "связаны". Я говорил, что результат работы одного попадает в другой.
А второй части коммента я не понял. Вернее, слова понятные, но не ясно, что имелось в виду.
Главное чтобы информация между всеми модулями передавалась через глобальный модуль, так архитектура красивее и понятнее. Ну или через пару-тройку глобальных модулей, если всё-таки несколько понадобилось.
А может, не надо использовать переменные a1, a2... a110? Выделять интерфейсы, именовать осмысленно классы, ну весь этот SOLID и KISS?
Тогда код будет читаем и особо даже не будет требовать доументации...
Вот вы не знаете мой код, и делаете такие выводы. Переменные с нормальными именами. Методы тоже. Дело в структуре. Есть один большой класс, и несколько мелких. И этот большой очень быстро разрастается, и я начинаю его бояться. Знал бы, что будет так часть функционала заранее закрыл бы в соседнем, что бы было более логично и структурировано. Пока что ковыряю так, все работает, но когда вдруг понадобится какой нибудь из методов переписать под новый функционал все может сломаться и уже никогда не был исправленым
И этот большой очень быстро разрастается, и я начинаю его бояться
Вот эта фраза мне подсказывает, что в коде не соблюдаются single responsibility и IoC. И, скорее всего, interface segregation тоже потерялся.
Выделите сущности. Опишите интерфейсы. Вкиньте их через DI. И всё станет сильно проще.
У меня есть знакомый, у которого в первом проекте (игра) всё лежало в нескольких классах, в которых было по 5-10к строк. Вот у этого парня, тоже что-то такое похоже)
У меня так было. Понял что так лучше не делать. Но как именно делать понимание ещё до конца не пришло.
Так и есть. Понимание этого приходит уже в процессе, когда многое уже сделано. Но это же и есть опыт. В следующем проекте я буду уже на этапе прототипирования понимать что такие проблемы возможны и надо их предусмотреть, и существуют готовые проверенные решения. Я позволяю себе не считать это чем то плохим. Тем более, что года полтора назад я даже не знал что такое классы и объекты, а сегодня уже вон чего.
Может тогда стоит научиться писать нормально? Код это дело такое, к нему постоянно надо возвращаться. Новые фичи не дремлют.
Конечно стоит. Но это вопрос опыта и практики. А пока работаем с тем что имеем. И ведь работает! Хорошо что я "основатель" и главный кодер на проекте, иначе было бы стыдно
Отладка систем с 4-6 слоями тот еще прикол. Особенно если части нет доступа для дебага, а ошибка в логике.
Тесты спасают, но оставляют самые хардкорные и редкие случаи
Я так понимаю, смысл в том, что на первой картинке описан подход в котором код пишут в одном файле, когда функции отвечающий за разные бизнес логики идут в перемешку в одном файле и строк там - заебешься скролить. Когда функция с 50 строки вызывает функцию из 1050 строки.
А на второй картинке код разбит на модули, которые логически отвечают каждый за свою логику. Но так или иначе при таком подходе нужны зависимости от одного модуля к другому и именно это пытается обьяснить человек с картинки.
Я примерно так же выглядел позавчера пытаясь обьяснить джуну, как устроен store ngrx(angular,ts) в моем проекте и как он используется в компонентах.
Я пьян немного, сильно не хуесосте за сравнения
IT-юмор
5.6K пост52.4K подписчиков
Правила сообщества
Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору