среда, ноября 07, 2007

Beyond Architecture

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

Любое проектное решение должно приниматься осмысленно. Мы привыкаем "выделять слой доступа к данным, слой бизнес логики..." и т.д. просто потому, что делаем это всегда. А ведь это - проектные решения, и они были в свое время придуманы для решения совершенно определенных проблем и задач. Всегда сказав "а", говори "б". Сказав "мы выделяем слой ...", говори самому себе "для того, чтобы...". Это первое.

Второе. Никогда не следует забывать о том что программирование по своей природе "мягкая" (soft) область инженерной науки. Здесь всегда существует несколько вариантов решения проблемы. А проектные решения, это всегда компромисс. Любое решение имеет плюсы и минусы. Мы очень охотно оцениваем плюсы и почти всегда забываем рассмотреть минусы. А в каждой конкретной ситуации важность, или вес того или иного аспекта (плюса или минуса) может быть разной.
Просто придумать хороший дизайн системы, опереться на паттерны проектирования, сделать "все как надо" это еще пол дела (или вернее, пол беды :). Гораздо сложнее и важнее, увидеть слабые стороны своего решения, найти ему альтернативы, выявить все плюсы и минусы для каждой из альтернатив.

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

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

2 комментария:

Анонимный комментирует...

Вы пишете: "...И наконец принять решение. Не единственное и верное, а компромиссное и одно из многих. И быть готовым нести за него ответственность."

Ммм, не совсем понятно, какие могут мерила ответственности?

Sergey Rozovik комментирует...

> Ммм, не совсем понятно, какие могут мерила ответственности?

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