Про не свой монастырь, но свой устав

Довелось поучаствовать в очень интересной, на мой взгляд, дискуссии. Так вот, как мне кажется человек не с той стороны подходит к джанго и к agile технике как таковой.

Нет. я не отрицаю этап моделирования или проектирования. Они безусловно нужны. И теоретики agile подхода на этом делают акцент. Но не надо возводить их в ранг первостепенных и основных этапов разработки.

Имея настолько гибкие инструменты как динамические языки программирования (питон), и фреймворки (джанго), можно и моделировать, и проектировать используя их. Тот DSL который предоставляет джанго для описания моделей, на мой взгляд, настолько нагляден и даже визуален, что заменять его диаграммами, и уж тем более ставить их во главу угла нельзя. Написанная модель это не только некая мета информация, но уже готовый функционал, который можно подергать через shell и прикинуть варианты использования. Всё это сразу. Без сугубо теоретических рисований диаграмм и их перетаскивания их одного угла в другой.

Диаграммы конечно же нужны. Но потом. Либо в момент написания некой вспомогательной документации, либо просто для вникания в проект. Благо есть почти автоматически решения, которые по моделям джанго строят вполне приятного вида картинки с прямоугольниками и связями:)

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

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

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

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

Тем более, если вы, ещё не начав реализовывать проект, подсчитали такое количество сущностей. То это повод лишний раз задуматься над архитектурой. Ведь в процессе разработки их может стать ещё больше.

Ну а сколько времени уйдет на их моделирование и проектирование?

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

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

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

Интересное совпадение, сразу после завершения диалога в этой теме, меня сделали модератором раздела по Django в этом форуме. Точно совпадение:)

P.S. И ещё, вот тут в django-developers начинают притесняют "языковые меньшинства". Наверно последней каплей для некого Тома Тобина стал мой вчерашний пост, который провисел в агрегаторе на первом месте достаточно долго и явно намозолил глаза:)

Комментарии 7

  1. Ivan написал:

    Вопросы проектирования в принципе всегда остры. НО. Если человек мало разбирается в том, что он делает и как, то ему никакие схемы не помогут...

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

    Оставлен 14 Июнь 2008 в 06:55
  2. AK написал:

    Пара очепяток:

    можно подергать через shall

    то это не проблема инструмент

    Оставлен 14 Июнь 2008 в 10:33
  3. Александр Кошелев написал:

    Вопросы проектирования в принципе всегда остры. НО. Если человек мало разбирается в том, что он делает и как, то ему никакие схемы не помогут...

    Согласен

    Оставлен 14 Июнь 2008 в 11:05
  4. Иван Маркеев написал:

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

    Оставлен 18 Июнь 2008 в 20:12
  5. Ivan написал:

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

    Допустим проектируем распределенную систему. Если сразу не опираться на набор технологий обмена данными (SOAP, XML-RPC, SOCKETS), то можно основательно застрять. Такой случай был у меня, когда проект изначально сделали на SOCKETS, а выяснилось, что при больших объемах данных этот метод не выгоден, в итоге пришлось переделывать часть на SOAP. То же касается связки AJAX. Мне лично горько за то, что у нас AJAXовые сайты работают не на XML. А все потому что изначально такое не заложили или "никто не разбирается в XML", или все привыкли работать только с HTML.

    ЗЫ. Грамотный архитектор должен сразу заложить все возможные варианты, из которых потом надо выбрать самый удобный в реализации и исполнении. Жаль, но обычно у подобного рода "спецов" такого не получается.

    Оставлен 19 Июнь 2008 в 13:58
  6. Михаил написал:

    эээ... всё что я усвоил из общения с UML, так это то, что проектировать надо всегда начинать с use-case. а из них уже вылезет и бд и архитектура. лично я для описания use-case'ов использую функциональные тесты (правда под zope3, но я вижу что и в django появилась такая возможность). и процесс разработки формален: прошёл тест - спи спокойно, до тех пор пока в тест не впишут новые use-case для новой функциональности.

    Оставлен 20 Июнь 2008 в 00:23
  7. Maximbo написал:

    лично я для описания use-case'ов использую функциональные тесты (правда под zope3, но я вижу что и в django появилась такая возможность). и процесс разработки формален: прошёл тест - спи спокойно, до тех пор пока в тест не впишут новые use-case для новой функциональности.

    +1 за одним маленьким исключением: unittests нельзя показать ни заказчику, не партнёрам по проекту, лишённым технических знаний. Поэтому в центре всё же должны стоять словестные варианты использований, которые, тем не менее, довольно легко транслируются в код тестов.

    Оставлен 01 Июль 2008 в 19:20