Мени

Рефакторирање кода: шта треба да знате о томе

code refactoring what you need know about it

Испробајте Наш Инструмент За Елиминисање Проблема

Разумевање преправљања кодова: перспектива тестера

Термин „Рефакторирање“ углавном се користи да означи потребно чишћење / редизајн кода.

У овом упутству ћемо разумети дефиницију рефакторирања, разговарати о потреби за рефакторингом кода и прегледати утицај рефакторинг кода на различите чланове пројектног тима. Такође ћемо разговарати о одговору на најважније питање - Као тестер, зашто треба да знате о рефакторингу?

Поред тога, разговараћемо и о неколико студија случаја како бисмо разјаснили концепт.

Рефакторирање кода

Шта ћете научити:

Увод у рефакторирање

За почетак, хајде да прво схватимо шта је заправо рефакторирање.

Рефакторирање је у основи пракса или процес побољшања кода и / или базе података уз задржавање постојеће функционалности. Идеја је трансформисати неефикасан и прекомпликован код у ефикаснији, по могућности једноставнији и лакши.

Рефакторирање кода такође је узело замах са већим бројем тимова пратећи приступ Агиле Софтваре Девелопмент. Пројектни тимови често имају ограничено време да примене нове или прошире функционалност постојећих карактеристика и кода који је чист. Код који је једноставан за разумевање и одржавање свакако увелико доприноси испуњавању рока за понављање.

Потреба за прерађивањем кода

Ако одржавамо изворну функционалност апликације или модула, поставља се питање Зашто се уопште мучимо рефакторирањем? Па, постоје бројни разлози због којих ће можда требати рефакторизовати одређени модул или део кода, попут:

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

О овим тачкама ћемо детаљно разговарати у следећим одељцима.

# 1) Мирис кода:

Сви можемо схватити да када храна почне мирисати, то указује на то да се највероватније претвара у лоше стање - то важи и за код! Мириси кода су показатељи да у коду може постојати много озбиљан проблем.

Следи неколико уобичајених мириса кода:

  • Присуство сувишног или идентичног кода.
  • Декларисана променљива која се не користи нигде у остатку кода.
  • Прекомпликован дизајн кода.
  • Класа кода која чини премало и не оправдава постојање дефинисане класе. Такве класе су познате као лења класа или бесплатни учитавач.
  • Постојање превише услова и петљи које могу бити разбијене и поједностављене.
  • Код се гради на начин да промена једног дела кода захтева да се промена примени и на другим местима.

Мириси кода постају очитији с временом. Како апликација или систем расте, на крају мириси овог кода почињу да утичу на развој, одржавање и чак перформансе система у екстремним сценаријима.

# 2) Технички дуг:

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

Размотрите функцију коју треба додати постојећем модулу. Након дискусије, тим сужава 2 приступа како би додао ову функцију. Приступ А, за који је потребно 2 спринта, биће одобрени дугорочни приступ. Приступ Б траје само 5 дана док је неуредан, добро кодиран хакер дизајниран да краткорочно само сервисира модул.

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

Једноставно речено, технички дуг у развоју софтвера односи се на додатну прераду или режијске трошкове потребне за постављање одговарајућих исправки или за обављање ствари на „прави начин“.

Наслеђени системи имају тенденцију да временом стекну огроман технички дуг, што заузврат може учинити апликацију подложном неуспеху и тешком за подршку и одржавање.

Опширније=> Шта је Техничко одељење

# 3) Следећи агилни приступ развоју софтвера:

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

Овај однос је приказан на доњем дијаграму

Приступ агилног развоја софтвера

Препоручено читање => Врхунски алати за анализу кода

Зашто КА треба да зна о рефакторингу?

Чини се да је све оно о чему смо до сада разговарали у овом упутству повезано са кодирањем и изгледа као неке ствари око којих би програмер требало да брине.

Зашто онда разговарамо о овом неповезаном концепту у Заједници за помоћ за тестирање софтвера? Наставите да читате остатак овог водича за одговор на ово питање.

# 1) За јединице тестере / програмере

Током рефакторирања кода, како се убацује нови код, старе класе се ажурирају, додају се нове класе, а постојећи Унит тестови сада могу пропасти. Поред тога, за старе системе можда уопште неће бити примењени јединствени тестови. У већини случајева ове нове јединствене тестове мораће да се креира и постави од нуле.

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

