La un moment dat am intalnit principiul celor 4 p in programare:
Prepare
Plan
Perform
Perfect
Nu reusesc sa le aplic atat de des pe cat mi-as dori, dar mi-ar placea sa aud si opiniile voastre despre modul vostru de lucru, si ce a-ti gasit ca fiind constructiv in daily work.
Am avut ceva prezentare recent despre optimizare. Din experiență cred că depinde și de proiect. Dacă ai aterizat într-un proiect deja maturizat, ai spațiu puțin de manevră. Nu te va aștepta nimeni să optimizezi de amorul artei. Trebuie să livrezi. Dacă participi la dezvoltarea proiectului from scratch, principiile open-close, LSP și restul îți sunt foarte bune prietene.
100% de-acord, aici e loc poate de gandit o strategie pentru astfel de situatii >> proiect existent.
Am lucrat la proiecte solo cu un codebase relativ mare (jocuri). Si-i adevarata zicala.
Am avut nu stiu cate bucati de cod migalite cu gandul ca “lasa ca o sa le refolosesc mai tarziu”. In 99% din cazuri nu le-am refolosit EVER.
Acelasi lucru si cu research-ul ptr. a stoarce si ultimul strop de performanta. In multe cazuri a fost inutil.
Pe de alta parte insa nu merge nici sa hackuiesti un proiect “la rapid”. Devine buggy hell asap.
Zilele astea urmez niste principii simple ca sa nu cad intr-o extrema sau alta (early optimization sau hacky code):
Daca folosesc ceva de minim 2 ori creez o functie separata. Altfel nu. (unii zic pe SO ca de 3 ori. Nu-s de acord. Daca-ti trebuie de 2 ori probabil o sa-ti trebuiasca si de 3 ori 
)
Nu-mi bat capul sa am obiecte INFINIT reutilizabile sau adaptabile. Aici se pierde timp de cele mai multe ori. Un minimum de extensibilitate e tot ce trebuie. Formula e: functionalitate STRICT pentru contextul actual cu posibilitatea de a fi extinsa mai tarziu.
La capitolul performanta trebuie deasemeni pastrata o balanta. Regula 20/80 e sfanta. 20% efort ptr. a avea 80% performanta. Google, SO si RTFM ptr. best practices in mod rapid.
Cel mai complex aspect IMO e arhitectura codului. Daca vrei sa termini un proiect cap coada de unul singur e un aspect super important.
O greseala e sa planuiesti prea detaliat si sa urmezi planul cu sfintenie. Asta duce la mult cod scris INAINTE sa ai nevoie de el. Am patit-o de multe ori.
Acum urmez o abordare modulara. Plug & play baby.
Singurele chestii pe care le planuiesc si testez inainte sunt componentele critice (quick & dirty).
Io-te asa am reusit sa creez 90% din codebase ptr. un joc maricel (de publicat pe Steam) in 3 saptamani. Inainte mi-ar fi luat luni de zile
Bine, si modul cum e structurat Godot a ajutat o gramada. 
In ce limbaj ai creat jocul?
Restul de 10% o sa iti ia 90% din timp
Vezi tu, poți face o metodă/clasă separată nu doar pentru reutilizare ci pentru a avea o organizare mai bună a codului. Altfel ajungi la mizerii de forma WP, cu metode de sute de linii…
GDScript (pythonic language).
As vrea sa te contrazic dar s-ar putea sa stii tu ceva. 
Nu te contrazic. Cum era vb. aia - daca ai mai mult de 10-20 linii in functie scrie alta.
Dar conteaza si limbajul. Cu 10 linii in Python (sau pythonic language) lansez o racheta in spatiu. Cu 10 linii in JS poate dau drumul la gaz?
Și în PHP cu json_decode() îți faci un obiect dintr-un string JSON. A dat greși? Da. Am încredere în lucrurile făcute de limbaj? Nu.
Da, in obiect sa nu ai incredere insa 
Decodeaza ca array (parametrul 2 pe true) si initializeaza un obiect pe baza arrayului, pe baza unei clase clar definite de tine.
Am trecut prin mail multe proiecte dar am întâlnit cealaltă situație: n-am cum să mai folosesc bucata asta de cod pentru altceva. În majoritatea cazurilor am folosit-o. Programarea “these days” este pentru a scrie o funcționalitate/bucată de cod odată și a o refolosi mai încolo (am pus “these days” între ghilimele pentru că cred că pentru asta e programarea în sine de fapt, pentru a refolosi codul). Nimeni nu prea mai inventează roata.
Foarte bună observație. În prezentarea pe care am făcut-o legat de optimizare ziceam că nu le poți avea pe toate: și rapiditate, și puține resurse consumate, și aplicație lightweight, și, și, și… Acolo intervine arhitectura, cum aplici design patterns și principiile OOP pentru a obține the most of it.
Acum ceva ani am citit The Mature Optimization Handbook de Carlos Bueno, și multe din chestiile menționate mai sus erau explicate și acolo pe larg. I-am dat 4 stele din 5, deci cred că mi-a plăcut (deși nu-mi amintesc stilul în care era scrisă, ci doar ideile).
Idea principală cu care am rămas din cartea aia: nu optimiza niciodată ceva ce nu poți măsura (să vezi ce efect are). Asta presupune că nu faci nici o optimizare de arhitectură înainte să măsori și să confirmi că problema (bottleneck-ul) e acolo unde presupui tu și că varianta optimizată te scapă de probleme. Prima versiune a orice trebuie să fie cod curat, cât mai simplu și intuitiv. Să meargă e mai important decât performanța. Dacă apar probleme de performanță rescrii și renunți la simplitate și claritate în locurile unde ai măsurat că sunt probleme (profiling). Nu faci compromisul ăsta înainte de a știi unde sunt probleme.
Pe proiecte începute de la zero, optimizarea prematură e inutilă de cele mai multe ori pentru că nu se cunosc specificațiile complete sau finale (în general se schimbă de vreo 2-3 ori până la forma finală). Așa că nu contează ce arhitectură optimizată ai planificat tu, tot o cârpeală o să ajungă după 2-3 modificări și probabil optimizarea o să facă modificările respective și mai grele.
Am ajuns să urăsc micro-optimizările. La cât de greu de întreținut și înțeles fac codul nu merită sacrificiul. Dacă le face compilatorul/parser-ul bine, dacă nu, atunci prefer 1-5% extra RAM/CPU cu un cod mai ușor de lucrat și înțeles.
Cel mai optim cod îl poți scrie atunci când cunoști foarte bine cerințele și posibilele soluții. Adică la o rescriere de soft, preferabil unul care rulează stabil de ceva timp. Știi deja ce se cere, știi unde ai avut probleme înainte etc. Și în cazurile de genul ăsta, optimizările sunt de fapt o arhitectură mai adaptată problemei, nimic special în cod.
Foarte bine punctat, IMHO. Si idea ta ma duce cu gandul la:
“If u can’t measure it, u can’t control it”.
