Съвети за работа с наследствен код

Иконичният APPLE MACINTOSH 128K

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

Когато преди 5 месеца започнах да работя като софтуерен разработчик в компания, базирана на продукти, нямах представа какво е наследствен код или какво води до него.

По време на четвъртия ми месец бях помолен да добавя модален филтър за превключване към приложение, създадено от един от моите колеги преди две или три години. Изглеждаше достатъчно лесно; Прекарах по-голямата част от последните три години, като работя върху изключително сложно приложение, включващо стандартния стек: TypeScript / React / Angular / Dotnet. Вече бях решил много уникални проблеми и се почувствах уверен в кодиращата си способност достатъчно, за да направя прост модал за предаване на параметрите на заявката към бекенда.

Както може би се досещате, не беше почти толкова просто. Но защо?

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

Legacy код е код, наследен от друг разработчик или екип, който използва по-стари технологии, които вече не се поддържат или са заменени от по-нова версия. Много програмисти казват, че „кодът става наследствен код веднага щом е написан“. Функционалната разлика между "обикновен" код и наследствен код може просто да е, че той има различни конвенции в сравнение с това, с което сте свикнали да работите.

В моя случай приложението използваше XAML и T4 Text Template, а не основния C # код, и не беше толкова силно набрано, колкото бях свикнал. Това ми направи малко по-трудно разбирането на структурата на данните. Никакви типове не означаваха, че се сблъсквам с TypeErrors по време на изпълнение много по-често, което може да бъде трудно за отстраняване на грешки, когато пишете голяма функция. На всичкото отгоре приложението използва много по-стара версия на dotnet, която трябваше да се съгласува със съвместима версия на библиотеката на компонентите.

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

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

Как да се справим със съществуващия код на техническо ниво

Прочетете документацията и кодовите коментари, когато е възможно

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

Вижте кодовата база като цяло

Ако сте изгубени и не знаете откъде да започнете, задайте си тези въпроси:

  • Каква е целта на приложението?
  • Как протичат данните през приложението?
  • Как вашата функция се вписва в приложението?

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

Тествайте приложението ръчно и с единични тестове, когато е възможно

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

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

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

Помоли за помощ

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

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

Знайте кога да намалите загубите си

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

Това каза, че има недостатъци да се постигне това по този начин:

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

Като цяло, използвайте най-добрата си преценка. Има плюсове и минуси за всеки избор и всичко зависи от вашите обстоятелства и бюджет на проекта.

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

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

Бъдете смирени и мили

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

Има много фактори, които могат да доведат до това, че наследственият код изглежда „изключен“, който трябва да вземете предвид, преди да започнете да критикувате автора или да приемате най-лошото за тях (Това е слабо свързано с основната грешка в приписването!).

Оригиналният автор може да е имал своите причини да напишат код по начина, по който са го направили.

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

Конвенциите се променят.

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

Целият код в крайна сметка става наследство

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

Гордейте се с малките успехи

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

За да успеете да навигирате успешно наследения код, вие показвате способността си да бъдете адаптивни, което е важно умение, което ви е от полза за текущата ви работа и всички бъдещи ваши работни места, независимо дали те са в областта на технологията или не. Legacy code е идеалната площадка за практикуване на това умение.

В заключение

Използвайте това време, за да подсилите писането на собствен код

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

Разработете приложения за потребителя и бъдещия разработчик

Независимо дали сте имали опит с чудесни коментари за документация и код или няма коментари за документация или код, можете да видите как документацията, така и коментарите са мощни инструменти, които да помогнат на бъдещите разработчици да се ориентират по проекта. Споделяте обща цел да искате гладко, функционално и СУХО приложение; поддържането на документацията и оставянето на коментари от информативен код е добър начин за преодоляване на тази празнина.

Не забравяйте, че кодът ви ще бъде наследен и някой ден

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

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