YAGNI sa Pag-develop ng App: Ano Ito, Ang Diwa ng Prinsipyo, at Praktikal na Benepisyo

Ano ang YAGNI?

YAGNI (You Aren't Gonna Need It) — prinsipyo ng extreme programming (XP) na nangangahulugang ‘hindi mo ito kakailanganin’. Ang patakaran ay: huwag kailanman i-implementa ang functionality na hindi kinakailangan ng kasalukuyang user stories. Kung ang feature ay hindi kailangan ngayon — huwag itong gawin kahit ‘kung sakali lang’.

Ang termino ay ipinakilala ni Ron Jeffries, isa sa mga co-author ng XP methodology (kasama si Kent Beck). Ipinahayag ni Jeffries: “Ipatupad ang pinakasimpleng bagay na gumagana, at huwag magdagdag ng anuman hangga't hindi ito kailangan.” YAGNI — hindi pagbabawal sa pagpaplano, kung hindi pagbabawal sa napaagang implementasyon.

Ayon sa Standish Group CHAOS Report (2023), 64% ng features sa karaniwang software product ay bihira o hindi kailanman ginagamit. Kung i-extrapolate sa mobile application — mahigit kalahati ng naisulat na code ay hindi nagbibigay ng halaga sa user. YAGNI ay pumipigil sa pag-aaksaya ng resources.

Ilapat ang YAGNI bilang mahigpit na filter: bawat feature ay dapat sumagot sa tanong na “anong problema ng partikular na user ang nilulutas nito ngayon?” Kung walang sagot — hindi kailangan ang feature.

Pagkakaiba ng YAGNI sa katamaran at pag-cut ng corners

YAGNI — hindi pagtanggi sa de-kalidad na arkitektura. Ipinagbabawal ng YAGNI ang pagsulat ng sobrang code, ngunit hindi nito ipinagbabawal ang pagsulat ng tamang code. Kung para sa kasalukuyang feature ay kailangan ang malinis na abstraction layer — gawin ito. Kung hindi kailangan ang layer — huwag gawin. Pangunahing pagkakaiba: ang YAGNI ay tungkol sa functionality, hindi sa kalidad.

Madalas ikalito ng mga developer ang YAGNI sa sinadyang pag-accumulate ng technical debt (technical debt ay laging kompromiso, YAGNI ay prinsipyo ng efficiency). Ang pagkakaiba ay ang technical debt ay alam at dokumentado, habang ang paglabag sa YAGNI ay dagdag na trabaho lamang.

Tanungin ang iyong sarili: “Kung hindi ko gagawin ang abstraction na ito ngayon, gaano katagal ang refactoring kapag kailangan na ito?” Kung mas kaunti ang oras ng refactoring kaysa sa oras ng pagsulat ngayon — ipagpaliban.

Bakit Kritikal ang YAGNI para sa Mobile Projects?

Mobile development ay lalong sensitibo sa paglabag ng YAGNI dahil sa tatlong dahilan: ang laki ng APK/IPA ay direktang nakakaapekto sa conversion ng pag-install, ang oras ng compilation ng mobile projects ay tumataas nang linear sa dami ng code, at bawat dagdag na feature ay nagdaragdag ng failure points. YAGNI — hindi tungkol sa katamaran, kung hindi tungkol sa pokus.

Ipinakita ng pananaliksik ng Google Play Console Data (2023): bawat 10 MB ng laki ng APK ay nagbabawas ng posibilidad ng pag-install ng 1.2%. Ang hindi ginagamit na code ay hindi lang basura sa repository, ito ay direktang pinansyal na kawalan. Sobrang libraries (para sa functionality na ‘baka idagdag mamaya’) ang pinakakaraniwang pinagmumulan ng paglobo ng APK.

Ayon sa Gradle Build Performance Report (2024), bawat karagdagang module sa Android project ay nagdaragdag ng oras ng full build ng 3–7 segundo. Kung magdagdag ng 5 modules ‘para sa hinaharap’ — ang pagtaas ng oras ng compilation ay 15–35 segundo sa bawat build. Sa isang taon, ang team ng 5 developer ay nawawalan ng hanggang 200 oras ng trabaho sa paghihintay ng compilation.

Subaybayan ang laki ng binary sa CI: magtakda ng warning limit (halimbawa, +500 KB bawat commit). Kung tumaas ang laki nang walang bagong feature — ito ay paglabag sa YAGNI na kailangang pag-usapan sa code review.

YAGNI vs Gold-Plating: Mga Praktikal na Halimbawa

Gold-plating: napaagang animation

Gold-plating — pagdaragdag ng functionality na lampas sa requirements sa pagtatangkang ‘pagbutihin’ ang produkto. Karaniwang halimbawa: ang developer ay nagdaragdag ng komplikadong transition animation sa pagitan ng screens, kahit na ang design ay nagsasaad lamang ng simpleng fade. Ang animation ay tumatagal ng 2 araw, hindi ito napapansin ng user, at ang bugs sa iba't ibang device ay sumasama sa proyekto sa loob ng maraming taon.

Ayon sa UX Collective Annual Report (2023), 78% ng mga user ay sinusuri ang application batay sa bilis at stability, hindi sa animation. YAGNI ay nagsasabi: kung ang animation ay hindi nakasaad sa requirements — huwag itong i-implementa. Ang designer ay magdaragdag ng animation kapag talagang kailangan ito para malutas ang UX problem.

Ipatupad lamang ang nasa mockups. Kung hindi iginuhit ng designer ang animation — nangangahulugang hindi ito dapat naroon. Anumang paglihis mula sa mockup ay paglabag sa YAGNI.

Napaagang localization sa 20 wika

Karaniwang pagkakamali ng mga startup: agad na maglaan ng support para sa 20+ wika ‘para sa hinaharap na pagpasok sa international market’. YAGNI ay nagrerekomenda: i-localize lamang ang wika ng kasalukuyang market. Ang pagdaragdag ng bawat bagong wika ay nangangailangan ng oras ng translator, testing ng strings para sa truncation, at debugging ng RTL layout.

Ipinakita ng pananaliksik ng Deloitte Digital Globalization Survey (2022): 60% ng mobile applications ay hindi lumalampas sa unang market. Kung ito ang iyong sitwasyon — ang resources para sa multilingual ay nasayang. YAGNI approach: English (basic) + wika ng target market. Ang iba pa — ayon sa aktwal na pagpasok sa rehiyon.

Gamitin ang YAGNI para sa prioritization: kung ang feature ay hindi kasama sa roadmap ng susunod na dalawang quarters — huwag itong simulan. Ang roadmap ay dapat na dokumentado at aprubado ng product manager.

Paano Ilapat ang YAGNI sa Android at iOS?

YAGNI sa Android: huwag magdagdag ng hindi kinakailangang libraries

Android projects ay dumaranas ng library inflation. Ang mga developer ay nagdaragdag ng Retrofit, OkHttp, Gson, Room, Dagger Hilt, Navigation Component, DataStore — kahit bago pa isulat ang unang linya ng business logic. YAGNI ay nagrerekomenda: magdagdag ng libraries ayon sa aktwal na pangangailangan, hindi preventively.

// Paglabag sa YAGNI: preventive na pagdaragdag ng libraries
// build.gradle (module)
implementation("com.squareup.retrofit2:retrofit:2.9.0")
implementation("com.squareup.retrofit2:converter-gson:2.9.0")
implementation("androidx.room:room-runtime:2.6.0")

// Ang application ay kasalukuyang nagpapakita lang ng “Hello World”

Ang libraries ay dependencies na may sariling komplikasyon. Bawat isa ay nangangailangan ng version updates, migration sa panahon ng breaking changes, at nagpapalaki ng APK size. Magdagdag ng library kapag may partikular na gawain na nalulutas ng library na iyon. Magsimula sa OkHttp (minimal na HTTP client), magdagdag ng Retrofit kapag kailangan ng REST client, at iba pa.

YAGNI sa iOS: huwag pilitin ang SwiftUI

SwiftUI — makapangyarihang framework, ngunit ang pagpapatupad nito ay dapat udyok ng aktwal na pangangailangan. Kung ang proyekto ay magsisimula sa iOS 14+ at minimal ang pangangailangan para sa custom UI components — magandang pagpipilian ang SwiftUI. Kung ang proyekto ay dapat sumuporta sa iOS 13 o nangangailangan ng komplikadong custom gestures — ang UIKit ay nananatiling tamang solusyon. YAGNI ay tutol sa migration sa SwiftUI ‘dahil uso’.

// YAGNI: gamitin ang UIKit hanggang walang tunay na benepisyo mula sa SwiftUI
class ProfileViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        title = "Profile"
    }
}

