Kujenga programu kunaweza kuhisiwa kama onyesho la hadhara. Mtandao hupatia zawadi uzinduzi, picha za skrini (screenshots), na vipengele vya mabadiliko (changelog bullet points). Hivyo, wakati mwanalishi wa programu (developer) anapotumia kikao kizima kwenye mradi na hana kitu kinachoonekana cha kuonyesha, silika yake ni kusema kuwa siku hiyo imepotea. Kumbukumbu ya maendeleo (dev log) ya hivi karibuni kutoka kwa Food Blog Platform inathibitisha kinyume chake. Hakukuwa na mapishi mapya ya kuonyesha, hakukuwa na kadi zilizoboreshwa, wala vitufe vya ziada kwa watumiaji kubofya. Ni kodi tu iliyochambuliwa, ikakaguliwa, na kuunganishwa tena kwa ubora zaidi kuliko awali.
Hii ndiyo kazi isiyoonekana inayofanya miradi ya muda mrefu iendelee kuishi.
Vipengele Hupata Sifa; Refactoring Huwezesha Uendeshaji
Unapodumisha jukwaa la blogu ya chakula, sehemu ya juu inaonekana rahisi. Watumiaji huchapisha mapishi, hupakia picha, na kutafuta kwa kategoria. Hata hivyo, chini ya uso, unashughulikia mifumo ya picha (image pipelines), uhusiano wa kanzi data (database relationships) kati ya viungo na maelekezo, viashiria vya utafutaji (search indexes), na tabaka za kashia (caching layers). Baada ya muda, marekebisho ya haraka hujikusanya. Kazi msaidizi (helper function) iliyanakiliwa kwenye faili tatu tofauti. Swali la kanzi data (database query) ambalo lilikuwa na maana kwa machapisho kumi lakini linakwama unapofika elfu moja. CSS iliyoanza ikiwa imepangwa vizuri hadi pale marekebisho matano ya dharura yalipoifanya kuwa kama mtego.
Refactoring inamaanisha kukabiliana na uchafu huo moja kwa moja. Inaweza kumaanisha kuunganisha mantiki inayojirudia ili fomu ya kuhariri mapishi na dashibodi ya msimamizi (admin dashboard) zitumie tabaka moja la uhakiki (validation layer) badala ya kudumisha matoleo sambamba. Inaweza kumaanisha kurahisisha jinsi picha zinavyochakatwa ili utaratibu wa ukandamizaji (compression routine) ufanye kazi mara moja badala ya kila wakati ukurasa unapopakia upya. Au inaweza kuhusisha kupanga upya msingi wa kodi (codebase) ili kuongeza aina mpya ya maudhui baadaye kusiwe na haja ya kutafuta kwenye miongozo sita isiyohusiana.
Hakuna kitu kati ya hiki kinachoonekana kwenye kiolesura cha mtumiaji (user interface). Mgeni anayetembelea tovuti hataona kichwa cha habari kinachosema "swali limeboreshwa" (query optimized) au "vipengele vimetenganishwa" (component decoupled). Lakini watahisi wakati tovuti inapopakia kwa haraka zaidi. Wataona wakati kipengele kipya kinapotokea siku tatu baada ya kuombwa badala ya wiki tatu. Mwanalishi wa programu hakupata uwezo mpya leo. Alifungua njia ili uwezo mpya uweze kuongezwa bila kupambana na msingi wa kodi.
Kodi Safi ni Uwekezaji Dhidi ya Kushindwa kwa Baadaye
Kila mradi unaodumu zaidi ya mwezi hujikusanya msuguano. Unajenga mfano wa haraka (prototype) ili kujaribu wazo. Kisha watumiaji wanakuja kweli. Kisha unahitaji tabaka la uthibitisho (authentication layer), kisha foleni ya usimamizi (moderation queue), na kisha mpangilio wa simu (mobile layout). Kila moja ya nyongeza hizo inaunganishwa kwenye muundo wowote uliopo tayari. Bila matengenezo ya mara kwa mara, usanifu (architecture) huanza kufanana na nyumba ambapo kila chumba kipya kilichoundwa na mtu tofauti ambaye hakuwahi kuona ramani ya nyumba hiyo.
Deni la kiufundi (technical debt) si kushindwa kwa nidhamu. Ni matokeo ya asili ya kufanya maamuzi ya kuachia kitu fulani ili kupata kingine (trade-offs) ili kutoa kitu halisi. Hatari si kwamba kodi yako si kamilifu. Hatari ni kuiacha isiwe kamilifu kwa muda mrefu kiasi kwamba kubadilisha kigezo kimoja kunaharibu vipengele vitatu visivyohusiana. Unajikuta unaogopa kugusa sehemu ya utafutaji kwa sababu mara ya mwisho ulipojaribu, mfumo wa lebo (tag system) uliharibika. Unachelewesha kuongeza kijisehemu cha mpangilio wa chakula (meal-planner widget) kwa sababu unajua muundo wa kanzi data (database schema) umekuwa kama mafundo ambayo yatachukua saa nyingi kuyatua.
Kutumia siku moja kufanya refactoring ni kama kulipa deni hilo kabla riba haijakuzidi. Inazuia matatizo madogo kuwa makubwa. Wakati Food Blog Platform itakapoongeza kipengele chake kikubwa kinachofuata, mwanalishi wa programu hatatalazimika kuzunguka kodi inayovunjika kirahisi (brittle code). Ataandika mantiki mpya, ataunganisha kwenye kiolesura safi, na kuendelea. Hiyo ndiyo faida ya uwekezaji.
Hatua Ndogo, Mafunzo Halisi
Kuna imani potofu kuhusu uendelezaji wa programu inayosema maendeleo yanaonekana kama uvumbuzi wa ajabu na vipindi virefu vya uandishi wa kodi vinavyofuta kila kitu usiku mmoja. Wataalamu wengi wa programu watakuambia hiyo ni ndoto. Maendeleo halisi yanaonekana kama mabadiliko (diff) ya alasiri ya Jumanne ambapo kazi tatu zilifupishwa, utegemezi mmoja usiohitajika uliondolewa, na jina la kigezo lililochanganya lilibadilishwa ili msomaji anayefuata aelewe hasa linachofanya.
Kumbukumbu ya maendeleo ya Food Blog Platform inakamata mdundo huu kikamilifu. Kujenga programu ni kuhusu maboresho madogo na thabiti. Unajifunza kutoka kwa kila changamoto. Labda leo changamoto ilikuwa kuelewa kwa nini moduli fulani ilikuwa imetegemea sana nyingine. Labda ilikuwa ni kutambua kwamba njia ya mkato iliyochukuliwa wiki mbili zilizopita ilikuwa imeanza kugharimu muda mwingi kuliko ilivyookoa. Kila commit inafanya mradi kuwa bora, hata wakati commit hiyo inafuta zaidi ya inavyounda.
Njia hii pia inalinda motisha yako. Kuandika upya mambo kwa kiasi kikubwa ni kuchosha na kuna hatari. Huleta hitilafu mpya wakati wakitatua za zamani. Uboreshaji wa hatua kwa hatua (incremental refactoring), ukiendeshwa