Pull to refresh

Comments 19

Почему-то ожидал большего.
Например, случаи, когда модульность полезна, а когда вредна. Примеры кода… Хотя… сперва добейся
Я не хотел конкретизировать тему. Мне кажется я раскрыл ее достаточно, чтобы заставить читателя подумать — насколько модульным должна быть ЕГО программа.

Примеры кода? Хорошая модульность обычно в Python и Java. Плохая очень часто встречается в PHP и Javascript.
Хватит уже дёргать PHP, а?
Быдлокодеры есть везде, просто PHP популярен, и в абсолютных числах, наших быдлокодеров много =)

А по поводу JS, посмотрите на extJS.
Там такой уровень абстракции, что питонистам и не снился.
Про ExtJS согласен.

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

В общем я просто проконстатировал факты в предыдущем комменте :)
Здравствуйте, КО!

Неужели вы думаете, что подобные вещи можно рассказывать на одном примере? Умение писать код с низкой связанностью и хорошо разбитый на «модули» приходит только с опытом.

Кстати, пример — плохой. Не надо делать вид, что работа с удаленным сервером настолько же проста, как и с локальной файловой системой. В реальном приложении может потребоваться нарисовать для юзера ProgressBar, придумать как реагировать на потерю соединения и т.п.
Если рассказывать не на одном примере и полностью раскрывать тему, вытаскивая все подводные камни — получится не топик на Хабре, а небольшая (небольшая ли?) книга.

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

Для разбиения модулей я пользуюсь одним простым правилом: на модули стоит разбивать только для реализации хорошего юнит теста. Хороший юнит тест, это юнит тест без деталей реализации тестируемого кода («черный ящик»). TDD рулит нереально, при его соблюдении сразу получается код с правильной архитектурой.
«TDD рулит нереально, при его соблюдении сразу получается код с правильной архитектурой. „
Конечно, нет. Никакое TDD не скажет вам, нужно втыкать в это место очередной паттерн, или нет.

Ну и чтобы соблюдать TDD, нужно как бы не меньше усилий, чем на то, чтобы спроектировать хорошую архитектуру. No silver bullet there.
TDD направляет в какую сторону мыслить, а это самое главное. Если у вас легко тестируемое приложение, это значит, что оно представлено в виде отдельных самостоятельно живущих, взаимозаменяемых кубиков. Лучше архитектуры и не надо. Что касается паттернов — со временем о них забываешь, они сами собой придумываются на ходу. Конечно серебряных пуль нету, но зато есть вполне ясная цель, а не архитектура ради архитектуры.
«Если у вас легко тестируемое приложение, это значит, что оно представлено в виде отдельных самостоятельно живущих, взаимозаменяемых кубиков. Лучше архитектуры и не надо.»
Вот здесь и ошибка. Архитектуру никогда нельзя оценить с помощью всего лишь одного критерия.

Свежий пример — надо было написать веб-сервис. Тупой, как три спички, чтение/запись в базу + полторы проверки. И что мы видим в результате? dal на linq2sql, поверх него абстрактный data provider (со своими классами, чтобы убрать зависимости от System.Data.Linq), поверх него business facade (а вдруг это надо использовать не в веб-сервисе), поверх него проксирующая обертка веб-сервиса (со своими классами, чтобы избежать проблем с пересылкой данных).

Все прекрасно тестируется. Отдельные самостоятельные кубики, все заменяется как угодно и на что угодно. Хорошая ли это архитектура? Конечно, нет, потому что на внесение изменений нужно в три раза больше времени и усилий, чем она того заслуживает.
Количество изменений, которые нужно вносить зависит от уже внесенной информации примерно квадратично. От этого никуда не деться. Не бывает «простых» сложных приложений. Так что такая архитектура хороша.
Да? А теперь скажите, чем она лучше следующего варианта: вся логика написана в веб-сервисе, который напрямую общается с linq2sql. Тестируемость сохранена, что характерно.
Вы уменьшили количество требований к решению, соответственно упростился и тест и реализация. Если тест действительно адекватный, то для _данных_требований_ это тоже хорошая архитектура. Хотя мне сложно сказать, хороший ли тест получается в вашем (втором) случае, я не .net-чик, но если у вас нету абстракции от dal, то получается для тестов нужно поднимать фикстурную базу, тест слишком «крупноколиберен», что говорит о не соблюдении persistence ignorance (если вам для данных требований это не нужно, то все ок).
А не было этих требований изначально, понимаете? Задачу я описал сразу («надо было написать веб-сервис. Тупой, как три спички, чтение/запись в базу + полторы проверки»).

Вот и вышло, что есть две «хороших» архитектуры, «лучше которых и не надо». А мне вот надо, чтобы было лучше первой, потому что поддержка обходится слишком дорого.

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

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

Это дает более высокий уровень абстракции и облегчает понимание потока выполнения программы.
Все правильно, деление на модули по инфраструктурному признаку должно быть как минимум. Если точнее выразиться, то такое деление позволяет разделить бизенс-логику и инфраструктурную логику. Однако в крупном приложении может понадобиться дальнейшее дробление на модули, скажем внутри того же бизнес-слоя, а это задача уже более сложная. Понимание того. на сколько сильно нужно закладываться «на будущее» приходит с опытом и в общем-то не существует универсального правила на этот счет. Но мне часто помогает правило, что я описал выше.
>>Понимание того. на сколько сильно нужно закладываться «на будущее» приходит с опытом
Вот об этом я и говорил. Серебрянной пули нет! А золотая середина у каждого своя.
Ваш «вывод» ничем не подтвержден. Вы не показали, почему _плохо_ делать модульные системы.
Sign up to leave a comment.

Articles