A lényeg az, hogy hogyan is kell otthon projectet programozni :)
Nincs 100%-os hatékonyság. Legyen egy külön hely az abandonolt projecteknek, ahonnan egy-egy jobb ötletet vissza lehet túrni. Amikor írja az ember, soha nem tudja, hogy évek múlva kell-e megint a kis cucc/framework amit ilyen-olyan okkal félbehagy az ember.
Szentháromság. Amelyik kódon nincs pár soros (nem túl hosszú, nem túl rövid) komment, az halott. Kár is írni, mert ha nagyon jó kód lesz (azt és úgy csinálja ahogy kell), akkor úgyis ráteszed a kommentet, ha meg nem, akkor akkor soha nem fogod tudni, hogy mit akart csinálni eredetileg. Ha nincs ott a komment előre, akkor nem vagy tisztában a feladattal, amit meg akarsz valósítani. Ha tisztában vagy, miért nem írod oda (vagy a referenciát a specifikációra, bár annak sok köze nincs a dologhoz, mert 3 dolog van: 1: mit csinál a kód valójában; 2: mit szerettél volna, hogy csináljon; 3: mi volt a specifikációban, ami közben változhat, bizonyos részei nincsenek szem előtt, a non functional requirementeket nem mindenki ismeri....)
Nincs ideiglenes megoldás. Verziókontrolba csak jó kód menjen. A szar kódért, ha elveszik, nem kár, hiszen a rászánt idő úgyis megtérül, mert jobban átlátod a kódot, mikor készreírod. Gábort idézve: az ideiglenes megoldás mindíg a végleges. Ez azért működik így, mert az ideiglenes megoldást pszichésen elfogadja az ember megoldásnak, és a változásra nem lesz motiválva. Működik ez, ha van valahol valaki, aki hideglelős lábrángást kap ettől a megoldástól, és oda is tud hatni (code review, customer QA...)
Evolúció. Gondold végig mielőtt írod a kódot. Ha nem tudod mit akarsz csinálni, akkor újra és újra átírod, ami egy evolucionáris kódot eredményez, amiben néhány sor indoklása az lesz, hogy ezt azért csináltam így (ilyen szarul), mert akkor még nem tudtam, hogy (mit kéne csinálni, hogy kéne csinálni). Az evolució fasza dolog, ha van erőforrásod pazarolni. Ha spórolni akarsz az erőforrásokkal (az időddel, a lendületeddel, hogy kitartson a project végéig) akkor tervezni kell.
deadline nem kell, de milestone igen. Az otthoni fejlesztéseket legjobban a scrummal lehet kordában tartani. A következő milestone-nak lehet becsült deadline-ja, de fontosabb az, hogy tudd, mit akarsz most megcsinálni. Időd úgyse lesz folyamatosan (meló, lustasági rohamok, vágyakozás a normális élet és a napsütés után, romlott pizza a hűtő mélyéről mind-mind eltereli az ember figyelmét). Jó, ha az ember tudja, hogy hova tart, és milyen lépésekben fog eljutni oda.
Önkritika, avagy a bug reporting. Az az alkalmazás, ami nem ad egy gyors, egyszerű és alapos módot a bug reportálására (log, trace, beépített reporting tool), az úgy csinál, mintha tökéletes lenne, és nem csak technikailag, de a jövőbeni user igényeknek is annyira elébe megy, hogy soha nem akarnak majd feature-t bejelenteni hozzá. Ha normális világban élnénk, akkor lenne egy sourceforge project arra, hogy ahogy a log4j-t beépítheted a kódba, úgy a bug management tool-t is lehessen integrálni. F1 = help; F10 = report bug. Bár nálam a bug reporting inkább a help része, hiszen ha valaki befut egy bug-ba, akkor alap, hogy segítséget kér, vagy szólni akar, hogy ez most akkor így akar működni? A help oldalon egyből és jól láthatóan ott kell lenni a reportingnak.
Ízlések és pofonok különbözőek. Amikor valamit valahogy megcsinál az ember, legyen azzal tisztában, hogy más máshogy csinálná meg. Az önkritikára visszautalva be kell látni, hogy valaki valahol, valamikor okosabb nálunk. A nagyon szerényteleneknek üzenem, hogy van náluk is okosabb ember: a jövőbeni önmaguk ^_^ Ennek szellemében kellő alázattal közelítsünk a problémához, hogy a jövöbeni énünket ne bosszantsuk fel a hülyeségünkkel.
Kísérleti nyulakat külön ketrecben, elkülönítve tartunk. Tudd, hogy mikor kísérletezel, és mikor írsz készre valamit. Ha már tudod, hgoy kell csinálni, nyugodtan vegzálhatod a kódot, de amíg bármi bizonytalanságot érzel az erőben, addig ne erőlted, mert vagy sok munka lesz kiszedni/kijavítani, vagy örökre bent marad, és mérgezi a kódot.
No comments:
Post a Comment