Basurang code at gulo sa mga mobile project — mga palatandaan at refactoring

Ano ang basurang code sa pag-develop

Basurang code (din spaghetti code, gulo, big ball of mud) — ay isang metapora para sa isang codebase na nawalan ng istraktura at naging isang magulong buhol ng mga dependency. Sa ganitong code, ang bawat pagbabago sa isang lugar ay sumisira ng ibang lugar, at ang pagdaragdag ng bagong functionality ay nagiging isang mapanganib na gawain.

Sa mobile development ang basurang code ay lubhang kritikal: ang app na binuo sa "gulo" ay nagsisimulang bumagal, mag-crash sa mga lumang device at mahirap makadaan sa code review. Ang iOS project na walang arkitektura ay maaaring hindi makapasa sa App Review dahil sa kawalan ng stability.

Ayon sa datos ng Stripe, ang mga developer ay gumugugol ng hanggang 42% ng oras ng trabaho sa pagbabasa at pag-unawa ng umiiral na code. Sa mga proyektong may basurang code, ang bilang na ito ay lumalampas sa 60%, na ginagawang lubhang hindi episyente ang pag-develop.

Pinagmulan ng mga termino

Spaghetti code — ang pinakamatandang termino, lumitaw noong 1970s. Inilalarawan nito ang code na may magulong control flow, na kahawig ng magkagusot na spaghetti.

Big ball of mud (malaking bola ng putik) — terminong ipinakilala nina Brian Foot at Joseph Yoder noong 1997 upang ilarawan ang mga sistema nang walang malinaw na arkitektura na "lumalaki" nang magulo.

Bakit mapanganib ang basurang code para sa negosyo

Basurang code nagpapabagal sa paglulunsad ng mga bagong feature sa merkado. Ang koponan ay gumugugol ng oras hindi sa paglikha ng halaga, kundi sa mga pagtatangka na maunawaan kung paano gumagana ang umiiral na code at hindi masira ang anuman.

Ayon sa datos ng McKinsey, ang mga kumpanyang may mababang kalidad ng code ay gumagastos ng 20-40% higit pa sa pagpapanatili ng produkto, at ang bilis ng paglulunsad ng mga bagong feature ay 2-3 beses na mas mababa kumpara sa mga kumpanyang may mataas na kalidad ng code.

Mga palatandaan ng basurang code at paano ito makilala

Makilala ang basurang code ay posible sa pamamagitan ng isang set ng obhetibong mga palatandaan, na ang ilan ay sinusukat nang awtomatiko. Kung mas maraming palatandaan ang magkatugma — mas seryoso ang problema.

Sa industriya ginagamit ang mga metric ng kalidad ng code tulad ng Halstead Complexity, Maintainability Index at Technical Debt Ratio. Ang kaalaman sa mga metric na ito ay tumutulong sa obhetibong pagtatasa ng kalagayan ng codebase.

Copy-paste (pag-uulit ng code)

Pinakakaraniwang palatandaan ng basurang code — umuulit na mga block ng code. Sa halip na mag-extract ng karaniwang function, kinokopya ng mga developer ang code mula sa isang lugar patungo sa iba na may minimal na pagbabago.

Normal na antas ng pag-uulit ay itinuturing na hanggang 5%. Kung ang pag-uulit ay lumampas sa 15% — ito ay isang seryosong senyales. Ang mga kasangkapan tulad ng Simian at PMD Copy Paste Detector ay tumutulong sa awtomatikong pagtuklas ng copy-paste.

Mahahabang method at klase

Ang isang method na mahigit sa 100 linya — malinaw na palatandaan ng basurang code. Ang ganitong method ay karaniwang gumagawa ng labis at lumalabag sa prinsipyo ng isang responsibilidad (Single Responsibility).

Ang mga klase na may higit sa 1000 linya ng code ay problematiko rin. Naglalaman ang mga ito ng hindi kaugnay na functionality, na nagpapahirap sa pag-test, pag-unawa at pagbabago ng code.

Mataas na cyclomatic complexity

Cyclomatic complexity ayon kay McCabe (Cyclomatic Complexity) — isang metric na nagpapakita ng bilang ng mga independiyenteng landas sa code. Ang halagang higit sa 15 ay itinuturing na problematiko.

Ang mga method na may complexity na higit sa 30 — "danger zone". Naglalaman ang mga ito ng napakaraming branching, hindi sila maaaring i-test o maunawaan nang walang malalim na pagsusuri.

Mga dahilan ng paglitaw ng basurang code

Basurang code ay hindi lumilitaw "nang kusa" — ito ay palaging resulta ng mga partikular na proseso at desisyon sa koponan. Ang pag-unawa sa mga dahilan ay nagbibigay-daan upang maiwasan ang paglitaw nito sa hinaharap.

Ayon sa datos ng JetBrains Developer Ecosystem 2024, 67% ng mga developer ay umamin na sumulat sila ng mas masamang code kaysa sa kanilang makakaya dahil sa kakulangan ng oras. Ito ang pangunahing dahilan ng pag-ipon ng teknikal na utang.

Pagmamadali at deadlines

Pinakakaraniwang dahilan — masikip na deadlines. Sumusulat ang koponan ng code "kung ano ang lumabas", para lang maabot ang deadline. Ang refactoring, test at code review ay ipinagpapaliban "para sa susunod".

