Модернизация на стар софтуер без пълно пренаписване

Почти всеки утвърден бизнес има такъв: парче софтуер, което всички тихо мразят. Бавно е, грозно е, половината екип знае заобиколен начин за бъга, който никой така и не поправи, а единственият човек, който го разбираше, напусна през 2019 г. Инстинктът винаги е един и същ — да го изгорим и да построим нов. И точно този инстинкт най-често е причината добри компании да загубят година и малко състояние за нищо.

Виждал съм голямото пренаписване да се проваля достатъчно често, за да имам рефлекс срещу него. Основател ми показва своята скрибуцаща система за поръчки или древния си инструмент за графици, въздъхва и казва някаква версия на „просто трябва да заменим цялото нещо“. И може би някой ден ще го направите. Но пълното пренаписване — изтръгваш старата система, изграждаш бляскава нова паралелно, превключваш — е един от най-рискованите ходове в целия софтуер. Скъпо е, отнема много повече от обещаното, а през цялото време работите на сляпо, надявайки се новото нещо да покрие всеки странен граничен случай, който старото тихо обработваше петнайсет години.

Добрата новина е, че рязкото пренаписване почти никога не е единствената опция и рядко е най-добрата. Има по-спокоен начин за модернизация — поетапен, обратим и щадящ бизнеса, който все още трябва да печели пари, докато работите. Това е ръководство за този начин: как да разберете какво наистина се нуждае от поправка, как да заместите болезнените части, без да сваляте цялата система, и как да познаете кога пълното пренаписване наистина е правилният избор.

Защо рязкото пренаписване е толкова изкушаващо — и толкова опасно

Пълното пренаписване съблазнява, защото обещава чист лист. Никаква наследена бъркотия, никакви компромиси, свежа кодова база, изградена правилно с модерни инструменти. На бялата дъска изглежда очевидно. В действителност се записвате да изградите наново години натрупана бизнес логика — голяма част недокументирана, някоя живееща само в главите на хора, които вече ги няма — докато часовникът тиктака и сметките пристигат.

По-дълбокият капан е проблемът на паралелната вселена. През месеците или годините, които отнема изграждането на заместника, имате две системи: старата, която все още трябва да движи бизнеса, и новата, която още не е готова. Всяка промяна, от която бизнесът се нуждае, трябва да се прави два пъти, иначе новата система изостава от реалността още преди да стартира. Екипите изгарят, поддържайки и двете живи. И понеже на никого не е позволено да превключи, докато новата система не прави всичко, няма ранна победа, няма обратна връзка, няма доказателство, че работи — само дълго, тревожно чакане за един огромен ден на старт по принципа „всичко или нищо“.

Тук има добре позната индустриална мъдрост и тя е заслужена: втората система, голямото пренаписване, има навика да отнема три пъти повече от очакваното и да пристига с по-малко функции от това, което замества. Оценката не е грешна, защото хората са нехайни. Грешна е, защото в началото никой не може да види всички дребни неща, които старата система тихо прави правилно.

Какво всъщност означава „наследен“ (не става дума за възраст)

Хвърляме думата наследен, сякаш означава просто стар. Не е така. Много софтуер, който работи от десетилетие, е напълно наред — скучен, стабилен, платен, върши си работата. Само възрастта не е причина да докосвате каквото и да било. Най-скъпата грешка в цялата тази област е да модернизирате нещо, което тихо е работело, само защото е изглеждало остаряло.

Софтуерът заслужава етикета наследен, когато активно ви пречи. Когато не можете безопасно да го промените, защото никой не го разбира напълно. Когато не може да се свърже с инструментите, от които вече зависите. Когато един-единствен човек е единственият, който може да го поддържа жив. Когато е толкова бавен или крехък, че екипът ви е изградил цял фолклор от заобиколни решения около него. Това е истинското определение — не годината, в която е написан, а цената, която ви налага днес, и риска, който носи към утре.

Диагностицирайте, преди да докоснете каквото и да било

Преди да се пренапише и един ред, ви трябва честна карта на това къде наистина живее болката. През повечето време системата, която всички мразят, е 80% наред. Проблемът е концентриран на няколко конкретни места — един бавен екран, една счупена интеграция, един работен процес, който налага двойно въвеждане на данни — и тези няколко места генерират почти всички оплаквания. Намерете ги и сте намерили целия си проект.

Начинът да ги намерите не е първо технически одит — а разговор. Седнете с хората, които използват нещото всеки ден, и ги попитайте къде боли. Къде чакат? Какво пренаписват? Какво избягват, защото е мъчително? Къде държат частна таблица, за да заобиколят официалната система? Тези заобиколни решения са злато: всяко от тях е точна рентгенова снимка на проблем, който си струва да се поправи.

• Екраните и стъпките, от които хората се оплакват най-много — не на теория, а в реалната им ежедневна работа.
• Всяко място, където данните се въвеждат два пъти, защото две системи не си говорят.
• Интеграциите, които се счупиха или никога не са съществували, налагайки ръчно копиране между инструментите.
• Всичко, което само един човек знае как да оперира или поправя — вашите единични точки на отказ.
• Частите, които наистина са наред, за да ги защитите и оставите на мира.
• От какво ще се нуждае бизнесът догодина, в което текущата система просто не може да порасне.

Когато правите това честно, проектът обикновено се смалява. Собственикът, който е влязъл с думите „заменете всичко“, излиза, осъзнавайки, че трябва да поправи три неща. Това не е разочарование — облекчение е. Три поправими неща са проект, който можете да завършите това тримесечие. Пълната замяна е година, която може и да не преживеете.

Strangler подходът: заменяйте я парче по парче