Када се функција преправља (с обзиром на то да не додајемо нове функције), подразумева се да након што се изврше потребне промене, већина функционалности за крајњег корисника треба да остане иста.

  • Као тестер, рефакторирање кода отприлике значи = дубинско тестирање + тестирање регресије. Дубинско тестирање мора да обухвати све постојеће корисничке токове како би се осигурало да све функционалности раде као и пре. Регресија тестирање целокупне апликације (или погођених подручја) потребан је како би се осигурало да надоградња модула ненамерно није нарушила функционалност осталих модула.
  • Кориснички тестови прихватања биће важни и ови тестови морају да прођу пре него што се верзија може прогласити спремном за објављивање.
  • Поред тога, било који други потребан тест попут тестова оптерећења, тест безбедности итд. такође би требало применити према потреби.

# 3) Инжењери за аутоматизацију

Рефакторирање кода може проузроковати неуспјех функционалних и нефункционалних скрипти за аутоматизацију.

Ово се може догодити из следећих разлога:

  • Ако се објекти странице промене као део напора за рефакторирање и ако се ваше скрипте за аутоматизацију Селениум ослањају на објекте странице, тада скрипте неће успети и мораће бити ажуриране.
  • Ако је дошло до мањих промена, он преусмерава оне које су додате или уклоњене током рефакторирања, а постојеће скрипте за аутоматизацију не би успеле и требало би их ажурирати

Препоручује се да тестови функционалне аутоматизације буду постављени тек када је нека функција стабилна, у супротном ће резултирати великим бројем прераде како се функција развија.

Будући да су програмери тестова за аутоматизацију, инжењери за аутоматизацију такође морају да размишљају као програмери и имају за циљ да створе чист и лак за одржавање код. Већина ИДЕ-а, као што су ИнтеллиЈ ИДЕА, Ецлипсе итд., Укључују уграђени мени за рефакторирање са уобичајеним методама рефакторинга ради лакшег сналажења.

Испод је снимак екрана менија за рефакторирање у програму ИнтеллиЈ ИДЕА (издање заједнице).

уник заповеда интервјуисање питања и одговора за искусне

мени за рефакторирање

# 4) За тестне потенцијалне купце / КА потенцијалне купце

  • Од потенцијалних клијената / потенцијалних клијената може се захтевати да раде заједно са остатком тима, укључујући програмере, аналитичара производа и можда чак и заинтересоване стране како би се осигурало да се планирање тестова за такве пројекте пажљиво ради.
  • Важно је разумети постојећу функционалност. На основу постојеће функционалности, морају се документовати пословни случајеви, токови корисника и тестови прихватања корисника. Када се преправљени код тестира, сви ови сценарији морају бити потврђени, заједно са регресионим испитивањем погођених подручја.
  • Будите проактивни док планирате приступ тестирању и планови испитивања . Ако предвиђате потребу за вишеструким тест окружењима или новим тест алатима, пошаљите захтев рано да бисте спречили кашњења када фаза тестирања започне.
  • Не устручавајте се да укључите чланове не-пројектног тима или крајње кориснике да дају свој допринос тестирању.

Студије случаја

Сада ћемо разговарати о неким стварним студијама случајева на којима сам имао прилику или директно да радим или индиректно да дам свој допринос.

Студија случаја # 1

Задатак: Рефакторизирајте модул за замјену тврдо кодираних вриједности варијаблама и додајте коментаре за нови алат за аутоматско генерирање техничке документације.

Изазови :Нема већих изазова. Модул је био нов, имао је документоване функционалне и корисничке захтеве за прихватање, корисничке токове и тестове. Јединствени тестови су постављени током самог почетног лансирања.

Приступ тестирању :Извршени су тест случајеви за модул који се преправља и релативно позната погођена подручја. Сви недостаци су пријављени и решени пре пуштања.

Студија случаја # 2

Задатак :Реформишите постојећу ускладиштену процедуру како бисте олакшали повећање степена примене

Похрањена процедура у овом сценарију била је старија ускладиштена процедура која је дизајнирана пре неколико година, имајући на уму захтев да апликација користи своју ускладиштену процедуру као интерну апликацију са мање од 10 истовремених сесија.

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

Тим је извршио неколико почетних тестова оптерећења и закључио да се систем прекида са оптерећењем од 25 истовремених сесија. Тим је прегледао код и препоручио рефакторизацију једне постојеће ускладиштене процедуре која ће омогућити апликацији да се прошири и подржи до 500 истовремених сесија без прекида.

Неки проблеми идентификовани овом ускладиштеном процедуром били су вишеструки подупитиви у оквиру једног упита, тешка спајања са приказима уместо табела, употреба селецт * уместо одабира одређене колоне итд. Због ових проблема са кодирањем, апликација је дохватала више података од тога је заиста био неопходан, што је довело до успоравања апликације и на крају пада.

Изазови:

