Унаследованный код

Сегодня я размещаю перевод статьи, над которым мы работали вместе с Артемом Кротовым по очень важной теме в разработке программного обеспечения — теме унаследованного (legacy) кода. Это глава из «белой» книги Крейга Лармана и Баса Водди Practices for Scaling Lean & Agile Development, перевод размещён с разрешения авторов.

Текст который вы найдете ниже в посте написан 10 лет назад, и на мой взгляд, со временем актуальность материала только увеличивается.

Я не хочу достичь бессмертия при помощи своих трудов, я просто не буду умирать. — Вуди Аллен

Если вы работаете в большой продуктовой группе, то скорее всего во время прочтения статей на сайте less.works вы, вероятно, думали: “Этот ресурс содержит столько полезных идей, но у нас пять миллионов строк кода, написанных на нашем собственном языке программирования, которые нам нужно поддерживать. У нас это не сработает”. Тогда эта статья как раз для вас.

Существующий хорошо структурированный переиспользуемый код безусловно является ценным активом. Тем не менее, со временем этот актив может превратиться в унаследованный код (legacy code) — код с плохой структурой, без автотестов, с неактуальной документацией и большим количеством дублирований. Унаследованный код ограничивает организационную гибкость, и как мы увидим, ведёт к серьёзному ослаблению вашей конкуретной способности. Эта статья о том, как возникает такой унаследованный код, и том как этого избегать.

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

С другой стороны, что бы произошло, если бы всю эту энергию направили на творческие, инновационные продукты? Кроме того, унаследованный код разрушал компании…

Рис. 1. Доля рынка браузеров и их версии

Браузер Netscape — один из лучших примеров, который по началу владел рынком. Но в 1995 году компания Microsoft осознала громадный потенциал сети Интернет и начала то, что в последствии назовут “войнами браузеров“ [см. книгу Competing On Internet Time]. В 2000 году она выиграла первую битву этой войны.

Это произошло по ряду причин. Одна из них в том, что Netscape не выпускала новую версию своего браузера три с половиной года. Но почему? “Потому что браузер был переписан заново без использования прежней кодовой базы Netscape Communicator”. В 2007 году компания AOL, (которая купила Netscape в 1999 году) официально убила браузер Netscape.

Это статья решит все ваши проблемы с унаследованным кодом… ладно, может и нет. Но она определённо притупит вашу боль от унаследованного кода и возможно когда-то, вы сможете полностью от него избавиться.

Как Писать Новый Унаследованный Код

Писать унаследованный код просто — мы объясним при помощи нескольких простых шагов. За десятки лет компании создали кучу унаследованного кода. В компании Xerox мы однажды услышали: “Нам преподали много уроков, но выучили мы лишь часть”. Это особенно касается унаследованного кода. Мы из раза в раз проходим этот урок, но почему-то так и не можем его выучить.

Как давно это началось? Ещё в 1967 году, возможно, в первой книге по управлению проектами разработки Чарльз Лехт (Charles Lecht) писал:

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

Ниже указаны явные причины появления унаследованного кода:

нереалистичные сроки и фиксированный объём работ
низкие навыки разработки

И конечно в этих причинах лежат ключи к предотвращению его возникновения…

Как Избежать Написания Унаследованного Кода

Избегайте нереалистичных сроков и фиксированного объёма работ

“Мы обещали этот релиз нашему основному заказчику к первому февраля, и отдел разработки должен сдержать это обещание” — было написано в недовольном письме директора менеджменту продуктовой группы, которую мы консультировали. Мы недоуменно прочитали это письмо и задались вопросом о “сдержать это обещание”. Решили не обращать пока на него особого внимания и вернуться к обычной работе — обучению одного из разработчиков рефакторингу унаследованного компонента, который был сляпан на скорую во время последнего релиза, чтобы успеть в срок.

Многие компании застряли в порочном круге навязанных обещаний и невыполнимых обязательств. Сегодня, в эру высоких скоростей, клиенты ‘принуждают’ компании-разработчиков обещать слишком многое. “Если вы не можете поставить к концу года, мы купим у вашего конкурента, который даст такое обещание”. Отдел продаж или руководство могли бы отреагировать, проявив прозрачность и стремясь к взаимовыгодным долгосрочным отношениям (сотрудничество с заказчиком), но вместо этого они озадачены, прописана ли неустойка в договоре за несоблюдение приемлемых сроков (согласование условий контракта), и отвечают: “Да, без проблем, мы это сделаем!”. После этого тот же цикл начинается уже внутри организации. Руководство приказывает главе разработки “сделать это” или “сделать так, чтобы это случилось”, потому что “это обещано клиентам”. Обещание путешествует по организационной структуре к разработчикам, которые не могут передать его дальше.

