Комментарии 19
Почему-то ожидал большего.
Например, случаи, когда модульность полезна, а когда вредна. Примеры кода… Хотя…сперва добейся
Например, случаи, когда модульность полезна, а когда вредна. Примеры кода… Хотя…
Я не хотел конкретизировать тему. Мне кажется я раскрыл ее достаточно, чтобы заставить читателя подумать — насколько модульным должна быть ЕГО программа.
Примеры кода? Хорошая модульность обычно в Python и Java. Плохая очень часто встречается в PHP и Javascript.
Примеры кода? Хорошая модульность обычно в Python и Java. Плохая очень часто встречается в PHP и Javascript.
Хватит уже дёргать PHP, а?
Быдлокодеры есть везде, просто PHP популярен, и в абсолютных числах, наших быдлокодеров много =)
А по поводу JS, посмотрите на extJS.
Там такой уровень абстракции, что питонистам и не снился.
Быдлокодеры есть везде, просто PHP популярен, и в абсолютных числах, наших быдлокодеров много =)
А по поводу JS, посмотрите на extJS.
Там такой уровень абстракции, что питонистам и не снился.
Про ExtJS согласен.
PHP я не дергаю. Это мой любимый язык. Я им на жизнь зарабатываю. Но ввиду популярности PHP — под него быдло-спагетти кода в разы больше, чем под остальное. Точно так же как в виду популярности винды под нее больше безграмотных якобы-админов.
В общем я просто проконстатировал факты в предыдущем комменте :)
PHP я не дергаю. Это мой любимый язык. Я им на жизнь зарабатываю. Но ввиду популярности PHP — под него быдло-спагетти кода в разы больше, чем под остальное. Точно так же как в виду популярности винды под нее больше безграмотных якобы-админов.
В общем я просто проконстатировал факты в предыдущем комменте :)
Здравствуйте, КО!
Неужели вы думаете, что подобные вещи можно рассказывать на одном примере? Умение писать код с низкой связанностью и хорошо разбитый на «модули» приходит только с опытом.
Кстати, пример — плохой. Не надо делать вид, что работа с удаленным сервером настолько же проста, как и с локальной файловой системой. В реальном приложении может потребоваться нарисовать для юзера ProgressBar, придумать как реагировать на потерю соединения и т.п.
Неужели вы думаете, что подобные вещи можно рассказывать на одном примере? Умение писать код с низкой связанностью и хорошо разбитый на «модули» приходит только с опытом.
Кстати, пример — плохой. Не надо делать вид, что работа с удаленным сервером настолько же проста, как и с локальной файловой системой. В реальном приложении может потребоваться нарисовать для юзера ProgressBar, придумать как реагировать на потерю соединения и т.п.
«TDD рулит нереально, при его соблюдении сразу получается код с правильной архитектурой. „
Конечно, нет. Никакое TDD не скажет вам, нужно втыкать в это место очередной паттерн, или нет.
Ну и чтобы соблюдать TDD, нужно как бы не меньше усилий, чем на то, чтобы спроектировать хорошую архитектуру. No silver bullet there.
Конечно, нет. Никакое TDD не скажет вам, нужно втыкать в это место очередной паттерн, или нет.
Ну и чтобы соблюдать TDD, нужно как бы не меньше усилий, чем на то, чтобы спроектировать хорошую архитектуру. No silver bullet there.
«Если у вас легко тестируемое приложение, это значит, что оно представлено в виде отдельных самостоятельно живущих, взаимозаменяемых кубиков. Лучше архитектуры и не надо.»
Вот здесь и ошибка. Архитектуру никогда нельзя оценить с помощью всего лишь одного критерия.
Свежий пример — надо было написать веб-сервис. Тупой, как три спички, чтение/запись в базу + полторы проверки. И что мы видим в результате? dal на linq2sql, поверх него абстрактный data provider (со своими классами, чтобы убрать зависимости от System.Data.Linq), поверх него business facade (а вдруг это надо использовать не в веб-сервисе), поверх него проксирующая обертка веб-сервиса (со своими классами, чтобы избежать проблем с пересылкой данных).
Все прекрасно тестируется. Отдельные самостоятельные кубики, все заменяется как угодно и на что угодно. Хорошая ли это архитектура? Конечно, нет, потому что на внесение изменений нужно в три раза больше времени и усилий, чем она того заслуживает.
Вот здесь и ошибка. Архитектуру никогда нельзя оценить с помощью всего лишь одного критерия.
Свежий пример — надо было написать веб-сервис. Тупой, как три спички, чтение/запись в базу + полторы проверки. И что мы видим в результате? dal на linq2sql, поверх него абстрактный data provider (со своими классами, чтобы убрать зависимости от System.Data.Linq), поверх него business facade (а вдруг это надо использовать не в веб-сервисе), поверх него проксирующая обертка веб-сервиса (со своими классами, чтобы избежать проблем с пересылкой данных).
Все прекрасно тестируется. Отдельные самостоятельные кубики, все заменяется как угодно и на что угодно. Хорошая ли это архитектура? Конечно, нет, потому что на внесение изменений нужно в три раза больше времени и усилий, чем она того заслуживает.
Да? А теперь скажите, чем она лучше следующего варианта: вся логика написана в веб-сервисе, который напрямую общается с linq2sql. Тестируемость сохранена, что характерно.
А не было этих требований изначально, понимаете? Задачу я описал сразу («надо было написать веб-сервис. Тупой, как три спички, чтение/запись в базу + полторы проверки»).
Вот и вышло, что есть две «хороших» архитектуры, «лучше которых и не надо». А мне вот надо, чтобы было лучше первой, потому что поддержка обходится слишком дорого.
Про что и спич — одного TDD недостаточно, чтобы определить хорошую архитектуру.
Вот и вышло, что есть две «хороших» архитектуры, «лучше которых и не надо». А мне вот надо, чтобы было лучше первой, потому что поддержка обходится слишком дорого.
Про что и спич — одного TDD недостаточно, чтобы определить хорошую архитектуру.
Иногда трудно предсказать, какая функциональность может понадобиться в будущем. Я сам пока с трудом понимаю, как правильно эту модульность реализовывать. На данный момент склоняюсь к варианту, что модули должны соответствовать используемым технологиям.
Допустим, мы имеем приложение, в котором есть данные, логи и конфигурация, лежащие в неком хранилище. Также есть парочка сторонних библиотек, которые отвечают за разные этапы обработки информации. Все это (работа с данными, логами, конфигурацией, сторонними библиотеками) нужно обернуть в отдельные модули.
Это дает более высокий уровень абстракции и облегчает понимание потока выполнения программы.
Допустим, мы имеем приложение, в котором есть данные, логи и конфигурация, лежащие в неком хранилище. Также есть парочка сторонних библиотек, которые отвечают за разные этапы обработки информации. Все это (работа с данными, логами, конфигурацией, сторонними библиотеками) нужно обернуть в отдельные модули.
Это дает более высокий уровень абстракции и облегчает понимание потока выполнения программы.
Ваш «вывод» ничем не подтвержден. Вы не показали, почему _плохо_ делать модульные системы.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Еще раз о модульности