Зачем нужно изучать архитектуру и паттерны? Часть 1
В этой статье мы поговорим о проблемах сложности разработки ПО и о том, где они обитают. Когда работа над проектом превращается в карусель, как программисты кладут кирпичи, и почему надо бежать. Что же, начнём!
Типичная работа над проектом в IT-отрасли порой напоминает гигантский аттракцион, этакий гибрид «Американских горок» и «Замка ужасов». Когда все только начинается, то кажется, что сейчас мы взлетим! И программисты-супергерои найдут решение для какой угодно задачи.
Но в ходе активной работы над проектом почему-то оказывается, что вроде бы задумка была хорошая, но тут и там все провалилось. И из всего проекта наружу торчат «костыли».
Далее то, что казалось отличной идеей, стремительно несется к стандарту «сделано на коленке». В конце концов, все разработчики на проекте уже и не мечтают даже о нормальном решении, а пытаются собрать хоть какую-то «тележку», лишь бы она поехала.
Эта нелепая история длится и длится до тех пор, пока не назревает революция. От текущей версии проекта отказываются и все начинается с нуля. Увы, никто не может дать гарантию, что второй заход не пойдет по сценарию первого. Знакомо?
На большинстве проектов этот цикл проходит всегда почти одинаково: сначала были грандиозные планы, потом что-то пошло не так, и все решения отправляются «в мусор», «планы — не так — мусор». Но даже это выглядит не так уж и страшно, если речь идет о небольшом проекте.
Но, к сожалению, все это работает и для глобальных решений. К примеру, Герман Греф ранее сетовал, что для «Сбербанка» написали систему за 30 млрд руб., а потом «выкинули» ее, чтобы переписать все с нуля. Потому что дешевле написать сначала, чем поддерживать работоспособность системы, которая стоит 30 миллиардов.
Превратить такую проектную «карусель», с которой все разбегаются с воплями «Спасите! Я накатался!» из недостатка в особенность IT-отрасли можно. Но сначала давайте разберемся: айтишники, определенно, не самые ленивые и уж точно не самые глупые люди на Земле — почему же тогда так горят проекты?
Проблема сотого кирпича
Важнейшей отличительной чертой IT является проблема сложности. Познакомиться с ней можно, к примеру, в книге Гради Буча «Объектно-ориентированное проектирование с примерами применения».
Увы, но сложность, о которой мы говорим, является, по-видимому, необходимым свойством всех больших программных систем. Под необходимостью мы имеем ввиду следующее: можно создать эту сложность, но нельзя придумать так, чтобы обойтись без нее — пишет нам Гради Буч.
Что же подразумевает такая зловещая формулировка? Фактически, сложность выражается так: количество ресурсов, связей и компонентов, которые требуются для решения какой-либо задачи, растет нелинейно по мере роста размеров проекта.
Давайте рассмотрим это утверждение на примере: сравним работу каменщика и программиста.
Если каменщик строит стену, то мы можем ожидать, что первый кирпич он, допустим, положит за условные 2 минуты, второй еще за 2 минуты, а сотый — уже быстрее, потому что у него выработался навык. К тысячному он, возможно, станет кирпичным виртуозом, и будет делать все просто молниеносно, с закрытыми глазами и прямо во сне.
А что у программиста? Все наоборот. Свой первый виртуальный «кирпич» он кладет за 2 минуты, второй тоже за 2 минуты, сотый кирпич кладет почему-то за час, а тысячный — за три дня… Как так? Это как раз и есть иллюстрация проблемы сложности: растет проект — меняются потребности и, соответственно, необходимые усилия, время и трудозатраты растут вслед за ним.
Грубо говоря, в IT мы можем начать проект вдвоем в гараже, а потом им будут заниматься несколько десятков тысяч человек.
Точнее Буча проблему сложности сформулировал Льюис Кэролл в «Алисе в Зазеркалье», там Черная королева говорит: «Нужно бежать со всех ног, чтобы только оставаться на месте, а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее!».
Это, к сожалению, «тащит» за собой другие малоприятные вещи: то, что программисты все время проваливаются в сроках, то, что все идет не по плану, то, что отрасль постоянно содрогается от кадрового голода и так далее.
«Чем сложнее система, тем ближе она к полному развалу». Строителям редко приходят мысли об установке дополнительного фундамента к уже построенному 100-этажному небоскребу; сделать это будет совсем недешево, да и, наверняка, ничего не выйдет. Но что удивительно, пользователи программных систем совсем нередко ставят подобные задачи перед разработчиками. Это, утверждают они, всего лишь технический вопрос для программистов (снова Гради Буч).
Из-за этой же проблемы сложности сейчас все обратились к философии Agile: планировать работу программистов напрямую, обычными средствами тяжело, если не невозможно, необходимо просто смотреть за тем, что получается и находить в этом ценность. Потому что затраты будут расти нелинейно и, в целом, надо за имеющиеся деньги успеть сделать хоть что-то полезное.
«Дополнительная сложность обусловливается изменением требований к программной системе уже в процессе разработки, в основном из-за того, что само существование проекта программной системы часто изменяет проблему" — Гради Буч, цитата из книги «Объектно-ориентированное проектирование с примерами применения».
Сегодня Agile получается как раз об этом: мы потратили ваши деньги, но не просто так — а с пользой, заранее мы ничего не планировали, но вот, какая удача — что-то получилось.
Итак, в программировании есть несколько проявлений проблемы сложности. Поговорим о них в следующей части статьи, где разберём 4 проявления проблемы сложности при разработке ПО: алгоритмическую сложность, трудоемкость разработки, информационную сложность и сложность тестирования. Следите за новостями!