Как разработчик обычно реагирует? Чарльз Лехт уже нас предупреждал более 50 лет назад: Разработчик будет “обязан согласиться из уважения, страха или ложной лояльности” и неохотно, но соглашается на эти сроки. Разработчик открывает свой секретный ящик с инструментами и делает всё возможное, чтобы успеть к ближайшему сроку, используя инструменты, такие, как хардкод, копипаст-программирование, игнорирование тестов, сверхурочные и другие, разрушающие качество и срезающие углы практики см. книгу The Enterprise and Scrum. Никто не обращает внимание на использование этих ‘инструментов’, поэтому что сроки соблюдены. Менеджмент награждает разработчиков за их тяжёлый труд и восхваляет их за “отличную командную работу” и “боевой дух”.

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

Рис. 2. Динамика нереалистичных сроков

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

Мартин частично прав. Но этот взгляд игнорирует тот факт, что разработчик является частью бóльшей системы, которая усиливает это поведение. Нужно, не только развивать мастерство разработчиков, но и улучшать систему, в которой они работают, в целом.

Однажды в Европе мы посетили директора большой продуктовой группы (которая разрабатывала встраиваемые системы) и его команду менеджеров. Директор объяснил, что группа успешно выпустила последний релиз, и поставил под сомнение необходимость внедрения масштабируемого Скрама. В этот момент один из его подчинённых сказал: “Ну, на самом деле ближе к дате релиза мы сильно отставали, поэтому мы много работали сверхурочно, выдернули более сотни человек из другого продукта нам в помощь. Поэтому мы и успели. Сейчас мы серьёзно отстаём от графика, потому что в последнем релизе было создано так много плохого кода, что мы тратим бóльшую часть времени на исправление дефектов, о которых сообщают нам наши клиенты, и вынуждены работать с беспорядком в кодовой базе”.

Обратите внимание на взаимосвязь между этими событиями и отсутствием бережливого мышления. Например, в этих случаях прослеживается утрата связи с реальностью (waste of wishful thinking). Один из трёх источников потерь в бережливом мышлении — перегрузка (overburden) — часто можно увидеть, как героический рывок ближе к концу релиза приводит к ещё большим потерям в будущем. Также отсутствует культура остановись и исправь (stop and fix) — а наблюдается противоположная ей “нет времени точить, нужно пилить” (carry on and don’t fix).

Если вы скажите своим клиентам: “Мы не понимаем, что происходит, и понятия не имеем, когда это будет сделано”, то это будет коммерческим самоубийством. Мы часто слышим от руководителей фразу: “Либо мы берём на себя нереалистичные обязательства, либо у нас не будет работы”. Это убеждение является ложной дихотомией.

Есть другой способ, когда клиент и заказчик вместе понимают суть продуктовой разработки: она не предсказуема на 95%. Вы можете принять эту реальность, если будете демонстрировать прозрачность по отношению к своим клиентам во время разработки. Например, …

предоставляя информацию о текущем статусе разработки вашим ключевым клиентам каждую итерацию; например, с помощью Диаграммы Сгорания Релиза (Release Burndown Chart) и актуального Бэклога Продукта
давая возможность ключевым клиентам предоставлять обратную связь по приоритетам и изменению целей по мере того, как они видят, как идут дела, а затем корректируя план соответствующим образом
предоставляя оценки с указанием их точности (вероятности) или несколько оценок (по разным сценариям) см. книгу Вальсируя с Медведями
используя другие техники, которые поощряет частое взаимодействие с клиентами, основанные на реальности и прозрачности

Часто менеджмент прибегает к “быстрому решению” (quick-fix) в ответ на давление рынка — ‘заказать’ разработке “ещё ресурсов”, так как это ‘дёшево’. Мы работали с продуктовой группой, которую принудили нанять сотни людей в течение года. Исключение? Нет, вот ещё пример: лидер продуктовой группы, с которой мы работали, недавно был ‘назначен‘ руководить новым продуктом. В этом продукте работало 900 человек в 12 разных офисах и 20 активных филиалах. Этот продукт отставал от конкурентов, и предыдущее руководство пыталось спасти его, добавляя больше людей — теперь они отставали ещё больше.

Вот ещё урок, который преподаётся снова и снова. Возможно, первым крупномасштабным проектом в мире была SAGE система, которая разрабатывалась в 1950-х. Команда проекта торопилась, поэтому…

