Меню

Рефакторинг на кода: Какво трябва да знаете за него

code refactoring what you need know about it

Опитайте Нашия Инструмент За Премахване На Проблемите

Разбиране на рефакторинга на кода: перспектива на тестера

Терминът „рефакторинг“ се използва главно за обозначаване на необходимото почистване / редизайн на кода.

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

Освен това ще обсъдим и няколко казуса за изясняване на концепцията.

Рефакторинг на кода

Какво ще научите:

Въведение в рефакторинга

Като начало нека първо разберем какво всъщност е рефакторингът.

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

Рефакторингът на кода също набра скорост с повече екипи сега, следвайки подхода на Agile Software Development. Екипите на проектите често имат ограничено време за внедряване на нови или разширяване на функционалността на съществуващите функции и чист код. Кодът, който е лесен за разбиране и поддръжка, със сигурност изминава дълъг път при спазване на крайния срок за итерация.

Необходимост от рефакторинг на кода

Ако поддържаме оригиналната функционалност на приложението или модула, възниква въпрос като Защо изобщо се занимаваме с рефакторинг? Е, има много причини, поради които даден модул или част от кода може да се наложи да бъде рефакториран, като:

  1. Кодът мирише
  2. Технически дълг
  3. Подход за гъвкав софтуер и др.

Ще обсъдим подробно тези точки в следващите раздели.

# 1) Мирише на код:

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

Следват някои често срещани миризми на код:

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

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

# 2) Технически дълг:

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

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

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

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

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

Прочетете още=> Какво е Технически отдел

# 3) Следвайки подхода на Agile за разработване на софтуер:

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

Тази връзка е изобразена на диаграмата по-долу

Подход на подвижен софтуер за разработване

Препоръчително четене => Топ инструменти за анализ на кода

Защо QA трябва да знае за рефакторинга?

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

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

# 1) За модулни тестери / разработчици

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

# 2) За тестери

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

  • Като тестер, рефакторингът на кода грубо се превежда в = задълбочено тестване + тестване на регресия. Задълбоченото тестване трябва да включва всички съществуващи потребителски потоци, за да се гарантира, че всички функционалности работят както преди. Регресионно тестване на цялото приложение (или засегнати области) се изисква, за да се гарантира, че надстройването на модул не е нарушило неволно функционалността на другите модули.
  • Тестовете за приемане от потребителите ще бъдат важни и тези тестове трябва да преминат, преди компилацията да може да бъде обявена за готова за пускане.
  • Освен това, всеки друг тест, като тестове за натоварване, тест за сигурност и т.н. също ще трябва да се приложи според изискванията.

# 3) Инженери за тестове за автоматизация

Рефакторингът на кода може да доведе до отказ на функционални и нефункционални скриптове за автоматизация.

Това може да се случи поради следните причини:

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

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

Като разработчици на тестове за автоматизация, инженерите за автоматизация също трябва да мислят като разработчик и да се стремят да създадат чист и лесен за поддръжка код. Повечето от IDE като IntelliJ IDEA, Eclipse и др., Включват вградено меню за рефакторинг с често използвани методи за рефакторинг за лесна справка.

По-долу е екранна снимка на менюто за рефакторинг в IntelliJ IDEA (издание на общността).

как да отворите bin файл windows 10

меню за рефакторинг

# 4) За тестови потенциални клиенти / QA потенциални клиенти

  • Може да се наложи да се проведат тестови клиенти / QA Leads, за да работят заедно с останалата част от екипа, включително разработчици, продуктов анализатор и може би дори заинтересовани страни, за да се гарантира, че планирането на тестове за такива проекти се извършва внимателно.
  • Важно е да разберете съществуващата функционалност. Въз основа на съществуващата функционалност трябва да се документират бизнес казуси, потребителски потоци и тестове за приемане от потребителите. Когато се тества рефакториран код, всички тези сценарии трябва да бъдат валидирани, заедно с регресионно тестване на засегнатите области.
  • Бъдете инициативни, докато планирате тестовия подход и планове за изпитване . Ако предвиждате изискването за множество тестови среди или нови тестови инструменти, моля изпратете заявката по-рано, за да предотвратите всякакви закъснения, след като започне фазата на тестване.
  • Не се колебайте да включите членове на непроектни екипи или крайни потребители, които да допринесат за тестването.

