• Новости
• Блоги
• Аналитика
• Новости компаний
• В СНГ и в мире
• Анонсы

Колосс на глиняных ногах

24 ноября 2015

Что такое концепция? Все известные определения этого понятия не отвечают на интересные вопросы. Зачем она нужна? Можем ли мы без нее обойтись? Почему концепцию может написать не каждый, и какой такой квалификацией должен обладать специалист, способный на такое дело?

Предложу простое, но противоречивое определение. Концепция – это предельно краткое описание системы, содержащее большое количество полезных для дела деталей. Где подвох? Как в краткое описание может поместиться куча деталей? Не знаю, хорошая концепция – это искусство. Не зря же говорят: «красивая концепция» или, наоборот, «путаная концепция». Именно возможность кратко передать сложные вещи и воспринимается (ощущается) специалистами как красота…

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

Где раки зимуют

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

1. Мы живем в очень динамичном мире. В любом деле инструменты быстро меняются. Вслед за этими изменениями нужно менять и программы.
2. Хорошая программа – это совершенно новый инструмент в руках специалиста, и ее использование меняет процесс работы. Изменения, конечно, планируют заранее, но не все удается предсказать. Инструмент новый, и многое используется не так, как ожидалось. Какие-то изначально задуманные функции оказываются лишними, ну и ладно. Но ведь других нужных функций в ПО теперь не хватает.
3. Как только специалист берет программу в свои руки, он ощущает невероятные возможности, тут же появляются неожиданные требования по усовершенствованию для получения дополнительных полезных эффектов.

Многое предсказать не удается даже людям с большим опытом. Ограничения человеческого воображения и мышления не позволяют заранее представить себе картину, как все будет работать в достаточных деталях. В результате в новом ПО обнаруживаются неожиданные эффекты. Одни их называют фичами, другие глюками, третьи архитектурными ограничениями. Научное же название – «эмергентные характеристики и качества» (то есть не предсказанные заранее). Именно эмергентность ставит в тупик управляющих проектами, когда выясняется, что в той ситуации, в которой проект оказался, количество путей развития ограничено какими-то рамками, о которых изначально никто и не задумывался.

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

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

Конструктор-самоделкин

Как это делается обычно

Детали программного обеспечения тщательно прописываются в ТЗ. Описывают даже в подробностях, кто какую кнопку и в какой момент будет нажимать. Разрабатывая программу по такому ТЗ, программист строит готовое решение, менять которое не предполагается. Главный принцип упущен…

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

Как надо

Хорошая архитектура системы позволяет не переписывать ее каждый раз, а вносить небольшие изменения. Главное отличие здесь в том, что надо создавать не продукт, а конструктор, из которого будет собираться будущее решение. Потратив много времени на конструктор и мало на внешний интерфейс, можно считать решение готовым по сути. Даже если потребуется развитие, можно быстро смонтировать нужные части и отштукатурить фасад.

Представим себе, что на презентации решения мы слышим такой диалог:
– А как в вашей программе можно сделать вот это?
– Это можно сделать тремя разными способами.

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

Конструктор – это язык программирования: на одном (стандартном) языке мы пишем другой специальный язык (конструктор), а уже на нем решаем задачу. Если требуется писать ПО детальному ТЗ, то даже в этом случае все равно сперва создаем "набор инструметнов" и потом с помощью них решаем задачу.

Издержки процесса

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

Как быть? Ответ: не мешать все в кучу. Нам нужен результат, а не мониторинг. Контроль инновационного процесса одновременно несет пользу (улучшает планирование, мотивирует к своевременному выполнению работ) и негатив (стресс для контролируемого и отвлечение его от основной работы). Что перевешивает? Никаких обстоятельных исследований на эту тему не приходилось видеть. Лично я уверен (писал об этом в статье про "добычу-продажу жемчуга", что промежуточный результат инновационного проекта с точки зрения контроля – это всегда бутафорская презентация, в которой контроллер избавлен от сложных и непонятных ему деталей. То есть польза отсутствует, а негатив остается.

Поэтому оставим тему контроля на следующий раз и поговорим о главном: как сделать удобный конструктор? С чего начать и как закончить? То есть, как и было обещано, переходим ко второму ключевому вопросу – архитектуре.

Опоры

Чтобы минимизировать переписывание программы (избежать этого полностью нельзя, но сократить объем работ можно), нам нужна хорошая архитектура. Что означает это заезженное слово «хорошая», мы сейчас увидим.

Проблема

Процесс создания конструктора буду объяснять на примере проектирования систем для бизнеса. Итак, все программы учета и управления принято проектировать от процесса, который состоит из: сотрудников, отделов, должностей, обязанностей, процессов, результатов, отчетов о результатах и т. д. Именно этот компот и порождает хаос в условиях постоянной перетряски, которая происходит всегда. Проект разработки и внедрения ПО длится определенное время, и если задачи поставлены в терминах отделов, сотрудников и обязанностей, то уже к середине проекта выясняется, что всего этого уже нет. Сотрудники сменились, отделы реорганизовали, обязанности перераспределили.

Раз здесь трясина, то где же твердая почва? Как известно, глаз реагирует прежде всего на движение, поэтому неподвижного слона легко и не заметить. Посмотрите внимательно: ведь стабильность – она везде вокруг нас.

Решение

В каждом бизнесе есть какие-то незыблемые сущности. Это те операции (или их части), мероприятия, физические объекты, которые наверняка останутся неизменными в течение десятков лет. Именно на них и надо опереться при проектировании архитектуры.

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

В данном примере незыблемой мы предполагаем частную собственность, а зыбкими – средства ее обеспечения. Например, незыблемым можно считать документ, фиксирующий переход права собственности, то есть накладную. Конечно, такой подход не математичен и весьма условен. Например, машину с товаром можно считать незыблемой сущностью, но если мы переместим компанию на Марс, то нам понадобится космический корабль…

Упростим идею: в архитектуре надо отбросить все лишнее и сосредоточиться на главном. Только так можно получить надежный результат, из-под которого не будет уплывать действительность быстрее, чем скорость исправления багов. Выбирайте архитектора, который хорошо понимает "что важно, а что нет", не только в информационных технологиях. Хорошую ИТ-архитектуру может написать только широко-эрудированный специалист. Он должен видеть не только частную задачу, но и предвидеть работу проектируемой системы через несколько лет. Кстати, и от писателя концепции тоже требуется высокая эрудиция по полному кругу затрагиваемых вопросов.

На века

Формат журнальной статьи не позволяет подробно описать все конструктивные особенности процесса программирования (который тоже является часть проектирования, по мнению многих гуру в этой области). Описанные принципы неточны, но здесь важен подход. В основу двух правил проектирования ПО лег жизненный принцип, который говорит, что результат труда должен быть фундаментальным, надежным и служить долго. Однако фундаментальность обычно не ассоциируется с гибкостью. Это неправильные ассоциации, которые будут мешать работе, ведь принцип «твердая опора, гибкая конструкция» работает очень часто.

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

Из блога Дмитрия Мартынова

Оставить свой комментарий:

Комментарии по материалу