Поправити (фиксирати) у програмирању: шта је то, фазе и како исправљати

Шта значи „поправити” у програмирању

Поправити (фиксирати) — исправити грешку у програмском коду, конфигурацији или подацима. Термин потиче од енглеског „to fix” (поправити) и једна је од најчешћих речи у речнику програмера. Поправка може бити једноставна — исправљање грешке у куцању у реду — или сложена, која утиче на архитектуру целог модула.

Глагол „фиксирати” има двоструко значење: поред исправљања бага, може значити „забележити измене у систему за контролу верзија” (од енг. „commit/fix”). У оба случаја резултат је исти — код постаје бољи него што је био пре интервенције. У професионалној заједници разлика између речи је минимална и обе се користе као потпуни синоними.

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

Животни циклус бага: од откривања до поправке

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

Откривање и регистрација

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

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

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

Писање теста и поправка

Пре поправке препоручује се писање теста који репродукује баг — ово гарантује да поправка заиста ради и спречава регресију у будућности. Након што тест падне са очекиваном грешком, програмер пише код за исправку. Тест мора да прође након поправке и буде додат у регресиони сет.

func testLoginWithInvalidCredentials() {
    let result = AuthService().login(
        email: "wrong@test.com",
        password: "wrong"
    )
    XCTAssertEqual(result, .failure(.invalidCredentials))
}

Код-преглед и провера

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

Деплој и верификација

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

Hotfix и bugfix: када и који приступ одабрати

Hotfix — хитна исправка критичне грешке која тренутно утиче на кориснике у продукцији. Таква поправка се извршава ван редовног развојног циклуса: креира се посебна грана од релеаз гране, уноси минимална измена, грана се тестира и одмах примењује. Након hotfix-а, измена се обавезно спаја са главном развојном граном.

Bugfix — планска исправка која пролази комплетан животни циклус: од регистрације до код-прегледа и регресионог тестирања. Bugfix је укључен у редован спринт и не захтева хитну примену. Разлика између hotfix-а и bugfix-а је у хитности и процедури, а не у сложености саме измене.

Када је потребан hotfix

Hotfix је неопходан када је у продукцији откривен проблем који блокира кључну функционалност: не ради платни пролаз, пада ауторизација, корисници виде празан екран. У таквим случајевима сваки сат застоја кошта новац и поверење. Hotfix треба да буде минималан — само усмерена измена која отклања проблем, без рефакторисања суседног кода.

Када је довољан bugfix

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

Практични процес: како правилно поправљати багове

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

Репродукуј баг локално

Пре него што напишеш код, репродукуј баг у свом развојном окружењу. Без репродукције нећеш моћи да провериш да ли поправка ради. Користи исте податке као корисник — копирај конфигурацију, ознаке функција, верзију API-ја. Ако се баг не репродукује локално, додај привремено логирање на стејџингу.

Напиши тест који пада са багом

Добра пракса је да прво напишеш тест који репродукује баг и пада. Ово служи две сврхе: прво, доказујеш да баг постоји, друго, након поправке тест пролази, потврђујући исправку. Тест остаје у бази кода као заштита од регресије.

@Test
fun testCartTotalWithPromotion() {
    val cart = Cart().apply {
        addItem(Item("T-shirt", 29.99))
        addPromotion(Promotion("10OFF"))
    }
    Assert.assertEquals(26.99, cart.total())
}

Направи минималну исправку

Минимална измена — кључни принцип bugfix-а. Немој рефакторисати суседни код успут, не поправљај друге багове у истом комиту. Сваки комит треба да решава тачно један проблем. Ово поједностављује код-преглед, враћање ако је потребно и разумевање историје измена. Једна измена — један комит.

Провери да ли поправка ради и не ломи друге делове

Након писања поправке, покрени цео регресиони сет тестова. Ако поправка утиче на заједнички модул, провери и тестове суседних модула. Покрени линтер и провери да ли је код у складу са прихваћеним стандардима у пројекту. Тек након тога креирај Pull Request.

Алати за праћење и најбоље праксе

Системи за праћење багова су неодвојив део процеса поправки. Они омогућавају да се не изгуби ниједна грешка, постави одговорна особа, прати статус и прикупи статистика. Избор алата зависи од величине тима и процеса, али основна функционалност је слична: креирање задатка, животни циклус, приоритети, интеграција са VCS.

Популарни алати

Jira — најраспрострањенији систем за enterprise пројекте, који подржава флексибилне workflow, прилагођена поља и интеграцију са Bitbucket/GitHub. GitHub Issues — уграђени трацкер, погодан за мале и средње тимове, интегрисан са Pull Request. Linear — модеран трацкер са минималистичким интерфејсом и великом брзином рада, популаран у стартапима.

Најбоље праксе за поправке

Прво: поправљај узрок, а не симптом. Ако апликација пада због nil-а, не обавијај цео код у if let — схвати зашто је вредност постала nil. Друго: поправка треба да садржи тест који доказује исправку. Треће: не поправљај два бага у истом комиту — ово отежава враћање. Четврто: додај у опис комита линк ка задатку у трацкеру.

• Користи формат conventional commits: fix(auth): handle nil token
• Увек стави линк ка issue-у у опису комита
• Провери да ли тестови пролазе пре и после поправке
• За hotfix креирај посебну грану од релеаз гране, не од develop
• Не заборави да спојиш hotfix са develop након примене