BANZAI!

CODE LIKE A SAMURAI! Sa letran, tuturan keo na dpat ang isang MP (Machine Problem) ay dapat tapusin ASAP. So, ang ginawa natin ay diretso code, sbay na ang prototyping at error-correction and most of the time kung ano ang prototype un narin ang final build. At syempre, wlang refactoring & optimizations..

Hm. Ok, siguro ako nlng ang nka intindi ng mga sinabi ko (4 da curious: google Software Engineering)

Pero basically, hindi dapat ganun. Bad practice un, at kung gagawin nyu un sa thesis nyo (or worse, sa labas ng letran like your professional work) patay kau. Ang hirap idebug ng ganung klaseng code, lalo na pag mahaba na. Makakalimutan mo ung mga code na dapat ay tapus na. (un pala ay hindi pa)

Ano ba dapat? Sino dito nkapanood na ng mga anime na may mga samurai? Diba mapapansin nyo na pag nagduduelo sila, nkatayo lng sila, pinagaaralan ang kalaban and after a few minutes, BAM! Isang mabilis at madugong sword slash, saby mkakangiti pa ung kalaban bago sya babagsak... hahaha

dpat ang programming ganon din:

Design. DEVELOP ONCE. Debug.

Isulat sa papel ang features para hindi makalimutan at HINDI MADAGDAGAN. Kung ano ang nsa papel, un at un lang ang dpat features. Focus, Less Code = Less Errors (See last TnT) Kung hindi ka sigurado kung kaya mo, gawa ka ng prototype ng prublema mo. No user interface, kung pwede sa Debug Console lang, mas mganda. Wag mong ipagpatuloy ang prototype - pwede kumuha ng code dun, pero hindi un ang final build.

Pag ok na ung design, DEVELOP ONCE. One strike lang dapat. Isang pasada. Hindi ko sinasabing tapusin mo ng isang araw. Pwedeng isang buong lingo - pero dapat focused ka sa coding. Kung may gusto ka idagdag, WAG, unless kailangan talaga - kung hindi life & death, WAG.

At syempre, kung hindi kaya, pwede bawasan ang nsa design. ^^ Pagkatapos ng madugong duelo, wipe yer sword and walk away like a samurai.. (pero wag kakalimutan mag debug!) wahahaha :P