Модульный код

Когда меня друзья спрашивают, что такое модульный код, чем он лучше, и почему я так от него кайфую, я показываю эту картинку. На что они говорят, что судя по лицу последнего, преимущество сомнительное :)

Модульный код Программирование, Программист, Код, IT, IT юмор, Айтишники

IT-юмор

5.6K пост52.4K подписчиков

Добавить пост

Правила сообщества

Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору

Вы смотрите срез комментариев. Показать все
63
Автор поста оценил этот комментарий
Как программист программисту скажи:
Как связана лапша на доске с модульностью?
Причём тут сисадмин в тегах?
раскрыть ветку (40)
36
Автор поста оценил этот комментарий

Каждая функциональность имеет n модулей, которые как-то увязаны. Красные верёвки - как раз эти "связи", если декомпозировать целостный проект до уровня модулей.

раскрыть ветку (20)
26
DELETED
Автор поста оценил этот комментарий

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

раскрыть ветку (13)
14
Автор поста оценил этот комментарий

А с чего вы взяли, что код не "чистый, понятный и с внятной иерархией"? Иерархия, кстати, вовне вовсе не обязана быть внятной.

раскрыть ветку (2)
8
DELETED
Автор поста оценил этот комментарий

Потому что при чёткой иерархии модули организуются уже в более высокоуровневые сущности (как пример, слои), понять взамосвязи между которыми становится уже проще. Грубо говоря, ты начинаешь анализ системы с таких высокоуровневых слоёв и их взаимосвязей, далее, расковыривая изолированно каждый слой, спускаешься вниз по иерархии. Код на доске более характерен для систем, где нет чёткой иерархии, а есть просто набор кодяры, нарезанный на куски (типа модули) и каждый такой кусок использует и сам является используемым каким годно другим куском. Все эти бессистемные линии во все направления намекают на это.

раскрыть ветку (1)
Автор поста оценил этот комментарий

и каждый такой кусок использует и сам является используемым каким годно другим куском
Я имел в виду иное - те линии, что вы относите к взаимному использованию, я посчитал собственно функциональностью.

1
Автор поста оценил этот комментарий

Абсолютно верно. Я так и не въехал в суть этого поста, потому что это какая то хуйня, так никто не делает, за такие модули руки надо откручивать.

Автор поста оценил этот комментарий

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

раскрыть ветку (7)
DELETED
Автор поста оценил этот комментарий
язык не дает разграничить доступ на разных уровнях.

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

раскрыть ветку (6)
Автор поста оценил этот комментарий

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

раскрыть ветку (5)
1
Автор поста оценил этот комментарий
Расширение фасада никак не должно нарушать общий контракт модуля, в соответствии с принципом Лисков.
раскрыть ветку (4)
Автор поста оценил этот комментарий

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

раскрыть ветку (3)
1
Автор поста оценил этот комментарий
Чел, я только на проде и пишу. Запрещать наследование смишно, да.. Это сказки из страны любителей изобретать велосипеды, я полагаю?
раскрыть ветку (2)
Автор поста оценил этот комментарий

Не, это просто опыт, современные парадигмы разработки и язык go. А касательно велосипедов, ты можешь все то же самое делать через композицию, и не будет никакого волшебства, и никакой неявной связности.

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

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

1
Автор поста оценил этот комментарий
Звучит разумно. Но такие «связи» намекают на монолитность системы. Мне казалось - модули должны быть инкапсулированы, возможно стоит использовать отдельный менеджер для связи.
В любом случае, картинка - не лучшая.
раскрыть ветку (5)
Автор поста оценил этот комментарий

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

раскрыть ветку (4)
Автор поста оценил этот комментарий
Действительно интересный вопрос. Пока модуль напрямую зависит от другого модуля - они связаны.
Типизируем мы формат данных или интерфейсы - мы обозначаем их зависимость.
раскрыть ветку (3)
Автор поста оценил этот комментарий

Я не говорил, что модули "связаны". Я говорил, что результат работы одного попадает в другой.

А второй части коммента я не понял. Вернее, слова понятные, но не ясно, что имелось в виду.

раскрыть ветку (2)
Автор поста оценил этот комментарий

Главное чтобы информация между всеми модулями передавалась через глобальный модуль, так архитектура красивее и понятнее. Ну или через пару-тройку глобальных модулей, если всё-таки несколько понадобилось.

раскрыть ветку (1)
Автор поста оценил этот комментарий

Ну, да, вы верно конкретизировали.