# 1) Менаџер пројеката / аналитичар производа

  • Окупљање захтева - Будући да је ова ускладиштена процедура била застарели код, за њу нису постојали документовани захтеви када је модул први пут дизајниран. Такође за итерације урађене у последњих неколико година, није било дневника промена који би указивао на пословна правила и логику додата или уклоњена из модула.
  • Распоред пројекта - Будући да захтеви нису били јасно дефинисани, а зависности кода још увек нису у потпуности идентификоване, било је тешко саопштити оквирни распоред.

# 2) За програмере

  • Недостатак јасних захтева и правила пословања.
  • Чишћење кода без губитка његове функционалности.
  • Непозната погођена подручја и / или зависности кода.
  • Није могуће пружити конкретне процене времена развоја.
  • Потребно је створити нове јединичне тестове.

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

  • Недостатак јасних захтева и правила пословања утичу на планирање испитивања.
  • Планирање испитивања утицаја на непозната погођена подручја, посебно за регресиона испитивања.
  • Није могуће пружити конкретне процене испитивања.

# 4) Актери

  • Недостатак јасних документованих захтева и / или протока корисника + кратки рокови = Већи ризик од квара.

Приступ који тим следи за ублажавање ризика и заобилажење изазова :

(и) Тим је следио заједнички приступ у сакупљању захтева : Менаџер пројеката / аналитичар производа и тестери тесно су сарађивали са унутрашњим крајњим корисницима како би разумели и документовали главну функционалност и проток корисника.

Програмери су такође прегледали код и додали релевантне информације у документ са захтевима. То је урађено пре дана почетка спринта.

(ии) Алтернативно тест окружење је створено за тестирање промене која се примењује : Назовимо ова окружења Гамма и Пхи. Гамма би имала стари код, а Пхи би имао најновију рефакторирану ускладиштену процедуру која би се стално користила.

Имајући паралелно 2 тест окружења, скоро рекреирајући пре и после приступа, омогућили су тиму да изврши детаљнија и истраживачка тестирања упоређивањем понашања у ова 2 тест окружења, успели су да идентификују вероватне грешке.

Тим је пружио захтеве за алтернативно тест окружење које је обезбеђено пре датума почетка спринта.

(иии) Крајњи корисници и заинтересоване стране које су рано укључене у тестирање : Сви очигледни проблеми су ухваћени и пријављени рано, омогућавајући тиму више времена за распоређивање и тестирање потребног поправка.

(ив) Дефинисање излазних критеријума и њихово придржавање: Критеријуми за излаз су дефинисани у почетним фазама планирања - тестирано је 80% корисничких токова, није решена ниједна критична грешка, демонстрирано и одјављено од заинтересованих страна пре пуштања.

(в) Одређивање оквирног датума објављивања: Одређивање датума објављивања и мотивисање тима да ради на заједничкој крајњој тачки. На основу обима пројекта, тим је препоручио да се прати тронедељни спринт уместо редовног двонедељног спринта како би се тиму обезбедило довољно времена за извршење пројекта.

Закључак

Да резимирамо, рефакторирање кода је процес чишћења / поједностављења дизајна модула без промене његове функционалности. Процес рефакторирања може бити једноставан, попут додавања коментара, додавања тачних увлака, уклањања статичке променљиве итд. Или може бити сложен за сложене старе системе.

Одређени модул или комад кода ће можда бити потребно реконструисати због мириса кода, техничког дуга или следења агилног приступа развоју софтвера.

За тестере, рефакторирање кода отприлике значи = дубинско тестирање + регресијско тестирање.

Потребно је детаљно тестирање да би се тестирали сви постојећи токови корисника како би се осигурало да ли све функционалности раде као раније. Потребно је регресијско тестирање целокупне апликације (или погођених подручја) како би се осигурало да надоградња модула ненамерно није нарушила функционалност осталих модула.

Од потенцијалних потенцијалних клијената / потенцијалних клијената може се захтевати да раде заједно са остатком тима, укључујући програмере, аналитичара производа, посебно за старе пројекте. Будите проактивни док планирате приступ тестирању и планове испитивања. Ако предвиђате захтеве за вишеструким тест окружењима или новим тест алатима, пошаљите захтев рано да бисте спречили кашњења када фаза тестирања започне.

О аутору: Овај информативни водич написала је Неха Б. Тренутно ради као менаџер за осигурање квалитета и специјализована је за вођење и управљање интерним и офшор тимовима за КА.

Да ли сте радили на изазовном пројекту који је подразумевао рефакторизацију кода или модула / апликације? Ако је одговор да, слободно поделите своја искуства у одељку за коментаре од којих могу да науче наши колеге тестери.

Препоручено читање

^