В течение года примерно 1000 человек были вовлечены в разработку системы SAGE. Люди из самых разных слоёв общества были наняты и обучены. Проводники трамвая, сотрудники похоронного бюро (изучавших математику не менее года), школьные учителя, мойщики окон и другие в спешном порядке были собраны, обучены программированию в течение нескольких недель и распределены по разным отделам очень большой организации… Изначально ожидаемый объем работ был значительно уменьшен. Первый релиз состоялся с опозданием на год и значительно превысил бюджет¹.

Вместо воспитания великих разработчиков или найма небольшого количества крутых людей они сконцентрировались на найме максимального количества “голов” (англ. heads, head count) что, в свою очередь, привело к поспешной и неполноценной образовательной программе для новых сотрудников. Это быстрое решение приводит в целом к низкому уровню навыков разработки в командах, снижает вероятность стать хорошими разработчиками и, в конечном итоге, к значительному увеличению количества плохого унаследованного кода.

Низкие Навыки Разработки

Системная динамика обещаний и обязательств полностью не описывает историю об унаследованном коде. Боб Мартин прав — индустрии определённо точно нужны хорошие инженеры.

В целом по нашим наблюдениям уровень навыков разработчиков в больших продуктовых группах довольно низкий. Разработчики часто не знакомы с хорошими базовыми техниками — простыми практиками, такими как сокрытие(information hiding) и инкапсуляция, или принципами хорошего дизайна. От разработчиков встраиваемых систем мы иногда слышим восклицания: “Это техники для ООП, а мы пишем на языке Си”. Но они не понимают, что некоторые из этих идей были изначально разработаны не для объектно-ориентированных технологий². Мы наблюдали следующую зависимость:

Но эти практики являются основой для бесконечно повторяемого процесса разработки. К счастью, навыки разработки зависят не только от чистого таланта; они могут быть изучены и развиты:

в школах
при поддержке организаций
путём самообучения

Лидеры продуктовой группы могут думать, что понимают, как работают образовательные программы, но это может быть не так…

Школы — В университетах не преподают базовых навыков разработки. Есть шокирующий разрыв между академическим образованием и коммерческой разработкой. Многие преподаватели никогда не работали разработчиками и не видели долгосрочную динамику развития навыков разработки и унаследованного кода. Им также не хватает практики Go See. Некоторые университеты недавно добавили практики Agile-разработки в их учебную программу по информатике. Это хорошо. Однако требуется глубокий опыт, чтобы действительно понять Agile-практики такие, как разработка через тестирование (TDD), а преподаватели редко имеют такой опыт.

Поэтому, не ожидайте от выпускников университетов, что они будут иметь хорошие навыки, особенно в Agile-разработке.

Поддержка в организации — Многие компании не считают должным обучать разработчиков. Мы часто слышим: “Любой выпускник университета может писать код”, тем самым подразумевая, что уже не требуется обучение базовым навыкам разработки. Наш опыт в консалтинге говорит об обратном. Многим разработчикам в больших продуктовых группах не хватает фундаментальных навыков, таких как: навыки дизайна программного обеспечения, эффективная работа с редакторами, эффективное использование основного языка программирования или автоматизация задач путём написания скриптов. Организации не уделяют вниманию обучению в этих областях, потому что многие бизнес-лидеры логично, но ошибочно предполагают, что люди приобрели эти навыки в университете, не понимая, что учебная программа по информатике не учит навыкам разработки программного обеспечения, и что большинство университетских профессоров не знают и не могут преподавать современные практики разработки³.

В отличие от них бережливые (lean) организации инвестируют в обучение своих сотрудников. Одно из исследований показывает, что японские компании тратят в восемь раз больше средств на обучение новых сотрудников, чем в США, и в два раза больше, чем их европейские конкуренты [см. книгу The Machine That Changed the World].

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

Самообучение — Многие разработчики не следят за развитием своих навыков. Гуру по качеству программного обеспечения Филип Кросби (Philip Crosby) назвал недостаток знаний, вызванный нехваткой обучения, главной причиной плохого качества.

Люди подсознательно тормозят собственное развитие. Они начинают полагаться на клише и привычки. Когда они достигают определённого уровня личного комфорта, они перестают учиться, и их ум остаётся бездействующим до конца своих дней. Они могут подниматься по карьерной лестнице, могут быть амбициозными, напористыми и даже работать с утра до ночи. Но они больше ничему не научатся. Филип Кросби (Philip Crosby) Quality Is Free, 1980.