Ang problema ay ang "susunod" ay hindi dumarating — sa susunod na sprint ay lilitaw ang mga bagong deadline at ang teknikal na utang ay naipon parang snowball.

Kawalan ng code review

Walang code review, bawat developer ay sumusulat sa kanyang sariling istilo, gumagamit ng kanyang sariling pattern at nag-iiwan ng kanyang sariling "bitag". Sa paglipas ng panahon, ang codebase ay nawawalan ng pagkakapareho.

Ang mga koponang nagsasagawa ng mandatoryong code review para sa bawat pull request ay may 60% na mas kaunting depekto sa produksyon, ayon sa pananaliksik ng SmartBear 2024.

Mahinang arkitektura mula sa simula

Kung ang proyekto ay nagsisimula nang walang malinaw na arkitektura, ang basurang code ay hindi maiiwasan. Ang mga unang "mabilis na solusyon" ay naglalagay ng pundasyon kung saan mahirap magtayo ng isang bagay na may kalidad.

Sa mobile development, ang pagpili ng arkitektura (MVC, MVP, MVVM, Clean Architecture) ay dapat na isang malay na desisyon na ginawa bago magsimulang sumulat ng code, hindi resulta ng ebolusyon.

Mga paraan ng paglaban sa basurang code

Paglaban sa basurang code ay nangangailangan ng sistematikong approach at disiplina ng buong koponan. Walang iisang kasangkapan o praktika na makalulutas ng problema — kailangan ang isang hanay ng mga hakbang.

Ang pangunahing prinsipyo — huwag payagan ang basurang code sa yugto ng pagsulat, sa halip na ayusin ito mamaya. Ang pag-iwas ay palaging mas mura kaysa sa refactoring ng umiiral na "gulo".

Coding standards

Pinag-isang istilo ng code — batayan para maiwasan ang basurang code. Ang coding standards (Code Style) ay dapat na idokumento at awtomatikong suriin ng mga linter.

Para sa iOS ginagamit ang SwiftLint, para sa Android — Ktlint at Detekt. Ang pag-configure ng mga patakaran sa file ng configuration ay nagbibigay-daan sa awtomatikong pagtanggi sa mga pull request na lumalabag sa mga pamantayan.

Regular na refactoring

Refactoring — hindi pag-aayos ng bug, kundi pagpapabuti ng istraktura ng code nang hindi binabago ang pag-uugali nito. Dapat itong maging regular na bahagi ng proseso ng pag-develop, hindi isang hiwalay na proyekto.

Inirerekomenda na maglaan ng 20% ng oras ng bawat sprint para sa refactoring at pagbabayad ng teknikal na utang. Pinipigilan nito ang pag-ipon ng "gulo" at pinapanatili ang bilis ng koponan sa pangmatagalan.

Mandatoryong code review

Bawat pull request ay dapat dumaan sa review ng kahit isang developer. Ang code review ay hindi lamang nakakatuklas ng bug, kundi pati na rin ng mga paglabag sa arkitektura, estilo at potensyal na pinagmumulan ng basurang code.

Magandang praktika — checklist para sa code review na sumasaklaw sa pagsusuri ng copy-paste, haba ng method, cyclomatic complexity at test coverage. Kung walang checklist, ang mga reviewer ay nakakaligtaan ng hanggang 50% ng mga problema.

Mga kasangkapan sa paglilinis ng codebase

Mga modernong kasangkapan sa pagsusuri ng code ay nagbibigay-daan sa awtomatikong pagtuklas ng basurang code, pagsukat ng teknikal na utang at pagkontrol ng kalidad. Ang pagsasama ng mga kasangkapang ito sa CI/CD pipeline ay nagbibigay ng patuloy na pagsubaybay.

Inirerekomenda na gumamit ng hindi bababa sa isang static analyzer at isang kasangkapan sa pagsukat ng metric. Bukod pa rito, maaaring ikonekta ang isang platform para sa pag-aggregate ng datos ng kalidad ng code.

Mga static analyzer

• SonarQube — nangungunang platform para sa pagsusuri ng kalidad ng code, sumusuporta sa 30+ wika at nagbibigay ng mga metric Technical Debt Ratio
• ESLint — pamantayan para sa JavaScript at TypeScript, na-configure sa pamamagitan ng configuration file at isinama sa IDE
• SwiftLint — mandatoryong kasangkapan para sa iOS projects, sinusuri ang pagsunod sa Swift Style Guide

Ayon sa datos ng SonarSource, ang mga koponang gumagamit ng static analysis ay nagbabawas ng bilang ng bug sa produksyon ng 30% sa unang quarter pagkatapos ng implementasyon.

Mga kasangkapan sa pagsukat ng metric

CodeClimate at Codacy — mga platform na nag-a-aggregate ng mga metric ng kalidad ng code, sumusubaybay sa dinamika at nagpapakita ng "hot spots" — mga file na may pinakamalaking teknikal na utang.

Para sa mga proyekto ng Android, ang Detekt ay nagbibigay ng higit sa 100 built-in na patakaran sa pagsusuri, kabilang ang pagsusuri ng cyclomatic complexity, haba ng method at pag-uulit ng code.