Казуси

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

Казус №1

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

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

Тестов подход :Бяха изпълнени тестовите случаи за реконструирания модул и относително известните засегнати области. Всички дефекти бяха докладвани и отстранени преди пускането.

Казус №2

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

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

Сега компанията искаше да пусне това приложение като софтуер като услуга (SaaS), с очаквания обем от 300 едновременни сесии първоначално.

Екипът направи някои първоначални тестове за натоварване и стигна до заключението, че системата се прекъсва с натоварване от 25 едновременни сесии. Екипът прегледа кода и препоръча рефакторинг на една съществуваща съхранена основна процедура, която ще позволи на приложението да се мащабира и да поддържа до 500 едновременни сесии, без да се прекъсва.

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

Предизвикателства:

# 1) Ръководител на проекти / продуктов анализатор

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

# 2) За разработчици

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

# 3) За тестери

  • Липса на ясни изисквания и бизнес правила за планиране на тестове за въздействие.
  • Планиране на тестове за въздействие на неизвестни засегнати области, особено за регресионни тестове
  • Не може да предостави конкретни оценки за тестване.

# 4) Заинтересовани страни

  • Липса на ясни документирани изисквания и / или потребителски потоци + тесни срокове = По-висок риск от повреда.

Подходът, следван от екипа за намаляване на рисковете и заобикаляне на предизвикателствата :

(i) Екипът е следвал съвместен подход за събиране на изискванията : Ръководител на проекти / продуктови анализатори и тестери са работили в тясно сътрудничество с вътрешните крайни потребители, за да разберат и документират основната функционалност и потребителския поток.

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

(ii) Алтернативната тестова среда е създадена за тестване на внедрената промяна : Нека наречем тези среди като Gamma и Phi. Gamma щеше да разполага със стария код, а Phi щеше да разполага с най-новата рефакторирана съхранена процедура по всяко време.

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

Екипът предостави изискванията за алтернативна тестова среда, която беше предоставена преди началната дата на спринта.

(iii) Крайни потребители и заинтересовани страни, участващи в тестването рано : Всички очевидни проблеми бяха уловени и докладвани рано, като позволиха повече време на екипа да разгърне и тества необходимата корекция.

(iv) Определяне на критерии за излизане и придържане към тях: Критериите за изход бяха дефинирани в началните етапи на планиране - тествани са 80% потребителски потоци, не е разрешена критична грешка, демонстрация и излизане от заинтересованите страни преди пускането.

(v) Определяне на предварителна дата на пускане: Определяне на дата на издаване и мотивиране на екипа да работи за постигане на обща крайна точка. Въз основа на обхвата на проекта, екипът препоръча да се следва 3-седмичен спринт вместо обикновен 2-седмичен спринт, за да се осигури достатъчно време на екипа да изпълни проекта.

Заключение

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

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

За тестерите рефакторингът на кода грубо се превежда като = задълбочено тестване + тестване на регресия.

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

Възможно е да се изискват тестови клиенти / QA Leads, за да работят заедно с останалата част от екипа, включително разработчици, продуктови анализатори, особено за наследствени проекти. Бъдете инициативни, докато планирате тестовия подход и тестовите планове. Ако предвиждате изискването за множество тестови среди или нови тестови инструменти, моля, изпратете заявката рано, за да предотвратите закъснения, след като започне фазата на тестване.

За автора: Този информативен урок е написан от Neha B. В момента тя работи като мениджър за осигуряване на качеството и е специализирана в ръководенето и управлението на вътрешни и офшорни екипи за QA.

Работили ли сте по предизвикателен проект, който включва рефакторинг на код или модул / приложение? Ако отговорът е да, не се колебайте да споделите своя опит в раздела за коментари, за да могат да се учат от нашите колеги тестери.

Препоръчително четене

^