В 1999 году Дейв Томас (Dave Thomas) и Энди Хант (Andy Hunt) опубликовали превосходную книгу Программист-прагматик. Путь от подмастерья к мастеру, в которой они делают выводы по мировоззрению и поведению современного профессионального разработчика. Мы призываем людей прочитать её и взять на себя ответственность за собственное развитие.

Избегайте тривилизации разработки

“Я архитектор, написание кода — этой низкоквалифицированной работой должны заниматься другие люди”. Мы слышим подобные заявления от архитекторов из “башни из слоновой кости”, которые считают, что программирование ниже их уровня. Организация, в которой работают такие архитекторы, создала культуру тривилизации (упрощение, признание обыденным, англ. trivializing) программирования. Такая культура принижает значение кода, обесценивает написание чистого кода и познание навыков программирования. В такой культуре люди хотят подняться по социальной и организационной лестнице — а это означает отход от программирования. Программирование является всего лишь ранним этапом карьеры, который им предстоит пройти. Такая культура поощряет распространение унаследованного кода.

Организации тривилизируют разработку при помощи:

аутсорсинга разработки
карьерного роста
разницы в зарплатах

Аутсорсинг разработки — Особенно в больших продуктовых группах мы сталкиваемся с компаниями, которые не считают написание кода своим “основным бизнесом”, и поэтому передали его на аутсорсинг. Они составляют спецификации, архитектурную и проектную документацию, а затем отправляют их дешёвым разработчикам в оффшор, чтобы “выполнить разработку и тестирование.” Рецепт катастрофы. Исходный код — это место создания реальной ценности — гемба. Подробнее смотрите:

Карьерный рост — Крупные организации хотят обеспечить будущее для своих сотрудников; типичное решение — это установленные карьерные пути для менеджеров и инженеров. Люди, переходящие на путь менеджмента, уходят от технической работы и становятся “профессиональными менеджерами”. Те, кто идёт по техническому пути, тратят своё время на написание “архитектурных документов”. Какой бы карьерный путь вы ни выбрали, в нем не будет программирования.

Разница в зарплатах — Из всех профессий, связанных с разработкой программного обеспечения, зарплата программистов в среднем одна из самых низких (см. книгу Applied Software Measurement). Естественно, и к сожалению, эта разница в заработной плате не способствует тому, чтобы стать лучшим разработчиком, а вместо этого способствует прекращению работы в в этом качестве. Есть ли альтернатива? Пит МакБрин (Pete McBreen) продвигает модель мастерства в области программного обеспечения, в которой зарплата напрямую связана с навыками. Навыки разработчиков оцениваются по портфолио и отзывами коллег.

Повышайте осведомлённость о негативном влиянии унаследованного кода

Накопление унаследованного кода — это не только помеха, это якорь. Трудно быстро поставить ценность и быстро адаптироваться, когда ваши 15 миллионов строк кода представляют собой дымящуюся кучу… ну, вы сами знаете чего.

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

Хорошо, у нас есть унаследованный код, что дальше?

Вы, вероятно, узнали причины появления унаследованного кода, и его у вас уже кучи. Как от него избавиться? В своей книге Эффективная работа с унаследованным кодом Майкл Физерс (Michael Feathers) рассказывает о конкретных техниках работы с кодом для его постепенного улучшения. В этой статье мы не будем повторяться, рекомендуем прочесть книгу Физерса. Однако мы рассмотрим некоторые общие стратегии работы с унаследованным кодом.

Не переписывайте унаследованный код

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

В продуктовой группе с 30-летней кодовой базой разработчик спросил нас, можем ли мы помочь в рефакторинге функции из 5000 строк. Мы думали, что он преувеличивает. Но когда мы сели в пару и посчитали количество строк функции, мы обнаружили, что она даже немного больше 5000. Как могла быть создана такая функция? Просыпается разработчик и думает: “Боже, какой сегодня чудесный день! Напишем-ка функцию из 5000 строк?”. Вероятно, что нет. Когда разработчик пишет новый код, он обычно пишет его с приличным качеством. Но со временем качество ухудшается. И функция вырастает до 5000 строк. Почему так происходит? Клиент запрашивает новую фичу, и она впихивается в существующий код из-за плохих навыков разработки или нереалистичных сроков. Качество кода снижается, а усилия, необходимые для внесения изменений, возрастают (см. рис. 3).

Рис. 3. Качество кода снижается со временем