Има модел за безопасното правене на това и той има леко мрачно, но запомнящо се име: strangler подходът, по името на удушаващата смокиня — лиана, която расте около дърво и постепенно превзема структурата му, докато накрая новият растеж застава самостоятелно, а старият ствол го няма. Приложена към софтуера, идеята е красиво практична: не заменяте старата система с една героична подмяна. Отглеждате новата около нея, парче по парче, докато не остане нищо от старата, от което някой да се нуждае.

На практика работи така. Избирате едно болезнено парче — да речем, модула за фактуриране, който всички мразят. Изграждате модерен заместник само за това парче. Насочвате фактурирането към новия модул, докато всичко останало продължава да работи на старата система, недокосната. Наблюдавате го известно време. Когато е стабилно, тази част от старата система утихва и преминавате към следващото парче. Старата система се смалява постепенно, като свещ, вместо да бъде съборена наведнъж.

Това, което прави този подход толкова по-безопасен от пренаписването, е, че всяка стъпка е малка, жива и обратима. Никога не работите на сляпо. Всяко ново парче бързо влиза в реална употреба, така че бързо разбирате дали наистина работи. Ако нещо се обърка, рискували сте само един модул, а не целия бизнес — и обикновено можете да се върнете на стария път, докато го поправяте. Получавате победи по пътя вместо един ужасяващ старт накрая. А бизнесът продължава да работи, нормално, през цялото време.

Как всъщност изглежда ритъмът

1. 1
   Изберете най-болезненото, най-самостоятелно парче

   Искате силна болка и чисти граници — модул, който боли много и няма пръсти навсякъде другаде. Това е първата ви цел.
2. 2
   Поставете тънък слой пред старата система

   Малък маршрутизиращ слой решава кои заявки отиват към старата система и кои към новото парче. Това е шевът, който прави всичко останало възможно.
3. 3
   Изградете и пуснете само това едно парче

   Заменете един модул, дайте го в реални ръце и насочете към него само този дял от работата. Седмици, не години — а останалата част от системата не е помръднала.
4. 4
   Стабилизирайте, после преминете към следващото парче

   Щом на новия модул се вярва, съответната част от старата система заспива. Повторете със следващото болезнено парче, учейки се в движение.
5. 5
   Изведете старата система от употреба, когато е празна

   В крайна сметка наследената система не прави нищо, на което някой да разчита. Едва тогава я изключвате — тихо, без драма, защото всичко важно вече се е преместило.

Забележете кое е различното спрямо пренаписването: няма един-единствен ден на старт, от който да се страхувате. Няма паралелна вселена за поддръжка. Новата система е в продукция от третата седмица, изкарва си хляба и ви учи на неща, вместо да чака в лаборатория за старт, който все се отлага.

Понякога изобщо не е нужно да я заменяте

Преди да заменяте каквото и да било, си струва да попитате дали старата система се нуждае от замяна, или просто трябва да спре да бъде остров. Изненадващо много проблеми от типа „трябва ни нова система“ всъщност са проблеми „системите ни не си говорят“. Старият софтуер си върши работата добре — той просто седи в силоз, принуждавайки хората да пренасят данни навътре и навън на ръка.

В тези случаи най-евтината, най-бързата поправка не е нова система. Тя е мост. Обвивате стария софтуер с връзка — интеграция, която му позволява автоматично да обменя данни с другите ви инструменти — и модерен слой отгоре за частите, които хората наистина докосват. Остарелият двигател продължава да бръмчи отдолу; екипът получава чиста повърхност и край на копирането. Не е бляскаво, но често е най-високата възвръщаемост на евро в цялото начинание.

Кога пълното пренаписване наистина е правилният избор

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

Честните знаци са конкретни. Технологията, върху която е изградена системата, е мъртва или умираща — няма поддръжка, няма ъпдейти за сигурност, не е останал никой, който може да работи по нея. Бизнесът се е променил толкова фундаментално, че старият модел вече изобщо не отговаря на реалността. Или системата е толкова заплетена, че дори малки промени редовно чупят неща на несвързани места, което обикновено означава, че изобщо няма чисти шевове, за да се приложи strangler подход. Когато две или три от тези са верни едновременно, поетапната работа спира да бъде по-безопасният избор.

И ето я тихата награда от това да свършите поетапната работа първо, дори ако в крайна сметка изградите наново: докато стигнете дотам, ще разбирате системата далеч по-добре, отколкото в началото. Всеки модул, който сте заменили, ви е научил на нещо, което оригиналните автори никога не са записали. Пренаписване, информирано от това знание, е напълно различно, далеч по-безопасно животно от онова, стартирано на оптимизма от първия ден.

Частта, която никой не споменава: всичко е най-вече за хората

Ето нещо, което техническите ръководства пропускат. Най-трудната част от модернизацията на стар софтуер обикновено не е кодът — а хората, които години наред са се адаптирали към него. Знаят му странностите. Имат мускулна памет за чудатите му преки пътища. Нов модул, който е обективно по-добър, пак може да се усеща по-зле през първите две седмици, просто защото е непознат. Ако пренебрегнете това, дори перфектна техническа миграция може да се провали.

Поетапният подход помага и тук, почти случайно. Понеже промяната пристига по малко парче наведнъж, хората я попиват постепенно, вместо да бъдат помолени да преучат всичко в един понеделник сутрин. Въведете ежедневните потребители рано. Оставете ги да оформят заместника, преди да е завършен. Екипът, който е помогнал да се проектира новият екран за фактуриране, ще го отстоява; екипът, на когото е стоварен, ще го мрази, дори ако е идентичен. Модернизацията е проект за управление на промяната, преоблечен в софтуерен костюм.

Чести въпроси