Legacy sa Pag-develop ng App — Ano Ito, Mga Risgo at Estratehiya sa Paggawa

Ano ang Legacy sa Pag-develop ng App

Legacy — code o sistema na patuloy na gumagana sa produksyon ngunit hindi na nakakatugon sa modernong pamantayan ng kalidad. Ang legacy ay maaaring nakasulat sa lumang wika (hal. Objective-C sa halip na Swift), gumagamit ng hindi suportadong mga library o pattern ng arkitektura na matagal nang itinuturing na antipattern.

Ang pangunahing katangian ng legacy ay ang kawalan ng tests. Ayon sa depinisyon ni Michael Feathers (2004), ang legacy code ay code na walang tests. Kung ang pag-uugali ay hindi ligtas na mababago, ang sistema ay nasa legacy status anuman ang edad. Sariwang code na walang unit tests — ay legacy sa unang araw.

Ang legacy ay hindi naman masama. Ang isang mahusay na dinisenyong sistema sa Java 8 ay maaaring mas maaasahan at mas maintindihan kaysa magulong code sa Kotlin na may coroutines. Edad ng code ay hindi indikasyon ng kalidad — ang mahalaga ay kung gaano kahanda ang sistema para sa mga pagbabago at pagpapalawak.

Bakit Normal ang Legacy Code

Bawat matagumpay na sistema sa paglipas ng panahon ay nagiging legacy. Ito ay natural na proseso: mas mabilis umunlad ang teknolohiya kaysa sa code ay maaring isulat muli. Ang app na isinulat 5 taon na ang nakaraan sa Swift 2 ngayon ay legacy, kahit na sa panahon ng paggawa ito ay moderno.

Ang halaga ng negosyo ng legacy ay madalas minamaliit. Ang sistema ay gumagana nang matatag, nagpoproseso ng transaksyon, nag-iimbak ng datos — ang pagsusulat muli ay nagdadala ng panganib. Ayon sa Standish Group (2024), 35% ng mga proyektong ganap na isinulat muli ay nauuwi sa kabiguan. Sa ekonomiya, hindi ang pagtatapon ng legacy ang makatuwiran, kundi ang pag-aaral na makipagtulungan dito.

Pinakamahuhusay na estratehiya — unti-unting migrasyon, pag-encapsulate ng lumang code sa likod ng bagong interfaces at automated testing. Ang legacy ay nagiging problema lamang kapag hindi na ito kayang baguhin sa predictable na gastos.

Mga Pangunahing Senyales ng Legacy System

Kawalan ng automated tests — pangunahing indikasyon. Kung pagkatapos baguhin ang isang linya ng code, ang developer ay hindi maaaring magpatakbo ng tests at tiyaking walang nasira — nasa harap mo ang legacy. Karagdagang senyales: ang proseso ng deployment ay tumatagal ng oras at nangangailangan ng manu-manong aksyon.

Ang dokumentasyon ay hindi tumutugma sa code — isa pang marker. Ang mga diagram ng arkitektura ay luma na, ang mga komento ay naglalarawan ng pag-uugaling nagbago na. Time-to-ramp-up para sa bagong developer ay lumalampas ng isang buwan — senyales ng mataas na komplikasyon at mababang maintainability ng sistema.

Karagdagang senyales: monolitikong arkitektura na walang malinaw na hangganan, manu-manong testing bilang pangunahing paraan ng beripikasyon, mahabang CI pipeline (higit sa 30 minuto), paggamit ng mga library na walang kasalukuyang bersyon at kawalan ng kakayahang i-update ang dependencies nang hindi sinisira ang mga kalapit na modules.

Phenomenon ng “marupok na code” — ang pagbabago sa isang lugar ay sumisira ng tatlo pang iba. Ito ay bunga ng mahigpit na pagdikit (tight coupling), kapag ang modules ay masyadong maraming alam tungkol sa isa't isa. Kung mas mataas ang coupling, mas mabilis lumipat ang sistema sa kategoryang legacy.

Mga Risgo sa Paggawa sa Lumang Code

