Nacházíte se:
PHP » Programátorské zkratky, aneb principy programátora ve zkratkách DRY, KISS, YAGNI a další 
Programátorské zkratky, aneb principy programátora ve zkratkách DRY, KISS, YAGNI a další
Než něco dělám měl bych si promyslet best practices a zohlednit to, v čem se spálili ostatní nebo naopak co ostatním pomohlo. To platí na každý obor. Programátoři však tyto principy zachycují v mnoha zkratkách.
KISS - Keep It Simple Stupid
Vždy jednej v souladu s kontextem a okolnostmi problému. Nekombinuj co není potřeba. Nedělej složitější to co není. Navrhni vždy řešení, které je efektivní v souladu s okolními podmínkami.
DRY - Don’t Repeat Yourself
Pokud něco děláš podruhé a používáš CTRL+C a CTRL+V je něco špatně! Neduplikuj kód, pokud jde něco vytknout před závorku udělej to! Využívej principy OOP.
YAGNI - You Ain’t Gonna Need It
Nestav nic co není potřeba. Dívej se do budoucnosti v rozumném horizontu. Zvaž jestli někdy využiješ přidanou funkci, zvaž jestli ti v budoucnu spíše nezkomplikuje život.
CoC - Convention over Configuration
Drž se konvencí, usnadňuje to orientaci v kódu a snižuje nutnost znát dokonale pozadí kódu. Programátor nemusí dělat zbytečná rozhodnutí, pokud se kód chová standardně podle očekávání. Není nutné se učit všechny konfigurační direktivy a postupy jak zajistit požadované chování.
Znáte ještě nějaké poučky, principy, kterými by se měl dobrý programátor řídit?
Snad FUBAR? Ale tady si nejsem jistý, někdo uvádí fucked up but all right, někdo fucked up beyond all repair, což se mi zdá, že je úplně jiný význa?
komentáře
RSS Komentáře
Tu by chcelo to „v rozumnom horizonte“ zvyraznit. Nemozem si pomoct ale tento princip pocujem v poslednej dobe prilis casto, a castokrat v zlom kontexte. Mne osobne este nikdy neprislo naskodu ked som si nakodil nieco do buducna, skor naopak. Tak isto pri vacsich projektoch ked sa clovke zamysli a implementuje nejaku funkcionalitu skorej tak mu to moze neskor ulahcit pracu.
Ale to sa uz asi sklbuje vyssie popisane TBC, spravny navrh APP a DB apod. Kazdopadne niekedy je lepsie si nejake tie drobnosti (rozumne) nakodit a pripravit.
já nesouhlasím, bojuji hodně s tím, abych tento princip dodržoval a čím víc se nutím tím méně mám stresu
každá funkčnost určitým způsobem je pro projekt svazující, klade určitá omezení, kdyby už ne žádné tak minimálně nutí programátora přemýšlet jestli nějakým dalším krokem nenaruší něco jiného
pracuji na vlastním systému, který je vyvíjen po dobu tří let, neuvěřitelný problém jsou funkce, které využívá např. jen jeden zákazník a zvykl si na ně, vznikli bonusem, jako vedlejší efekt něčeho, bylo velice snadné je tam dodělat, proč ne
jenomže vývoj projektu si vyžádal nefunkčnost této funkce, která pro celkový koncept vůbec není důležitá, stojíme před otázkou, že buď musíme zajistit zpětnou kompatibilitu projektu pro chod této funkce nebo musíme tuto funkci opravit, až jich budete takových mít 30 už bude každá změna problém
pochopitelně zákazník si za své peníze nenechá nic vzít! už mu nevysvětlíte, že ta funkce není žádoucí! takže z původního bonusu se stává do budoucna sleva uplatňována zákazníkovi za to, že mu bereme něco co jsme udělali z dobré vůle (nebo z blbosti)
YAGNI
No jo v takomto pripade je to dost „blba“ – osemetna situacia, prave preto vravim, ze to „v rozumnej miere“ resp. horizonte je velmi dolezite pri tomto principe. Niekedy vsak pomoze masivne TBC pri kazdom vacsom projekte (alebo projekte, ktory ma tendenciu prerast na vacsi), pretoze kvalitny navrh moze ulahcit pracu do buducna a clovek sa potom do tebou opisovanej situacie dostane len velmi zriedka alebo vobec.
TBC- Think Before Coding