// Kung kailangan ang SwiftUI — ipatupad sa pamamagitan ng UIHostingController
let swiftUIView = ProfileView()
let hostingVC = UIHostingController(rootView: swiftUIView)

Ang analysis ng Point-Free: “SwiftUI vs UIKit Decision Guide” (2024) ay nagrerekomenda: huwag i-migrate ang umiiral na UIKit screens sa SwiftUI nang walang malinaw na business reason (halimbawa, pangangailangan ng Live Preview para sa designer). Ang muling pagsulat ng gumaganang code ay direktang paglabag sa YAGNI. SwiftUI — para sa mga bagong screen, UIKit — para sa mga umiiral na.

Mga Karaniwang Pagkakamali sa Pagsunod sa YAGNI

YAGNI bilang dahilan ng masamang arkitektura

Ang pinakamapanganib na pagkakamali ay ang paggamit ng YAGNI bilang dahilan para sa masamang arkitektura. “Hindi tayo gagawa ng repository layer dahil YAGNI — isulat na lang ang request diretso sa ViewModel.” Ito ay hindi YAGNI, ito ay pag-accumulate ng technical debt. YAGNI ay nagbabawal ng sobrang functionality, hindi ng architectural integrity.

Ang arkitektura ay investment sa maintainability. Kung sumulat ka ng higit sa 3 screens — ang basic architectural layer (MVVM, repository) ay makatwiran na. Kung 1 screen — maaari kang gumamit ng simpleng approach. Susi: tukuyin ang architectural minimum na kinakailangan para sa kasalukuyang features, at huwag magdagdag ng higit pa.

