Modi per rompere la "Sindrome del programmatore perfetto" [chiuso]

Dare priorità . Cominciando dall'inizio. Concentrati su ciò che conta.

Le tue priorità possono variare, ma in generale dovresti preoccuparti di:

• Codice corretto
• Codice gestibile
• Pulisci codice
• Codice semplice ed elegante
• Codice efficiente

Forse in questo ordine. Tuttavia, il primo punto è il più importante. Senza di esso, il codice è inutile. Cosa fai con un programma che non funziona correttamente?

Falla funzionare, tutto il resto è quasi irrilevante per risolvere i problemi che devi risolvere. Certo, anch'io ne soffro. Quello che ho imparato che aiuta è concentrarsi solo sulle soluzioni che funzionano . Questo è sufficiente. Questo è il 99% del lavoro.

Potresti voler pensare a qualcosa come buon codice . Che cos'è? Che tipo di persone lo scrivono? Come scrivere buon codice ? È molto semplice. Scrivi codice che funziona . Il codice di lavoro è un buon codice. Tutto il resto viene dopo.

Naturalmente, quando si scrive codice in ambiente professionale, in team, il codice evidente, leggibile e il codice mantenibile diventano sempre più importanti. Tuttavia, il primo compito è ancora farlo funzionare e concentrarti su quello. Solo così puoi iniziare a perfezionare e rifactoring per migliorare, se necessario.

Spesso è abbastanza ovvio che la correttezza del codice è molto importante, eppure non riusciamo ad abbracciarne l'importanza quando scriviamo il codice. Riduciamo gli angoli, usiamo un'ottimizzazione prematura, noi proviamo per scrivere codice elegante anche prima di scrivere lavorando . È la natura umana a cercare la perfezione fin dall'inizio, ma la programmazione e lo sviluppo del software sono processi iterativi e le priorità esistono. Quindi, ancora, fallo funzionare , preoccupati di tutto il resto. Comprendi l'importanza del codice corretto e cerca di farlo.

Anche se ci sono tonnellate e tonnellate delle cosiddette buone pratiche , penso che il buon senso sia il più importante, pensa al perché le pratiche sono considerate buone, quando e dove applicarle. Non sforzarti però di soddisfare ogni singola parte delle buone pratiche. Non c'è sostituto o sostituto per esperienza personale. Non puoi evitare le insidie più comuni, non importa quanti libri leggi, seminari a cui partecipi o altro. Ciò che conta è imparare facendo, facendo le cose correttamente e divertendosi - ogni volta che è possibile.

Il modo più semplice per evitare questo problema è cambiare solo ciò che fa male. Non lucidare il codice che è corretto, leggibile e manutenibile, anche se pensi che alcune modifiche potrebbero renderlo ancora migliore. Ma una volta, ad es. tentare di cambiare qualcosa e passare a una variabile di cui non è chiaro lo scopo, o una funzione che è troppo lunga da comprendere, risolverla. Non prima.

Questo non significa che non dovresti sforzarti per ottenere un codice buono e pulito, ovviamente, dovresti, ma dovresti considerare il tuo primo tentativo "abbastanza buono" a meno che non sia provato diversamente.

Penso che il miglior antidoto a questo è ricordare a te stesso che tutte le best practice e le regole sulla pulizia del codice non esistono per il loro stesso interesse, né il codice stesso.

Alla fine, ciò che conta più di ogni altra cosa è che il software funziona e può essere usato. E ciò non accadrà se non lo finisci.

Non mi piace il confronto tra la codifica e l'arte, ma a questo proposito funziona: artisti ( specialmente gli autori ) spesso vogliono continuare a lavorare su un pezzo perché c'è sempre qualcosa che non è perfetto. Ma quale valore c'è nella perfezione quando ritarda la pubblicazione indefinitamente e impedisce così a chiunque di apprezzare il lavoro?

