Optimizează pentru schimbare, nu pentru performanță: de ce DX e noua metrică principală

Dezvoltatori, pregătiți-vă pentru erezie: se pare că a alerga după fiecare milisecundă în runtime nu e întotdeauna cea mai bună strategie. Autorul blogului EchoOff propune să mutăm focusul de la performanța aplicației la... performanța dezvoltatorului. Da, exact acel DX pe care îl lăudăm atât de mult, dar rar îl implementăm.

Comparația cu IKEA se potrivește de la sine: poți asambla un dulap într-o oră, dar dacă instrucțiunile sunt în chineză și cheia e hexagonală, peste șase luni se va destrăma. La fel și cu codul: rapid, dar inflexibil, e o bombă cu ceas. Autorul sugerează să optimizăm pentru schimbare: să scriem cod ușor de refactorizat, nu care se execută în 0.01 ms.

Argumentul principal: afacerea se schimbă mai repede decât reușiți să faceți profiling. În timp ce vă lustruiți bottle-neck-urile, concurenții au lansat deja o funcționalitate pe un cod strâmb, dar funcțional. Și da, „datoria tehnică” nu e întotdeauna rea, dacă se amortizează prin viteza schimbărilor. Desigur, dacă nu scrieți software pentru nave spațiale, unde fiecare nanosecundă contează.

Sfat practic: începeți cu un CI/CD care nu se strică la primul commit și o arhitectură modulară unde înlocuirea unei biblioteci nu necesită rescrierea întregului proiect. Și amintiți-vă: codul vostru trăiește mai mult decât startup-ul vostru (mai ales dacă startup-ul e un pet-project).

Comentariul studioului METABYTE: Și noi am alergat după codul perfect, până când am înțeles că clientul vrea un produs funcțional ieri. Acum optimizăm pentru schimbare — și CI/CD-ul nostru nu pica nici după commit-ul de vineri.