Nekaj praktičnih vprašanj iz programiranja

Tiste, ki se poklicno ali pa kako drugače ukvarjate s programiranjem, vas lepo prosim, da odgovorite na nekaj vprašanj. Zelo vam bom hvaležen za vaš input.

1. Ko razvijate, ali se držite kakšnega neustaljenega oz. malo poznanega postopka? Če ja, ga lahko opišete?
2. Ko pišete kodo, ali kupčkate sorodne metode / razrede v eno samo dolgo datoteko? Pod dolgo osebno smatram 500+ vrstic kode. Ali se ogibate dolgih datotek? Ima vaš projekt ogromno datotek z malo kode?
3. Ko prepoznate neko deljeno obnašanje v kodi, se poskušate za vsako ceno držati koncepta DRY in predelati kodo? Če da, do kje je meja? Ali razbijete metodo / funkcijo do najmanjšega deljenega atoma in posledično naredite ogromno majhnih metod?
4. Koliko časa zabijete za malenkosti pri razvoju? Kaj so primeri, ki jih smatrate kot brezvezne malenkosti, ki nimajo veze s ciljem projekta, ki ga razvijate oz. postanejo te škodljive? Na misel mi pridejo razna preimenovanja datotek in premature optimization.
5. Če uporabljate dokumentacijo kode (kot npr. Javadoc) ali to dokumentacijo napišete preden spišete metodo, vmes ali na koncu?
6. Ko kodirate, ali za vsak nov logični korak oz. skupek preprostih korakov v vaši kodi poženete program / debugger, da preverite če vse "ok dela", preden nadaljujete? Ali najprej zasnujete celoten program "na približno" in šele nato poskusite pognati program?
6. Testiranje: ali za pisanje testov uporabljate framework, ali pa vam je test zgolj še en mini vanilla programček/skripta kot nek koristen dodatek vašemu main projektu?
7. Za tiste, ki ne pišete testov: kako biti siguren v lastno kodo ob spremembah? Ali točno veste, kaj je treba »sprobat«, da ste kolikor toliko sigurni v delovanje kode? Če ne pišete testov, kaj je razlog za to?

LP :)

2. Več datotek ampak ne pretiravam, vsekakor ne en class za vsako datoteko, izguba cajta.
3. To se ne dogaja v praksi, v praksi se program spiše čimprej da dobiš proof of concept potem pa narediš bottleneck test da se vid če je treba kej spreminjat.
4. Včasih me OCD nabriše in ja zapravljam čas pr takih stvareh. Ne vem kolk časa.
5. dokumentacijo pišem kot komentarji v kodi. Odvisno od programskega jezika, če je verbose in če poimenuješ metode pravilno ponavadi sploh ni treba.
6. Pišem dokler mi paše, ko mi zmanka idej zaženem debugger.
7. Odvisno od aplikacije, ponavadi ne pišem testov, tuki je spet velik odvisn od jezika.