Как известно большинству руководителей разработчиками, система Виртуального Архива Судов (Virtual Case File (VCF)) стала самым дорогим провалившимся проектом в нашей отрасли. Проглотив от 100 до 200 миллионов долларов налогоплательщиков, она не оставила после себя ничего, кроме горы бесполезной документации, примерно миллиона строк никому не нужного кода и множества жестоких уроков. Что еще хуже, все эти уроки, которые стали результатом многомиллионной катастрофы, можно было найти в пятидесятидолларовой книге по проектированию программного обеспечения. Более того, все причины, стоявшие за крахом VCF, будто бы взяты из оглавления этой книги:
- Промышленная Архитектура: У VCF ее не было.
- Управление: Разработчиками плохо руководили как на микро-, так и на макро- уровнях.
- Опытные Сотрудники: На критические направления были назначены руководители и инженеры без должной подготовки.
- Требования: Они постоянно менялись.
- Ползучий фичеризм: Новые функции добавлялись даже после того, как проект выбился из сроков.
- Стабильная команда: Чтобы ускорить разработку постоянно добавлялись новые люди.
Хотя все эти ценные уроки каждый начальник должен зазубрить наизусть, один из самых важных, причем обсуждаемый гораздо меньше других урок проистекает из редкого в том проекте верного решения – решения сматывать удочки и выкинуть на помойку весь этот ужас.
Как бы трудно не было закрыть разработку VCF, альтернатива была бы гораздо мрачнее. Если бы VCF ввели в промышленную эксплуатацию, работоспособность Бюро упала бы ниже плинтуса, ведь агентам пришлось бы сражаться с кишащей багами системой. Программистам пришлось бы вкалывать денно и нощно, прилаживая к системе патч за патчем в тщетных попытках исправить известные недоработки, и попутно внося бессчетное количество новых. Еще многие миллионы были бы потрачены на поддержание системы в угрожающем состоянии стабильной нестабильности, когда чрезвычайно трудно оценить затраты и риски на исправление даже самой бестолковой ошибки. В конце концов, и вполне вероятно, что всего через несколько незаметно пролетевших лет, систему придется переделывать с нуля.
Хотя лишь немногим придется руководить проектом такого масштаба как VCF, большинство могут ясно представить себе, во что превратилась бы VCF: в необъятного программного левиафана, вменяемость которого тает на глазах, с гниющей, неумолимо расползающейся плотью кода. Такие приложения относятся к наихудшим из провалов: мнимому успеху.
Страшнее провала
Когда крупномасштабная программная система вводится в эксплуатацию, почти везде это считается успехом. В большинстве других отраслей было бы нелепым приравнивать завершение чего-либо к успеху. В конце концов, мало кто в строительстве назовет двухлетний дом с протекающей крышей и просевшим фундаментом чем-то иным кроме как катастрофой и прямо заявит о возникших проблемах.
Да, если бы VCF было суждено заработать, практически каждый, кто приложил к ней руку, начиная с бизнес аналитиков, и заканчивая программистами с их начальниками, назвали бы свою работу успешной. Даже после того, как система превратится в мерзкое месиво, многие не будут признавать своего провала. В результате все это будет повторяться снова и снова, пока разработчики будут отказываться признавать наличие проблем, разъедающих их проекты.
Будучи редактором этого сайта, я следил за крушениями программных проектов годами. В большинстве этих историй очень много общего: плохое руководство, неверные процедуры и тонны человеческих ошибок. Вообще, в подавляющем большинстве тех провалов, что я задокументировал очень мало, если вообще хоть что-то зависит от технологий, зато все зависит от людей их использующих.
Единственный способ избежать таких провалов, быть реалистом насчет успеха. И если взглянуть на вещи здраво, то корпоративное ПО обязано проработать минимум 15 лет. Все, что не может продержаться это время, должно считаться неудачным.
Основная причина, по которой заменяется специализированное корпоративное ПО, заключается в том, что его поддержка начинает обходиться слишком дорого. В особенности это касается старинного и очень удачного софта. Представьте, насколько трудно и дорого создать (или хотя бы найти, способных это сделать программистов) работающий в реальном времени модуль поиска по складскому реестру для написанной на COBOL-е системы складского учета 80-х годов. В подобных случаях замена старой системы, или хотя бы переделка ее основных частей, обычно единственный разумный способ снизить до приемлемого уровня издержки на обслуживание.
Грамотно спроектированная система, созданная на протяжении последних восьми – десяти лет не требует масштабной модернизации.
Истоки хаоса
Отсутствие возможности поддержки часто становится основной причиной провала программных проектов, рассказывает бывший MVP (Most Valuable Professional – Самый Ценный Специалист) Microsoft Фил Хаак, разработчик, который часто пишет в своем блоге о поддержке программных систем. Он заучил урок о поддержке с младых ногтей, когда его команда получила задание на создание довольно простого меркетингового Веб сайта, который клиент должен были использовать для получения отзывов. На сайте была форма, которую должны были заполнять посетители, и все что в нее заносилось, отправлялось в компанию по электронной почте.
Они решили придерживаться простоты: никаких баз данных, никаких особых настроек и никакой расширяемости. Сайт работал прекрасно. Проект был завершен в срок и не вылез из бюджета, а клиент был удовлетворен. Вообще, все работало настолько хорошо, что клиент пришел снова, и попросил добавить еще одну форму.
Хотя система не проектировалась под работу с несколькими формами, добавить вторую было нетрудно. При помощи нескольких хаков им удалось вдолбить в систему новые требования и заставить ее работать так, как того требовал клиент. Через месяц клиент попросил добавить третью форму. Команда Хаака похакала, скомпилировала и выдала что требовалось. Затем им понадобилась четвертая. Хакаем, компилируем, выдаем. Потом пятая. Хакаем, компилируем, выдаем. С каждым новым требованием некогда простое приложение постепенно превращалось в запутанное нагромождение кода.
После года изменений в Веб приложении уже использовалась база данных, COM объекты и куча других технологий, которые были далеко за пределами предметной области первоначального приложения. Кроме того, каждое обновление было более рискованным и обходилось все дороже по мере течения времени. Команда быстро теряла способность поддерживать систему.
«На каждое новое задание уходило гораздо больше времени, даже если требования были не сложнее предыдущих», рассказывает Хаак. «Приложение стало слишком монолитным, и его было слишком трудно поддерживать».
Наконец команде Хаака пришлось отправиться к клиенту с дурными вестями: Приложение, которое они создавали и расширяли на протяжении почти двух лет, превратилось в полный бардак. Что еще хуже, оно стало настолько сложным, что и переписать его не представлялось возможным. Им оставалось только реализовать в новом приложении мост к старым функциям и затем поверх этого выстраивать унифицированную платформу.
Признание провала
Команде Хаака было непросто признать провал. Разумеется, они могли все свалить на клиента, с его постоянно растущими аппетитами, но, в конце концов, это их команда создала приложение и позволила ему разрастись из просто формы в неподдерживаемое чудовище. Их ошибка была не в выбранном изначально пути, а в том, что они не сошли с этого пути вовремя.
Другими словами, решение команды создать простое приложение под простые требования было верным. Никто не мог предсказать, что система изменится так, как она в итоге изменилась. Если бы они создали первую версию программы более гибкой и расширяемой, возможно, добавив базу данных для форм, или их группировку, требования запросто могли бы измениться таким образом, что эти функции не имели бы смысла, или что еще хуже, стали бы обременительны.
«Избегайте преждевременного обобщения», советует Хаак. «Не создавайте систему способную предсказать любое изменение. Пусть она будет достаточно гибкой для внесения изменений».
Чтобы определить, когда требуется обобщение, Хаак использует Правило Трех: «Когда вы в первый раз увидите, что что-либо может повторяться, не обобщайте это. В следующий раз сделайте все аналогичным способом, возможно даже при помощи копипастинга, но только не обобщайте. В третий раз хорошенько подумайте, как это можно обобщить».
В случае Веб приложения Хаака, такой подход мог бы заставить его команду обобщать рабочий код с каждой новой итерацией. Со временем вносимые изменения могли бы помешать «древним» кускам кода превратиться в закостеневшее наследие.
Дружественное к изменениям окружение
Как VCF так и Веб приложение Хаака рухнули под собственной тяжестью, первое, так и не дожив до промышленной эксплуатации, второе после непродолжительного двухлетнего существования. Они бы жили непредсказуемо долго, если бы их можно было поддерживать.
Создание поддерживаемого программного обеспечения, то есть гибкого по отношению к внесению различных изменений, должно начинаться гораздо раньше и на гораздо более высоком уровне, чем сам код или структура программы. Оно начинается на самом высоком уровне, Архитектуре Системы, и влияет на все этапы жизненного цикла системы.
Бизнес аналитиков и разработчиков необходимо обучать таким образом, чтобы они полностью отдавали себе отчет в том, что создаваемое ими ПО обязательно будет изменяться, причем, таким образом, который им и в голову никогда не придет. Кроме того, такие инструменты как рефакторинг и шаблоны проектирования должны быть неотъемлемой частью процесса разработки.
Процессы тестирования и контроля качества также должны быть готовы к изменениям. По мере того как изменяется ПО, вслед за ним изменяются модульные, первоначальные и возвратные тесты. Без адекватного, полного и своевременного тестирования, дефекты, вызванные постоянными изменениями, соберутся в огромную кучу, которую потом будет очень трудно разгрести.
Наконец, руководители разработкой должны быть в состоянии определить момент, когда разработка системы провалилась, и найти в себе силы переступить через нее и двигаться дальше. Чем раньше это случится, тем меньше вреда принесет проект. И в отличие от VCF, вполне может статься, что на пепелище найдется что-то стоящее.
Статья Как избежать катастрофы при разработке была изначально опубликована в колонке Алекса DevDisasters в номере Redmond Developer News от 1 октября 2007 года. RDN это бесплатный журнал для активных читателей, который рассказывает о планах Microsoft, а так же свежих новостях и событиях интересующих Windows разработчиков.
Оригинал:http://thedailywtf.com/Articles/Avoiding-Development-Disasters.aspx
Перевод:Евгений Виговский
