Kodo užšaldymas

Kodo užšaldymas arba code freeze - programavimo etapas, kuris yra daromas prieš relyzą, jei nenori gauti didelio feilo ir apsišikimo iki pat ausų, o kartais ir dar smarkiau. Kodo užšaldymo esmė - kad tam tikram, gana ilgam laikui, programa tiesiog užšaldoma ir laikoma kaip nejudinama, išskyrus nenumatytų bugų taisymą. Numatyt bugai irgi nejudinami, taisomi tik tie, kurie numatyti nebuvo. Kartu daromi intensyvūs testai.

Tipišku geru atveju code freeze periodas yra apie tris mėnesius - tiek laiko užtrunka, kol galima daugmaž gerai išgaudyti visokias nesąmones.

Gi programuotojai code freeze metu užsiima visiškai nesusijusios, kitos softo versijos gerinimu - nesvarbu, ar tai būtų bugfiksinimas, ar tai būtų fyčerių gaminimas.

Visa code freeze esmė - turėti užšaldytą, bet gerą ir tvarkingai veikiančią versiją, su kuria nenutiktų nieko nenumatyto ir kuri bent minimaliose ribose veiktų būtent taip, kap žadama vartotojui, t.y., prognozuojamai.

Kodo užšaldymo tikslai yra du:

• Pirmas tikslas - išvengti situacijų, kur nenumatytai įvyksta "Ooops, atsiprašom, čia neveikia, atsiprašom, dabar neleisim šitos versijos, apsišikom"
• Antras tikslas - palikti programuotojus laisvus taisyti realiai neišvengiamiems bugams, tokiems kur realiai negali išvengti ir turi pataisyti norom nenorom - jie gauna tą code freeze periodą

Tipiškos nepatyrusių projektų vadovų klaidos, susijusios su kodo užšaldymu prieš relyzą:

• Šaldymui paskiriamas per trumpas laiko periodas, pvz., vienas mėnuo - per tą laiką nespėjama rasti nenumatytų bugų
• Šaldomame kode yra taisomos įprastos klaidos ar daromi kiti fyčeriai, kas nepastebimai privelia tuntus naujų bugų
• Kodo šaldymo periodas paskiriamas įprastiems, jau anksčiau žinomiems bugams taisyti
• Kodo šaldymo periodas skaičiuojamas, į jį įtraukiant visokių numatytų fyčerių realizavimo ar bugų taisymo periodus
• Kodo šaldymas tiesiog nenumatomas, nes nu kam jis, ir be jo gerai

Yra du kiti momentai, kurie dažnai labai klaidingai painiojami su kodo šaldymu:

• Fyčerių listo užšaldymas - momentas, nuo kurio naujų fyčerių kūrimas netraukiamas į artimiausio relyzo developmentą
• Bugų listo užšaldymas - monentas, nuo kurio įprastų naujų bugų taisymas netraukiamas į artimiausio relyzo developmentą

Ir fyčerių listo užšaldymas, ir bugų listo užšaldymas turi būti padarytas gerokai prieš kodo užšaldymą, o paskui jau padaryti abiejuose listuose numatyti darbai - irgi dar prieš kodo užšaldymą pradedant. Jei kažkurie iš tų darbų nespėjami iki užšaldymo termino, jie atidedami sekančiam relyzui, tačiau per šaldymo periodą neturi būti daromi.

Šaldymo periodo metu tvarkomi tik tie bugai, kurie yra aukštesnio prioriteto, t.y., nenumatyti ir kritiniai. Visas kitas balaganas turi vykti paskirai.

Jei šaldymo periodas nedaromas, tai kaskart relyzo padarymas virsta į totalinį pyzdauską, kur niekas nieko nespėja, lenda paskutinės minutės bugai ir paskutinę minutę atsiradę būtini fyčeriai (kartais realiai būtini), o laiko jiems sutvarkyti nebėra. Galutinis vartotojas tada visais atvejais (be jokių išimčių) gauna softą, kuris yra nedadirbtas, su kokiais nors bugais ir panašiai.

Aišku, įdomusis fenomenas čia yra tai, kad netgi visai rimtose kompanijose apie 80% atvejų kodo šaldymas nevykdomas arba vykdomas blogai (su aukščiau minėtomis klaidomis). Taigi, to rezultate ir turime tą visiems pažįstamą tragišką softo kokybę su visais tais errorais, šiaip nesąmonėmis ar išvis BSOD.