Через какое-то время вносить изменения в код становится слишком болезненно и для этого требуется слишком много усилий; разработчики начинают просить его переписать. Сначала Владелец Продукта отказывается — переписывание означает высокие затраты без добавления новой ценности. Но по мере того, как скорость разработки падает, разработчики жалуются все больше, и в конечном итоге Владелец Продукта ‘соглашается’ переписать. В это время способность реагировать на изменения — новые требования — равна нулю. И после окончания переработки код получается более качественным, а значит, и новая разработка идёт быстрее (см. рис. 4).

Рис. 4. Переписывание улучшает качество

Что происходит после? Спешка при реализации новых требований приводит к “срезанию углов” только что вычищенного кода, что снова приводит к ухудшению качества и увеличению усилий по разработке (см. рис. 5). Через некоторое время разработчики требуют ещё раз всё переписать. В некоторых крупных продуктовых группах мы видели, как компоненты переписывались трижды.

Рис. 5. Качество кода снижается вновь после переписывания

Ключевая идея: Проблема не в наличии унаследованного коде, а в его создании.

Мысль в том, что нужно предотвращать создания нового унаследованного кода, а не бороться с ним самим. Фокус должен быть на выращивании здорового кода и не давать ему ухудшаться со временем. Но как? Улучшайте качество кода каждый раз, когда его меняете. “Если бы мы все оставляли после себя наш код немного чище, чем когда мы за него взялись, то код попросту не будет загнивать” — утверждает Боб Мартин

Рис. 6: Выращивание здорового кода

Улучшайте код по соседству

Выращивание здорового кода — ключевая стратегия устранения унаследованного кода. Вы можете следовать ей, улучшая код по соседству и постепенно устраняя “разбитые окна“. Каждый раз, когда вы вносите изменения, осматривайтесь вокруг места их внесения — на его соседей, код, который может быть улучшен, “разбитые окна”: добавьте пару тестов и проведите рефакторинг (см. рис. 7). Когда начнёте применять эту практику, каждое изменение будет происходить немного медленнее. Но со временем код улучшается, а скорость разработки увеличивается из-за более здорового кода.

Рис. 7: Улучшайте код по соседству

Унаследованный код означает наличие технического долга — а выплата долгов не бесплатна. Стратегия переписывания пытается погасить долг сразу. В свою очередь, улучшение кода по соседству распределяет выплаты во времени. Она направляет усилия на самые важные части, которые меняются чаще всего. Унаследованный код, который не меняется и не улучшается — и это нормально.

Пишите высокоуровневые и модульные тесты

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

Переписывайте мёртвый унаследованный код

Иногда невозможно постепенно провести оздоровление кодовой базы. Предположим, что часть низкоуровневого кода написана на PL/M (устаревший процедурный язык, прим. переводчика), и его никто не хочет изучать. Или часть вашего кода написана на доморощенном языке, компилятор которого работает только на VAX/VMS (проприетарная серверная операционная система, прим. переводчика). Когда постепенное изменение невозможно⁴ — то унаследованный код уже мёртв, т.е. необходимо ‘ампутировать‘ эту часть кода вместо того, чтобы позволить ей убить ваш продукт.⁵

При замене мёртвого кода:

покройте его тестами
не добавляйте функциональности в старый код
не добавляйте функциональности в заменённый код

Заключение

В мире существуют миллиарды строк унаследованного кода, и их количество увеличивается с каждым днём. Это уже создавало огромные проблемы в прошлом (например, Проблема 2000 года), и будет в будущем. Но унаследованный код не исчезнет, если не будут устранены первопричины:

нереалистичные сроки и фиксированный объём работ
низкие навыки разработки

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

“Создание вещей — это в первую очередь про создание людей” Summary Notes from Art Smalley Interview with Mr. Isao Kato, 2006.

Сноски

Cтатья Дж. Шварфца “Построение ПО: Проблемы и Практики” (J. Schwartz, Constructing of Software: Problems and Practices), позже опубликованная в книге), жирный шрифт добавлен.
Например, статья Д. Парнаса (D. Parnas) “On the Criteria To Be Used in Decomposing Systems into Modules”.
“Используйте редактор кода, к которому вы привыкли” — это, пожалуй, самый эффективный курс повышения производительности, который вы можете преподавать во многих компаниях.
Редко бывает невозможно сделать постепенное изменение. Поэтому бросайте вызов каждый раз, когда кто-то говорит, что постепенное изменение невозможно.
Статья Д. Парнаса (D. Parnas) “Software Aging, Proceedings of the 16th International Conference on Software Engineering”, также доступная в книге Software Fundamentals: Collected Papers by David L.Parnas.