Paghiwalayin ang mga desisyon sa ‘architectural’ at ‘functional’. Ang architectural decisions (layers, navigation, DI) ay hindi sakop ng YAGNI — kailangan ang mga ito para sa maintainability. Ang functional decisions (features, screenshots, animations) — sakop.

Bulag na pagsunod sa YAGNI kapag nagtatrabaho sa API

Ang isa pang extreme — pagbalewala sa future API contracts. Ang developer ay tumatanggap ng JSON mula sa backend na may 5 fields at nagpe-parse lamang ng 3 dahil “ang iba ay hindi kailangan ayon sa YAGNI”. Problema: kapag nagdagdag ng field ang backend, maaaring masira ang parsing kung nagbago ang response. Solusyon — i-map ang lahat ng response fields, kahit hindi lahat ay ginagamit ngayon.

Ayon sa Meta API Design Guidelines (2023), ang client ay dapat mag-parse ng lahat ng fields na ibinabalik ng server, i-ignore ang hindi ginagamit, ngunit hindi itapon ang buong structure. YAGNI dito ay tungkol sa iba: huwag magdagdag ng pagproseso ng fields na wala pa sa spec, ‘kung sakaling ibalik ng backend’.

I-parse ang buong response structure (lahat ng fields na kasalukuyang ibinabalik ng server). Huwag magdagdag ng pagproseso ng fields na wala sa kasalukuyang API specification. Ito ay balanse sa pagitan ng YAGNI at resilience sa pagbabago.