ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 25.10.2023
Просмотров: 356
Скачиваний: 11
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Глава 2. Почему же Agile?
86
И они отвечают: «Надо все переделывать» .
Представьте, в какой ужас приходят менеджеры . Сколько денег и времени было вложено в проект! И что мы видим? Разработчи- ки советуют выбросить все наработки и начать проект с чистого листа!
И как считаете, верит ли руководство разработчикам, когда те обе- щают, что «в этот раз будет все по-другому»? Конечно, нет! Они ж не дураки, чтобы поверить этому . Но что же им теперь делать?
Производительность уже и так ниже плинтуса . Такими темпами работа не может продолжаться . Поэтому после многочисленных стенаний они соглашаются на рефакторинг .
У разработчиков засверкал в глазах огонь . «Слава богу! Наконец- то можно вернуться в те времена, когда трава зеленее и код чище», — скажут они . Но, конечно же, все не так просто, как ка- жется . Команда разбивается на два лагеря . Отбирается лучшая десятка — ударная группа, те самые орлы программирования, которые больше всех ответственны за беспорядочный код . Им выделяют отдельную комнату . Теперь они поведут всех остальных в мир рефакторинга . Остальные же их на дух не переносят, по- тому что из-за них приходится сопровождать тот отстой, который уже написан .
Откуда наша ударная группа берет требования? Есть ли на сегод- няшний день какой-нибудь документ, где представлены требова- ния? Да . Это код, который уже написан . Этот код — единственный документ, который точно дает понять, как должна выглядеть про- грамма после рефакторинга .
Поэтому орлы вчитываются в написанный код, пытаясь сообра- зить, что с этим кодом не так и как нужно писать новый . Между тем
Разумные ожидания
87
другие программисты вносят изменения в старый код, устраняют ошибки и добавляют новый функционал .
Гонка продолжается . Ударная группа пытается поймать движу- щуюся добычу . И как Зенон показал в своей апории об Ахиллесе и черепахе, поймать движущуюся добычу не так-то просто . Каж- дый раз, когда они доходят до этапа разработки, на котором нахо- дился написанный код, этот код уже изменился .
Чтобы доказать, что Ахиллес все равно догонит черепаху, нужно применить математический анализ . В разработке ПО это не всегда удается . Я работал в компании, где новое программное обеспечение не получалось развернуть в течение десяти лет . Клиентам обещали представить новый пакет программ еще восемь лет назад . Однако им постоянно не хватало функционала в новых программах, старые справлялись со своими задачами лучше . Поэтому клиенты не стали пользоваться новым пакетом программ .
Несколько лет спустя клиенты просто перестали обращать внима- ние на обещания о предоставлении новой системы .
С их точки зрения, подходящей системы никогда не было и не могло появиться .
В то же время компания, занимавшаяся написанием программ, оплачивала работу сразу двух команд разработчиков: тех самых ударных групп и сопровождающих . В конечном итоге руководство очень расстроилось и уведомило клиентов о том, что компания собирается развернуть новый пакет программ, несмотря ни на ка- кие возражения . У клиентов началась истерика, но она не шла ни в какое сравнение с той, которую закатили разработчики, та самая ударная группа, а точнее сказать — то, что осталось от их команды .
Всю команду, которая занималась разработкой с самого начала,
Глава 2. Почему же Agile?
88
повысили до руководящих постов . Нынешние члены команды дружно встали и в один голос заявили: «Нельзя это поставлять, вы что? Это же фуфло . Надо все переделывать!»
Да-да, еще одна байка от Дяди Боба . Она основана на реальных событиях, но я чуть-чуть приврал для красного словца . И все же основной посыл вполне правдив . Масштабный рефакторинг — это чудовищно дорого и редко востребовано .
Клиенты и менеджеры не рассчитывают, что разработчики сбавят темпы . Скорее, они думают, что если реализация функции заняла одну или пару недель в начале проекта, то и через год подобная функция будет реализована в те же сроки . Они ожидают, что про- изводительность будет стабильна на протяжении всего проекта .
Разработчики должны ожидать этого не меньше . Благодаря не- прерывному поддержанию чистоты архитектуры, проекта и кода настолько, насколько это возможно, сохраняется высокая произ- водительность, и команда не попадает в ловушку медлительности и перепроектирования .
Далее вы увидите, что такие методы Agile, как тестирование, пар- ное программирование, рефакторинг и простота структуры про- екта, помогают избежать попадания в эту ловушку . А игра в плани- рование — это противоядие от давления сроков, подталкивающего разработчиков в эту ловушку .
Недорогие изменения
Программное обеспечение — это словосочетание . Со словом «про- граммное» все понятно . Рассмотрим слово «обеспечение» . Оно означает, что пользователь обеспечен функционалом, необходи-
Разумные ожидания
89
мым для успешного выполнения своих задач . Получается, что программное обеспечение — это программы, обладающие необхо- димым функционалом . А полнота функционала невозможна без изменяемости кода . Программное обеспечение изобрели потому, что возникла необходимость легко и быстро вносить изменения в функциональность техники . Если мы хотим, чтобы функционал изменялся только на аппаратном уровне, то пользуемся понятием
«аппаратное обеспечение» .
Разработчики беспрерывно сетуют на то, что требования к продук- ту изменяются . Мне часто доводилось слышать заявления вроде:
«Это изменение полностью рушит архитектуру нашей програм- мы» . Солнышко, у меня для тебя плохие новости . Если изменение требований ломает архитектуру твоей программы, то твоей архи- тектурой можно только подтереться .
Мы, разработчики, должны радоваться изменениям, потому что ради них и работаем .
Изменение требований — основное правило игры . Эти изменения дают нам работу и кормят нас . Наша работа заключается в способ- ности мириться с изменениями требований и находить решения, которые будут относительно недороги .
Эффективность программного обеспечения измеряется в том числе и тем, насколько безболезненно в него можно внести какие-либо изменения . Клиенты, пользователи и руководители ожидают, что программное обеспечение будет можно легко изменить и что сто- имость таких изменений будет соизмеримой и как можно ниже .
Далее вы узнаете о том, как методы Agile, разработка через тести- рование, рефакторинг и простота проектирования при одновремен-
1 2 3 4 5 6 7 8 9 ... 20
Глава 2. Почему же Agile?
90
ном применении и с наименьшими усилиями помогают вносить изменения в программы без ущерба для них .
Постоянное совершенствование
Со временем люди повышают уровень своего мастерства . Ху- дожники лучше пишут картины, певцы лучше исполняют песни, строители лучше возводят здания и так далее . То же должно быть справедливым и для отрасли разработки программного обеспече- ния . Чем дольше существует программа, тем лучше она должна становиться .
Структура и архитектура программного обеспечения со временем должны становиться только лучше .
Структура кода должна становиться лучше и, соответственно, должно произойти улучшение производительности программы .
Разве это не очевидно? Разве это не то, что вы ожидаете от коман- ды, работающей над чем-либо?
То, что мы с течением времени работаем все хуже — самое серьез- ное обвинение и наиболее очевидное свидетельство нашей неком- петентности .
Самое безответственное отношение, которое только может быть, пожалуй, проявляется в случае, когда разработчики настроены на то, что по мере продвижения код будет становиться беспо- рядочным, а программа — неработоспособной, нестабильной и уязвимой .
Постоянное и уверенное совершенствование — вот чего от нас ждут клиенты, пользователи и руководители . Они ожидают, что «дет- ские болезни» программы со временем пройдут, что в дальнейшем
Разумные ожидания
91
она будет становиться только лучше . Методы Agile, а именно раз- работка через тестирование, парное программирование, рефакто- ринг и простота структуры проекта, призваны укрепить здоровые ожидания .
Компетенция без страха и упрека
По какой причине большая часть программ со временем не стано- вится лучше? Эта причина — страх . Если быть точнее, страх перед изменениями .
Представьте, что вы смотрите на экран, на котором находится на- писанный ранее код . Первая мысль, которая приходит в голову:
«Господи, какой ужас! Нужно почистить его» . Но следующая мысль будет примерно такой: «Нет, я в это не полезу!» А почему?
Да потому что вы думаете, что если влезть в код, то он перестанет работать . А если он перестанет работать, виноваты будете вы . Так вы отказываетесь от того единственного, что может улучшить код, — от его очистки .
В вас говорит страх . Вы боитесь кода, и этот страх вынуждает вас вести себя некомпетентно . Вы чувствуете некомпетентность и бои- тесь проводить очистку кода, потому что исход непредсказуем . Вы позволили коду, который создали своими собственными руками, стать таким самостоятельным, что боитесь что-либо делать для его улучшения . Это в высшей мере безответственно .
Клиенты, пользователи и менеджеры ожидают, что вы профессио- нал без страха и упрека . Они ожидают, что если в коде будут ошиб- ки или избыточность, вы это увидите, исправите и вычистите . Вы не допустите разрастания и усугубления несовершенств и сделаете все возможное для поддержания высокого качества и чистоты кода .
Глава 2. Почему же Agile?
92
Так как же избавиться от этого страха? Представьте, что у вас есть кнопка, а возле нее две лампочки — красная и зеленая . Представь- те, что когда вы нажимаете на кнопку, то загорается одна из них .
Зеленая — если программа работает правильно, красная — если неправильно . Представьте, что нажатие на кнопку и получение результата занимает лишь считаные секунды . Насколько часто вы будете на нее нажимать? Вы будете нажимать на нее без останов- ки . Вы будете нажимать на нее постоянно . Каждый раз, когда вы внесете изменения в код, вы нажмете на кнопку, чтобы понять, все ли работает правильно .
Теперь представьте, что на экране вы видите уродливый код . Пер- вая мысль, которая проносится у вас в голове: «Надо его почи- стить» . И после этого вы просто берете и чистите его, нажимая кнопку после каждого внесенного изменения, чтобы удостоверить- ся в том, что все работает .
Больше нет никакого страха . Вы спокойно чистите код . Чтобы устранить недостатки кода, можно использовать методы Agile: рефакторинг, простоту структуры проекта и парное программи- рование .
Где взять эту кнопку? Разработка через тестирование дает вам ту самую кнопку . Если вы применяете этот метод дисциплини- рованно и решительно, то достигнете компетенции без страха и упрека .
Контроль качества
Контроль качества должен показать, что неполадок нет . Продукт должен быть сделан так, чтобы после прохождения тестирования специалист сообщил, что все работает должным образом . Каждый
Разумные ожидания
93
раз, когда при прохождении контроля качества обнаруживаются какие-то ошибки, разработчики должны выяснить, что пошло не так во время работы, и устранить недостатки, чтобы в следующий раз такого не было .
Специалисты по контролю качества (Quality Assurance) должны задаться вопросом, почему они застряли в конце системы проверки процесса, которая всегда работает . Так что пусть проверяют кого- нибудь другого, для этого есть более достойные кандидаты .
Методы Agile, а именно приемочное тестирование, разработка че- рез тестирование, непрерывная интеграция, позволят не бояться контроля качества .
Автоматизация тестирования
На рис . 2 .1 можно увидеть руки . Это руки руководителя QA- отдела . В них он держит оглавление плана для тестирования, про- водимого вручную . В нем содержится 80 тысяч тестов, которые должна проводить армия индусов раз в полгода . Чтобы провести это тестирование, нужно потратить миллион долларов .
QA-менеджер принес мне этот документ, когда вышел от своего начальника . Его начальник, в свою очередь, до этого был в каби- нете финансового директора . Это был 2008 год . Начало мирового финансового кризиса . Финансовый директор каждые полгода сокращал этот миллион вдвое . Руководитель отдела контроля ка- чества, протягивая мне план, попросил отобрать из списка тестов половину, которую можно не проводить .
Я объяснил ему, что неважно, какие тесты будут проводить, а какие нет . Важно то, что мы так не узнаем, работает ли половина про- грамм .