Как да завладеем наследствен код

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

Аз бях в тази ситуация много пъти през последните две десетилетия. Мога да помогна.

Как да разбера наследствен код

Ако имате късмет, ще имате документация или поне вътрешни коментари. Може би един или двама от първоначалните автори все още ще са наоколо, за да помогнат. Но през повечето време няма да имате толкова късмет.

Нека да поговорим за това, което ще правите в тези нещастни случаи.

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

Лесно е да погледнете работата, която идва пред вас и да решите, че не е добре и че можете да се справите по-добре. Това е погрешно отношение. Това ще ви отведе по много опасна пътека.

Ако тръгнете по този опасен път, ще започнете да правите промени, преди да разберете правилно въздействието на тези промени. Ще „поправите“ неща, които не са счупени, защото са написани в стил, който не ви харесва, или се основават на по-стар начин на правене. В крайна сметка ще загубите невероятно много време с това отношение.

Затова спрете. Направете крачка назад и осъзнайте, че всичко в тази кодова база е направено по определен начин с причина.

Докато не знаете кода напред и назад, трябва да приемете, че е имало основателни причини той да бъде написан такъв, какъвто е, и че просто още не сте ги измислили.

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

Не правете глухо Dumpty вашата кодова база.

„Да, така че„ бързото коригиране “към наследения код всъщност разби всичко и не съм сигурен защо. Ciao!

Най-добрият начин, който открих да науча кодова база, е да стартирам на ниво потребителски интерфейс, след което да върна обратно в кода.

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

Докато продължавате, начертайте диаграма на последователността, за да илюстрирате какво се случва. Ако не сте сигурни какво представлява диаграмата на последователността или как да я нарисувате, проверете този безплатен урок. Ако нямате добър инструмент за рисуване на UML, ето безплатен.

Примерна схема на UML последователност
източник: UML 2 последователни диаграми: пъргаво въведение

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

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

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

Като цяло, най-важното е да бъдете търпеливи и да избягвате да се биете. Кодът е сложно нещо. Разбирането на наследения код отнема време. Запази спокойствие.

Как да поправим наследения код

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

Това ви дава люк за бягство. По-лош сценарий, ако се изтеглите, за да адресирате някакъв друг приоритет - или ако сте в кратък срок - поне ще съберете някакъв работен код, на който можете да се върнете.

След като започнете да работите с кода си, ако все още имате време, можете да започнете да правите малки, постепенни подобрения.

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

Понякога ще срещнете грешка, която всъщност е резултат от структурен дефект. Тези грешки не могат да бъдат коригирани с обикновена промяна в някаква условна логика. Те изискват по-инвазивни промени.

Ето тук нещата стават косми. Трябва да бъдете брутално откровени със себе си относно това каква е минималната жизнеспособна промяна. Всяко влакно на вашето същество ще иска да раздърпа кода и да напише цялото нещо. Не го правете!

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

За да накарате този подход да работи наистина, уверете се, че винаги подплащате прогнозите си, за да имате време за малко рефакторинг.

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

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

Подгответе се да заявите своя случай в бизнес отношение. Какво ще струва да се извърши значително преструктуриране на кода? Какви са реалните рискове за бизнеса, ако не го направите? Ако имате солиден случай, в крайна сметка ще бъдете изслушани. Не се учудвайте, ако първо са необходими няколко цикъла на кръпка.

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

Как да добавите нови функции към наследения код

Накрая ще бъдете призвани да добавите функции към наследения код. На този етап трябва да вземете важно решение. „Отивате ли с потока“ на текущата кодова база или поемате нещата в нова посока?

Отново ви съветвам да бъдете брутално честни в оценката си. Продължаването на следването на моделите и практиките, очевидни в съществуващата кодова база, ще го влоши или ще се натрупа върху съществуващ проблем?

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

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

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

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

Не този тип адаптер (това няма да работи, в случай че се чудите)

DO Factory има добро обяснение на адаптерния модел:

„Моделът адаптер превежда един интерфейс (свойства и методи на обекта) в друг. Адаптерите позволяват на програмните компоненти да работят заедно, което в противен случай не би било поради несъответстващи интерфейси. Моделът на адаптера също се нарича модел на опаковката.
Един от сценариите, при които често се използват адаптери, е когато новите компоненти трябва да бъдат интегрирани и да работят заедно със съществуващите компоненти в приложението.
Друг сценарий е рефакторинг, при който части от програмата са пренаписани с подобрен интерфейс, но старият код все още очаква оригиналния интерфейс. "

Ето някои връзки към обяснения и примери на различни езици.

  • Пример на JavaScript на модел адаптер
  • C # пример за модел на адаптера
  • Пример за Java на адаптерния модел

Ключови заведения

В обобщение, тук са основните моменти, които ще ви помогнат да се справите и в крайна сметка да завладеете всяка кодова база:

  1. Никога не съдете за наследения код или го променяйте, докато не отделите време да го разберете напълно.
  2. Диаграмите за последователност са ваш приятел.
  3. Предпочитайте малки, постепенни подобрения спрямо презаписване на едро или промени.
  4. Всяка промяна трябва да се опита да остави кода малко по-добър, отколкото беше, когато го намерихте.
  5. Ако трябва да направите големи промени, направете бизнес случай и първо получете одобрение.
  6. Когато добавяте нови функции, опитайте да „вървите с потока“.
  7. Ако трябва да вземете кода в нова посока, изолирайте промените и използвайте адаптерния модел за интегриране.

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

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