come valutare il proprio progetto

La domanda è così generica, che le risposte riguarderanno un punto (come "non copiare codice copia-incolla", "un metodo deve fare una e una sola cosa", "commentare correttamente il tuo codice", ecc. ), o essere anche troppo generico, come il mio:

Ci sono due modi per valutare il tuo progetto.

• Il primo è ovviamente dare questo progetto a uno sviluppatore più esperto e contare il numero di WTF durante la revisione.

( origine )

Il problema con questo approccio è che più lo sviluppatore è esperto, migliore sarà la recensione, ma riceverai più critiche da parte di uno sviluppatore più esperto, quindi potrebbe essere davvero scoraggiante e deprimente. D'altra parte, se scegli uno sviluppatore che non vuole criticarti troppo o non ha molta esperienza, la sua recensione potrebbe non essere troppo utile.

• Il secondo modo è attendere quando acquisirai più esperienza, quindi rivedere il tuo progetto, ottimizzando, rifattorizzando e modificando il codice.

Puoi quindi determinare una durata di vita del tuo codice e provare a controllarlo regolarmente. Per esempio, nel mio caso, la durata della vita è di un anno: significa che posso modificare il codice che ho scritto sei mesi fa, ma se il codice è stato scritto due anni fa, ha una strong possibilità di essere gettato, quindi riscritto completamente , dal momento che fa schifo troppo.

Per riprendere, non ci sono modi per valutare veramente il tuo codice. è perfetto per te nel momento in cui lo scrivi. Ma lo stesso codice è non corretto se esaminato da uno sviluppatore più esperto, e questo stesso sarà cattivo quando lo esaminerai dopo aver appreso e capito nuove cose.

In altre parole, esiste un no obiettivo per valutare la qualità del codice : puoi solo valutare la qualità del codice (e quindi le tue abilità) relativamente al codice di altri sviluppatori (e te stesso dopo aver appreso più cose).

Fai Test-Driven Development , non solo ti aiuterà a testare tutto è giusto e dare il tuo open -spoglia il pubblico un senso di stabilità, ma ti costringe anche a scrivere codice modulare, meglio architettato e più raffinato.

Se stai cercando una risposta semplice, ricorderei sempre D.R.Y. Non ripetere te stesso. Se hai copiato e incollato il codice da un'area all'altra, probabilmente stai sbagliando. Taglia e incolla va bene, copia e incolla non tanto. Inoltre, se il tuo codice è difficile da testare, sarei preoccupato per il design.

Penso che quando si ha a che fare con OOP una buona idea da tenere a mente è:

• Mantieni la classe leggera, leggo alcuni in cui questa quoute: "Rendilo semplice stupido"
• Di fronte a una certa pace del codice che a tuo avviso potrebbe richiedere flessibilità. È sempre bene dargli un po 'di tempo e verificare la presenza di modelli di progettazione che possono aggiungere un po' di bontà alla tua soluzione (non te ne pentirai)

Qualche seconda risposta ...

@MainMa Ovviamente c'è, in realtà ci sono molti modi per valutare e valutare la qualità del software, quelli sono processi di sviluppo del software che vanno dalla scrum altamente considerata, alla PSP meno pratica e più rigida (ma forse più obiettiva) ( per codice personale) & TSP (per il codice squadra).

Per prima cosa, è necessario definire il tipo di fattore di qualità del software che si sta cercando, quindi perseguirlo con la destra utensili. Per il codice personale, prova il Personal Software Process ma butta via i moduli fugly di carta per la documentazione moderna come UML, BPMN, ecc. O applica anche Sfrutta in modo personale .

@gruszczy Forse con il tuo caso, cercherei un repository di codici che ospita un sito che supporta un buon flusso di lavoro di revisione del codice, come github .

recensioni di codice e TDD , penso che siano alcune delle migliori pratiche che si verificano nei progetti open source in questo momento , perché entrambi mantengono il codice vivo e sano