La cosa più importante da capire è che il tuo codice cambierà sempre, e c'è sempre spazio per miglioramenti. Nessun codice è mai perfetto. Il più delle volte, una biblioteca di classi su cui lavori oggi sarà molto diversa tra sei mesi lungo la strada. Impari qualche nuova tecnica o trovi uno schema che funzioni davvero per te. Finché il codice è facilmente mantenibile e leggibile, dovresti essere bravo. Idealmente avresti dei test unitari per rendere più facile il refactoring più avanti lungo la strada.

È facile farsi prendere per rendere il codice perfetto e seguire ogni standard che si possa immaginare. Succede a tutti noi. Guardando il codice che ho scritto un paio di settimane fa, mi viene in mente di apportare modifiche. Aggiungi una proprietà qui, rifattora il metodo lì. E sembra che accada alla fine del progetto. Ma se ti senti troppo coinvolto, potresti finire con un bug da show-stop. L'ho fatto un paio di volte all'inizio della mia carriera. Un paio di sessioni di correzione degli errori delle 3 AM mi hanno risolto il problema.

Fai il contrario.

Invece di "cosa si può fare meglio?" cercare "cosa mi fa incazzare?" fino a nulla.

Come programmatore, il tuo compito è produrre codice. Lo scopo delle migliori pratiche è aumentare il tasso di produzione rendendo le cose più facili da capire / fare / ricordare. Se aderire a queste pratiche sta ostacolando in realtà le cose, stai facendo qualcosa di sbagliato. Cerca semplicemente di produrre codice il più velocemente possibile e le tue pratiche dovrebbero evolversi per permetterti di farlo.

Falla funzionare, rendila pulita, rendila SOLIDA, rendila performante.

I primi tre sono un adagio che sposano ogni volta che qualcuno si chiede come scrivere il codice SOLID su una timeline. Quando scrivi per la prima volta una riga di codice, deve semplicemente funzionare, quindi fai ciò che devi fare e non avere fantasia. La prima volta che si rivisita una riga di codice, non è più una tantum e si dovrebbe pulire il codice, rendendolo leggibile e quindi più manutenibile. La terza volta che il cursore si posiziona su questa linea, è probabilmente un grosso problema ora e dovresti rifattorizzarlo per aderire alla metodologia SOLID, astrarre dipendenze, implementare pattern e in generale rendere il codice più facile da collegare o da collegare a per miglioramenti futuri.

L'eleganza del codice deve essere raggiunta quando il programmatore nota un'opportunità ed è generalmente una funzione di semplificazione, pulizia e in generale miglioramento della leggibilità e manutenibilità del codice mentre si seguono i passaggi precedenti. Non è qualcosa da massimizzare .

Il codice performante è quasi sempre la meno importante nei linguaggi gestiti dalla memoria (Java, la famiglia .NET, la maggior parte dei linguaggi funzionali, ecc.). In questi ambienti, l'obiettivo è scrivere correggere codice ("corretto" qui definito come produrre il risultato atteso in tutti i casi previsti, e essere comprensibili e ben strutturati, e così mantenibile), e le prestazioni sono secondarie (di solito procederà in una certa misura dal codice corretto). In tutti i casi, un algoritmo è performante quando è "abbastanza buono". Ricorda, "l'ottimizzazione prematura è la radice di tutti i mali"; fare ottimizzazioni che non sai di aver bisogno non fa altro che perdere tempo, codice offuscato e, in generale, impedire il progresso. Deve funzionare prima, poi una volta che funziona, lo esegui e vedi quanto velocemente funziona. Se non è abbastanza veloce (come definito da un benchmark che è un requisito pubblicato), lo si migliora finché non lo è, e quindi si interrompe .

Devi davvero essere pragmatico sulla programmazione. Sì, a tutti noi piace fare le cose per bene, ma vieni pagato per aver distribuito software funzionante, non per lucidarlo per il resto della tua vita.

L'approccio da adottare è quello di "farcela" nella tua vita professionale. Consegna e vai avanti. Salva il tuo perfezionismo per progetti personali.