Pagbaba ng bilis — pangunahing panganib. Ang pagdagdag ng simpleng feature ay nangangailangan ng oras ng pag-aaral ng code at araw ng pag-test. Ayon sa Stripe (2024), ang mga developer ay gumugugol ng 33% ng oras sa paglampas sa technical debt, na direktang nauugnay sa pagkakaroon ng legacy modules sa proyekto.

Pagkaubos ng expertise — ang mga may-akda ng orihinal na code ay umaalis sa kompanya at ang dokumentasyon ay hindi kumpleto. Ang mga bagong developer ay natatakot hawakan ang hindi maintindihang modules, na humahantong sa epekto ng “nakapirming code”: ang module ay hindi umuunlad ngunit patuloy na gumagana. Ang Bus factor ng mga ganitong sistema ay kritikal na mababa.

Seguridad — ang lumang mga library ay naglalaman ng kilalang mga kahinaan. Ang paggamit ng OpenSSL 1.0.2 o lumang bersyon ng Jackson sa Java projects ay direktang daan patungo sa mga insidente ng seguridad na maaaring magdulot ng pagkalugi sa reputasyon at kliyente ng negosyo.

Demotivation ng team — ang paggawa sa legacy nang walang estratehiya sa pagpapabuti ay nagbabawas ng kasiyahan ng mga developer. Ang team ay tumitigil sa pagmamalaki sa produkto, tumataas ang turnover ng tauhan, na lalong pumapabagal sa pag-unlad ng sistema.

Mga Estratehiya sa Refactoring ng Legacy

Characterization tests — unang hakbang bago ang anumang pagbabago sa legacy code. Patakbuhin ang code sa kilalang input data at itala ang inaasahang output. Ang mga tests na ito ay nagtatala ng kasalukuyang pag-uugali bilang spesipikasyon. Golden master testing — variant kung saan ang output data ay inihahambing sa reference file.

Seam analysis — paghahanap ng mga punto kung saan ang pagkakadikit ay maaaring maputol nang hindi binabago ang pag-uugali. Si Michael Feathers ay nagtatangi ng ilang uri ng seam: preprocessor seam, object seam, link seam. Object seam — pinakakaraniwan: pagpapalit ng tunay na bagay ng test stub sa pamamagitan ng interface.

Sprout method at Sprout class — mga teknik sa pagdagdag ng bagong code sa tabi ng lumang code, hindi sa loob nito. Sa halip na baguhin ang existing method, gumawa ng bagong method na may kinakailangang logic at tawagin ito mula sa luma. Ito ay nagpapaliit ng panganib na masira ang gumaganang code.

Halimbawa: pagdagdag ng logging sa legacy

class LegacyPaymentProcessor {
    def process(payment) {
        // 200 linya ng legacy code na hindi dapat hawakan
        logPayment(payment) // sprout method
    }
    def logPayment(payment) {
        // bagong code idinagdag sa tabi ng legacy
    }
}

Migrasyon sa Makabagong Technology Stack

Strangler Fig pattern — inirerekomendang approach para sa legacy migration. Ang bagong module ay ginagawa nang parallel, ang trapiko ay unti-unting inililipat mula luma patungo sa bago. Ang lumang module ay natural na “namamatay” kapag huminto ito sa pagtanggap ng mga request. Pinapaliit ng pattern ang mga panganib at pinapayagan ang rollback kung may problema.

Branch by Abstraction — teknik kung saan ginagawa ang abstraction sa ibabaw ng luma at bagong implementasyon. Ang client code ay lumilipat sa abstraction, ang lumang implementasyon ay unti-unting pinapalitan ng bago. Halimbawa: pagpapalit ng network layer mula AFNetworking patungong Alamofire sa pamamagitan ng iisang protocol na NetworkService.

Unti-unting migrasyon — paghahati ng transisyon sa maliliit na hakbang: pag-encapsulate ng lumang module → pagsulat ng tests → paggawa ng bagong module → parallel na pagpapatakbo → pagtanggal ng lumang module. Ang bawat hakbang ay nagtatapos sa matatag na estado ng sistema, na nagpapahintulot sa deployment ng mga pagbabago anumang oras.