Насколько гибок ваш продукт?

[zibsun]

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

Мне кажется, можем.

Comments

Про бесплатный сыр

[d_zh]

А чем мы платим за получаемую гибкость?

Re: Про бесплатный сыр

[zibsun]

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

Re: Про бесплатный сыр

[d_zh]

Коммуникации при согласовании требований для спецификации тоже немало :-)

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

Agile хорош на относительно коротких прямых участках, но все равно нужно иногда все водиночку разломать, со сменой концепции, объектной модели и с отъезжанием всех тестов :-) И особенно при продуктовой разработке :-)

Re: Про бесплатный сыр

[zibsun]

Интересно, а что такое хорошая архитектура?

Все эти ваши "гибкие" в кавычках архитектуры ознчают часто на практике мегафрейворк, который мы за 6 месяцев напишем, а потом за 1 месяц замочим XML для конкретного заказчика. А потом приходит заказчик и говорит "у нас добавился уровень иерархии" и начинается "в одиночку все разломать" и "со сменой концепции":-)

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

Ваш код стал слишком связанным и не тянет дальнейшего усложения функциональности.

В реальности нужна деревенька :-) В смысле decoupling.

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

Re: Про бесплатный сыр

[d_zh]

Небоскреб получает все прелести деревеньки при регулярном запуске code inspections и разнесением избыточных зависимостей через, например, spring.

По поводу мегафрэймворков --- большая ошибка начинать проект с этого, когда еще не видны пути развития продукта. Но на каком-то этапе развития все равно придется сделать качественный переход, в т.ч. на мегафрэймворк (МФ). МФ позволяет приятную вещь --- разработчику можно знать и помнить меньше. Коллективное знание, обеспеченное совместным владением кодом, не стреляет, когда за несколько лет на 5 человек приходится 5000 классов и продукта существенно более одного заказчика со своими особенными требованиями.

Дальше по поводу рефакторинга --- http://d-zh.livejournal.com/795.html

Re: Про бесплатный сыр

[zibsun]

A-a-a-a. Каким-то волшебным образом я стал противником архитектуры вообще. Не иначе как потому что являюсь "апологетом agile" :-)

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

Re: Про бесплатный сыр

[d_zh]

Я у себя целый пост написал с примерами :-) Применяя практики Agile вы не сможете постепенно перейти от кучи условных конструкций к системе управления правилами. От системы управления правилами вы не сможете постепенно перейти к системе, которая сама строит правила на основании юнит-тестов. Это качественные переходы, которые выходят за рамки текущей архитектуры, какой бы decoupled она не была. И юнит-тесты придется переписать очень сильно, поскольку изменится сама концепция объектной модели.

Re: Про бесплатный сыр

[zibsun]

> Применяя практики Agile вы не сможете постепенно перейти