3
Автор поста оценил этот комментарий

Без диздока это выглядит именно так.

раскрыть ветку (13)
3
Автор поста оценил этот комментарий

Код должен быть читабельным и без диздока

раскрыть ветку (12)
7
Автор поста оценил этот комментарий

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

раскрыть ветку (9)
3
Автор поста оценил этот комментарий

А может, не надо использовать переменные a1, a2... a110? Выделять интерфейсы, именовать осмысленно классы, ну весь этот SOLID и KISS?

Тогда код будет читаем и особо даже не будет требовать доументации...

раскрыть ветку (5)
2
Автор поста оценил этот комментарий

Вот вы не знаете мой код, и делаете такие выводы. Переменные с нормальными именами. Методы тоже. Дело в структуре. Есть один большой класс, и несколько мелких. И этот большой очень быстро разрастается, и я начинаю его бояться. Знал бы, что будет так часть функционала заранее закрыл бы в соседнем, что бы было более логично и структурировано. Пока что ковыряю так, все работает, но когда вдруг понадобится какой нибудь из методов переписать под новый функционал все может сломаться и уже никогда не был исправленым

раскрыть ветку (4)
Автор поста оценил этот комментарий
И этот большой очень быстро разрастается, и я начинаю его бояться

Вот эта фраза мне подсказывает, что в коде не соблюдаются single responsibility и IoC. И, скорее всего, interface segregation тоже потерялся.

Выделите сущности. Опишите интерфейсы. Вкиньте их через DI. И всё станет сильно проще.

раскрыть ветку (3)
1
Автор поста оценил этот комментарий

У меня есть знакомый, у которого в первом проекте (игра) всё лежало в нескольких классах, в которых было по 5-10к строк. Вот у этого парня, тоже что-то такое похоже)

раскрыть ветку (1)
Автор поста оценил этот комментарий

У меня так было. Понял что так лучше не делать. Но как именно делать понимание ещё до конца не пришло.

Автор поста оценил этот комментарий

Так и есть. Понимание этого приходит уже в процессе, когда многое уже сделано. Но это же и есть опыт. В следующем проекте я буду уже на этапе прототипирования понимать что такие проблемы возможны и надо их предусмотреть, и существуют готовые проверенные решения. Я позволяю себе не считать это чем то плохим. Тем более, что года полтора назад я даже не знал что такое классы и объекты, а сегодня уже вон чего.

7
Автор поста оценил этот комментарий

Может тогда стоит научиться писать нормально? Код это дело такое, к нему постоянно надо возвращаться. Новые фичи не дремлют.

раскрыть ветку (2)
1
Автор поста оценил этот комментарий

Конечно стоит. Но это вопрос опыта и практики. А пока работаем с тем что имеем. И ведь работает! Хорошо что я "основатель" и главный кодер на проекте, иначе было бы стыдно

раскрыть ветку (1)
Автор поста оценил этот комментарий
А можно поинтересоваться что из себя представляет проект или хотя бы на каком/каких языках?
/* спросил человек, который основатель и главный кодер проекта на access VBA 🙃 */
3
Автор поста оценил этот комментарий

Код. НЕ. Должен. Вобще ничего и никому не должен.

Автор поста оценил этот комментарий

Не все пишут очередную энтерпрайзную хрень.

2
Автор поста оценил этот комментарий

Отладка систем с 4-6 слоями тот еще прикол. Особенно если части нет доступа для дебага, а ошибка в логике.


Тесты спасают, но оставляют самые хардкорные и редкие случаи

3
Автор поста оценил этот комментарий
А с чего ты взял, что тс программер?
5
DELETED
Автор поста оценил этот комментарий

Сисадмин охуевает потом просто над этим над всем, возводя очи горе и вопрошая небеса: СУКА, ГДЕ МОИ ИОПСЫ

2
Автор поста оценил этот комментарий

Я так понимаю, смысл в том, что на первой картинке описан подход в котором код пишут в одном файле, когда функции отвечающий за разные бизнес логики идут в перемешку в одном файле и строк там - заебешься скролить. Когда функция с 50 строки вызывает функцию из 1050 строки.


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

Я примерно так же выглядел позавчера пытаясь обьяснить джуну, как устроен store ngrx(angular,ts) в моем проекте и как он используется в компонентах.

Я пьян немного, сильно не хуесосте за сравнения

раскрыть ветку (1)
Автор поста оценил этот комментарий
Все именно так
Вы смотрите срез комментариев. Чтобы написать комментарий, перейдите к общему списку