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

Probabilmente non sono l'unico che la pensa così. Ma ho quello che tendo a chiamare "La sindrome del programmatore perfetto" che molti potrebbero dire è lo stesso di un perfezionista, ma in questo caso rientra nel campo della programmazione. Tuttavia, il dominio della programmazione è un po 'problematico per una tale sindrome.

Hai mai sentito che quando stai programmando non sei fiducioso o mai abbastanza sicuro che il tuo codice sia pulito e buono codice che segue la maggior parte delle migliori pratiche? Ci sono così tante regole da seguire che mi sento come essere sopraffatto in qualche modo. Non che non mi piaccia seguire le regole, ovviamente sono un programmatore e adoro programmare, lo vedo come un'arte e devo seguire le regole. Ma lo adoro anche io, voglio dire e amo seguire le regole per avere una buona sensazione di ciò che sto facendo sta andando nel modo giusto .. ma vorrei solo avere tutto un po 'più in "controllo" per quanto riguarda le migliori pratiche e il buon codice.

Forse è una mancanza di organizzazione? Forse è una mancanza di esperienza? Forse una mancanza di pratica? Forse è la mancanza di qualcos'altro che qualcuno potrebbe sottolineare? C'è un modo per sbarazzarsi di quella sindrome in qualche modo?

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

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

• Codice corretto
• Codice gestibile
• Codice pulito
• 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?

Fallo funzionare, tutto il resto è quasi irrilevante per risolvere i problemi che devi risolvere. Certo, anch'io soffro di questo. 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 un buon codice . Che cos'è? Che tipo di persone lo scrivono? Come scrivere un buon codice ? È molto semplice. Scrivi il codice che funziona . Il codice di lavoro è un buon codice. Tutto il resto viene dopo.

Naturalmente, quando si scrive codice in professionale, ambiente della squadra, ovvio, leggibile il codice e mantenibile codice diventano sempre più importanti. Tuttavia, il primo compito è ancora farlo funzionare e concentrarsi su quello. Solo allora puoi iniziare a perfezionare e refactoring per meglio - se necessario.

È spesso abbastanza ovvio che la correttezza del codice è molto importante, eppure tutti non riusciamo ad abbracciarne l'importanza durante la scrittura del codice. Tagliamo gli angoli, usiamo l'ottimizzazione prematura, proviamo a scrivere codice elegante anche prima di aver scritto il codice di lavoro . È la natura umana lottare per la perfezione fin dall'inizio, ma la programmazione e lo sviluppo del software sono processi iterativi ed esistono priorità. Quindi, ancora una volta, fallo funzionare , preoccupati di tutto il resto in seguito. Comprendi l'importanza del codice corretto e sforzati di farlo.

Mentre ci sono tonnellate e tonnellate di 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 di soddisfare ogni singolo bit delle buone pratiche. Non vi è alcun sostituto o sostituto per l'esperienza personale. Non puoi evitare le insidie ​​più comuni, indipendentemente dal numero di libri che leggi, dai seminari a cui partecipi o quant'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 gestibile, anche se pensi che alcune modifiche potrebbero renderlo ancora migliore. Ma una volta che, ad esempio, stai cercando di cambiare qualcosa e inciampare in una variabile di cui lo scopo non è chiaro, o una funzione che è troppo lunga per comprenderla, risolvila. Non prima.

Ciò non significa che non dovresti cercare il codice buono e pulito in primo luogo, ovviamente dovresti, ma dovresti considerare il tuo primo tentativo "abbastanza buono" se non dimostrato diversamente.

Penso che il miglior antidoto a questo sia ricordare a te stesso che tutte quelle migliori pratiche e regole di pulizia del codice non esistono per il loro bene, né lo stesso codice.

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

Non mi piace il confronto tra la programmazione e l'arte, ma a questo proposito funziona: anche gli artisti ( specialmente gli autori ) spesso vogliono continuare a lavorare su un pezzo perché c'è sempre qualcosa che non è perfetto. Ma quale valore ha la perfezione quando ritarda la pubblicazione a tempo indeterminato e quindi impedisce 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. Molto spesso, una biblioteca di classe su cui lavori oggi sarà molto diversa per sei mesi lungo la strada. Impari qualche nuova tecnica o trovi uno schema che funziona davvero per te. Finché il codice è facilmente gestibile e leggibile, allora dovresti essere bravo. Idealmente, si avrebbero test unitari per facilitare il refactoring più avanti lungo la strada.

È facile farsi coinvolgere nel rendere perfetto il codice e seguire tutti gli standard a cui puoi pensare. Succede a tutti noi. Guardando il codice che ho scritto un paio di settimane fa mi viene in mente di fare delle modifiche. Aggiungi una proprietà qui, refactoring il metodo lì. E sembra accadere alla fine del progetto. Ma se sei troppo preso dal fatto che potresti finire per creare un bug showtopping. L'ho fatto un paio di volte all'inizio della mia carriera. Un paio di sessioni di correzione di bug 3 AM mi hanno risolto il problema.

Fallo diversamente.

Invece di "cosa si può fare di meglio?" cercare "cosa mi fa incazzare?" fino a quando non succede niente.

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 effettivamente le cose, stai facendo qualcosa di sbagliato. Prova semplicemente a produrre codice il più velocemente possibile e le tue pratiche dovrebbero evolversi per permetterti di farlo.

Fallo funzionare, rendilo pulito, rendilo SOLIDO, rendilo performante.

I primi tre sono un adagio che sposerò ogni volta che qualcuno si chiede come scrivere il codice SOLID su una linea temporale. Quando scrivi per la prima volta una riga di codice, deve semplicemente funzionare, quindi fai quello che devi fare e non farti ingannare. La prima volta che rivisiti una riga di codice, non è più una tantum e dovresti ripulire il codice, rendendolo leggibile e quindi più gestibile. La terza volta che il cursore si posiziona su quella linea, è probabilmente un grosso problema ora e dovresti rifattorizzarlo per aderire alla metodologia SOLID, astrarre dipendenze, implementare schemi e in generale rendere il codice più facile da collegare o da collegare per futuri miglioramenti.

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

Il codice performante è quasi sempre la preoccupazione minore nei linguaggi gestiti dalla memoria (Java, la famiglia .NET, i linguaggi più funzionali, ecc.). In questi ambienti, l'obiettivo è scrivere il codice corretto ("corretto" qui definito come produrre il risultato atteso in tutti i casi previsti, eessere comprensibile e ben strutturato, e quindi mantenibile), e le prestazioni sono secondarie (di solito procederanno in una certa misura dal codice corretto). In tutti i casi, un algoritmo è efficace quando è "abbastanza buono". Ricorda, "l'ottimizzazione prematura è la radice di tutti i mali"; fare ottimizzazioni di cui non sai di aver bisogno non fa altro che perdere tempo, offuscare il codice e in generale impedire i progressi. Deve funzionare prima, quindi 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 fino a quando non lo è, quindi si interrompe .

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

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