Su quale pratica di programmazione che una volta ti piaceva hai cambiato idea? [chiuso]

Mentre programmiamo, sviluppiamo tutti pratiche e modelli che utilizziamo e su cui facciamo affidamento. Tuttavia, nel tempo, man mano che la nostra comprensione, maturità e persino l'utilizzo della tecnologia cambiano, ci rendiamo conto che alcune pratiche che una volta pensavamo fossero ottime non sono (o non sono più applicabili).

Un esempio di una pratica che ho usato una volta abbastanza spesso, ma che negli ultimi anni è cambiata, è l'uso del modello di oggetti Singleton .

Grazie alla mia esperienza e ai lunghi dibattiti con i colleghi, sono arrivato a rendermi conto che i singleton non sono sempre desiderabili : possono rendere i test più difficili (inibendo tecniche come il beffardo) e possono creare accoppiamenti indesiderabili tra le parti di un sistema. Invece, ora uso fabbriche di oggetti (in genere con un contenitore IoC) che nascondono la natura e l'esistenza dei singleton da parti del sistema che non si preoccupano o hanno bisogno di sapere. Invece, si basano su una fabbrica (o un localizzatore di servizi) per acquisire l'accesso a tali oggetti.

Le mie domande alla comunità, nello spirito di auto-miglioramento, sono:

• Quali schemi o pratiche di programmazione hai riconsiderato di recente e ora cerchi di evitare?
• Con cosa hai deciso di sostituirli?

//Coming out of university, we were taught to ensure we always had an abundance 
//of commenting around our code. But applying that to the real world, made it 
//clear that over-commenting not only has the potential to confuse/complicate 
//things but can make the code hard to follow. Now I spend more time on 
//improving the simplicity and readability of the code and inserting fewer yet 
//relevant comments, instead of spending that time writing overly-descriptive 
//commentaries all throughout the code.

Punti di ritorno singoli.

Una volta ho preferito un unico punto di ritorno per ogni metodo, perché con quello potevo garantire che qualsiasi pulizia necessaria dalla routine non fosse trascurata.

Da allora, sono passato a routine molto più piccole - quindi la probabilità di trascurare la pulizia è ridotta e di fatto la necessità di pulizia è ridotta - e ho scoperto che i primi ritorni riducono l'apparente complessità (il livello di annidamento) del codice. Gli artefatti del singolo punto di ritorno - mantenere le variabili "risultato" in giro, mantenere variabili flag, clausole condizionali per situazioni non già eseguite - fanno sembrare il codice molto più complesso di quanto non sia in realtà, rendono più difficile la lettura e la manutenzione. Le uscite anticipate e metodi più piccoli sono la strada da percorrere.

• Cercando di codificare le cose perfettamente al primo tentativo.
• Cercando di creare un modello OO perfetto prima della codifica.
• Progettare tutto per flessibilità e miglioramenti futuri.

In una parola overengineering .

Notazione ungherese (sia forme che sistemi). Ho usato per prefissare tutto. strSomeString o txtFoo. Ora uso someString e textBoxFoo. È molto più leggibile e più facile per qualcuno nuovo che si avvicina e riprende. Come bonus aggiuntivo, è banale mantenerlo coerente: camelCase il controllo e aggiungi un nome utile / descrittivo. Forms Hungarian ha l'inconveniente di non essere sempre coerente e Systems Hungarian non ti fa guadagnare molto. Il raggruppamento di tutte le variabili insieme non è davvero così utile, specialmente con i moderni IDE.

L'architettura "perfetta"

Ho pensato THE L'architettura un paio di anni fa. Mi sono spinto tecnicamente il più lontano possibile in modo che ci fossero strati accoppiati al 100%, ampio uso di delegati e oggetti leggeri. Era il paradiso tecnico.

Ed era una schifezza. La purezza tecnica dell'architettura ha solo rallentato il mio team di sviluppo puntando alla perfezione sui risultati e ho quasi raggiunto il completo fallimento.

Ora abbiamo un'architettura molto più semplice e meno tecnicamente perfetta e il nostro tasso di consegna è salito alle stelle.

L'uso della caffina. Una volta mi teneva sveglio e in uno stato d'animo glorioso di programmazione, dove il codice volava dalle mie dita con febbrile fluidità. Adesso non fa niente e se non ce l'ho mi viene il mal di testa.

Commentare il codice. Un tempo pensavo che il codice fosse prezioso e che non puoi semplicemente eliminare quelle bellissime gemme che hai creato. Ora elimino qualsiasi codice commentato che trovo a meno che non ci sia un TODO o una NOTA allegata perché è troppo pericoloso lasciarlo dentro. In altre parole, mi sono imbattuto in vecchie classi con enormi porzioni commentate e mi ha davvero confuso il motivo per cui c'erano: sono stati recentemente commentati? è un cambiamento dell'ambiente di sviluppo? perché fa questo blocco non correlato?

Considera seriamente di non commentare il codice e di eliminarlo semplicemente. Se ne hai bisogno, è ancora nel controllo del codice sorgente. YAGNI però.

L'uso eccessivo / abuso delle direttive #region. È solo una piccola cosa, ma in C #, in precedenza usavo le direttive #region ovunque, per organizzare le mie classi. Ad esempio, raggrupperei tutte le proprietà della classe insieme in una regione.

Ora guardo indietro al vecchio codice e principalmente mi infastidisco. Non penso che renda le cose più chiare per la maggior parte del tempo, ea volte semplicemente ti rallentano. Quindi ora ho cambiato idea e sento che le classi ben organizzate sono per lo più più pulite senza direttive regionali.

Sviluppo a cascata in generale, e nello specifico, la pratica di scrivere specifiche funzionali e di design complete e complete che in qualche modo dovrebbero essere canoniche e quindi aspettarsi che un'implementazione di quelle sia corretta e accettabile. L'ho visto rimpiazzato con Scrum, e un bel gioco, dico. Il semplice fatto è che la natura mutevole delle esigenze e dei desideri del cliente rende ogni specifica fissa effettivamente inutile; l'unico modo per affrontare veramente correttamente il problema è con un approccio iterativo. Non che Scrum sia un proiettile d'argento, ovviamente; L'ho visto abusato e abusato molte, molte volte. Ma batte la cascata.

Mai schiantarsi.

Sembra una buona idea, non è vero? Agli utenti non piacciono i programmi che si bloccano, quindi scriviamo programmi che non si bloccano e agli utenti dovrebbe piacere il programma, giusto? È così che ho iniziato.

Al giorno d'oggi, sono più propenso a pensare che se non funziona, non dovrebbe fingere che funzioni. Fallisci il prima possibile, con un buon messaggio di errore. Se non lo fai, il tuo programma andrà in crash ancora più difficile solo poche istruzioni dopo, ma con qualche errore anonimo di puntatore nullo che richiederà un'ora per il debug.

Il mio pattern preferito per "non andare in crash" è questo:

public User readUserFromDb(int id){
    User u = null;
    try {
        ResultSet rs = connection.execute("SELECT * FROM user WHERE id = " + id);
        if (rs.moveNext()){
            u = new User();
            u.setFirstName(rs.get("fname"));
            u.setSurname(rs.get("sname"));
            // etc
        }
    } catch (Exception e) {
        log.info(e);
    }
    if (u == null){
        u = new User();
        u.setFirstName("error communicating with database");
        u.setSurname("error communicating with database");
        // etc
    }
    u.setId(id);
    return u;
}

Ora, invece di chiedere ai tuoi utenti di copiare / incollare il messaggio di errore e inviarlo a te, dovrai immergerti nei log cercando di trovare la voce di log. (E poiché hanno inserito un ID utente non valido, non ci sarà alcuna voce di registro.)

Ho pensato che avesse senso applicare modelli di design ogni volta che li ho riconosciuti.

Non sapevo che stavo effettivamente copiando stili da linguaggi di programmazione stranieri, mentre il linguaggio con cui stavo lavorando consentiva soluzioni molto più eleganti o più semplici.

L'uso di più lingue (molto) diverse mi ha aperto gli occhi e mi ha fatto capire che non devo applicare male le soluzioni di altre persone a problemi che non sono miei. Adesso rabbrividisco quando vedo il pattern factory applicato in un linguaggio come Ruby.

Test ossessivo. Ero un fervente sostenitore dello sviluppo test-first. Per alcuni progetti ha molto senso, ma mi sono reso conto che non solo è irrealizzabile, ma piuttosto dannoso per molti progetti aderire pedissequamente a una dottrina di scrittura di unit test per ogni singola funzionalità.

In realtà, aderire pedissequamente a qualsiasi cosa può essere dannoso.

Questa è una piccola cosa, ma: preoccuparsi di dove vanno le parentesi graffe (sulla stessa riga o sulla riga successiva?), Lunghezza massima suggerita delle righe di codice, convenzioni di denominazione per le variabili e altri elementi di stile. Ho scoperto che tutti sembrano preoccuparsi di questo più di me, quindi mi limito a seguire il flusso di chiunque stia lavorando al giorno d'oggi.

Modifica: L'eccezione a questo è, ovviamente, quando sono io quello a cui importa di più (o quello in grado di impostare lo stile per un gruppo). In tal caso, faccio quello che voglio!

(Nota che questo non è la stessa cosa che non avere uno stile coerente. Penso che uno stile coerente in una base di codice sia molto importante per la leggibilità.)

Forse la più importante "pratica di programmazione" su cui ho cambiato idea da allora è l'idea che il mio codice sia migliore di quello di chiunque altro. Questo è comune per i programmatori (soprattutto per i neofiti).

Librerie di utilità. Ero solito portare in giro un assembly con una varietà di metodi e classi di supporto con la teoria che avrei potuto usarli da qualche altra parte un giorno.

In realtà, ho appena creato un enorme spazio dei nomi con molte funzionalità mal organizzate.

Ora, le lascio semplicemente nel progetto in cui le ho create. Con ogni probabilità non ne avrò bisogno e, se lo avrò, potrò sempre rifattorizzarle in qualcosa di riutilizzabile in seguito. A volte li contrassegno con un // TODO per una possibile estrazione in un assembly comune.

Progettare più di quanto ho programmato. Dopo un po ', si trasforma in paralisi da analisi.

L'uso di un DataSet per eseguire la logica di business. Questo lega troppo strettamente il codice al database, inoltre il DataSet viene solitamente creato da SQL, il che rende le cose ancora più fragili. Se l'SQL o il database cambia, tende a ricadere su tutto ciò che tocca il DataSet.

Esecuzione di qualsiasi logica aziendale all'interno di un costruttore di oggetti. Con l'ereditarietà e la capacità di creare costruttori sovraccarichi tendono a rendere difficile la manutenzione.

Abbreviazione di variabile / metodo / tabella / ... Nomi

Lo facevo tutto il tempo, anche quando lavoravo in lingue senza limiti imposti sulla lunghezza dei nomi (beh, probabilmente erano 255 o qualcosa del genere). Uno degli effetti collaterali sono stati molti commenti disseminati in tutto il codice che spiegano le abbreviazioni (non standard). E, naturalmente, se i nomi fossero cambiati per qualsiasi motivo ...

Ora preferisco di gran lunga chiamare le cose per quello che sono realmente, con buoni nomi descrittivi. incluse solo le abbreviazioni standard . Non è necessario includere commenti inutili e il codice è molto più leggibile e comprensibile.

Racchiudere i componenti di accesso ai dati esistenti, come Enterprise Library, con un livello personalizzato di metodi di supporto.

• Non semplifica la vita a nessuno
• È più codice che può contenere bug
• Molte persone sanno come utilizzare i componenti di accesso ai dati EntLib. Nessuno tranne il team locale sa come utilizzare la soluzione di accesso ai dati interna

Ho sentito parlare per la prima volta della programmazione orientata agli oggetti mentre leggevo di Smalltalk nel 1984, ma non avevo accesso a un linguaggio oo fino a quando non ho usato il compilatore C ++ cfront nel 1992. Alla fine ho avuto modo di usare Smalltalk nel 1995. Avevo atteso con impazienza oo tecnologia, e ha acquisito l'idea che avrebbe salvato lo sviluppo del software.

Ora, vedo oo solo come una tecnica che ha alcuni vantaggi, ma è solo uno strumento nella cassetta degli attrezzi. Svolgo la maggior parte del mio lavoro in Python e spesso scrivo funzioni autonome che non sono membri di una classe e raccolgo spesso gruppi di dati in tuple o elenchi dove in passato avrei creato una classe. Creo ancora classi quando la struttura dei dati è complicata o ho bisogno di comportamenti associati ai dati, ma tendo a resistere.

In realtà sono interessato a fare un po 'di lavoro in Clojure quando ho tempo, che non fornisce servizi oo, sebbene possa utilizzare oggetti Java se capisco correttamente. Non sono pronto a dire qualcosa come oo è morto, ma personalmente non sono il fan che ero.

In C #, utilizzando _notation per i membri privati. Ora penso che sia brutto.

Poi sono passato a this.notationper membri privati, ma ho scoperto che non ero coerente nell'usarlo, quindi ho abbandonato anche quello.

Ho smesso di seguire il metodo di progettazione raccomandato dall'università prima dell'implementazione. Lavorare in un sistema caotico e complesso mi ha costretto a cambiare atteggiamento.

Ovviamente faccio ancora ricerche sul codice, specialmente quando sto per toccare un codice che non ho mai toccato prima, ma normalmente cerco di concentrarmi su implementazioni il più piccole possibile per ottenere qualcosa prima. Questo è l'obiettivo principale. Quindi affina gradualmente la logica e lascia che il design appaia da solo. La programmazione è un processo iterativo e funziona molto bene con un approccio agile e con molto refactoring.

Il codice non guarderà affatto come avevi pensato inizialmente. Succede ogni volta :)

Ero grande nel design-by-contract. Ciò significava mettere un sacco di controllo degli errori all'inizio di tutte le mie funzioni. I contratti sono ancora importanti, dal punto di vista della separazione delle preoccupazioni, ma piuttosto che cercare di imporre ciò che il mio codice non dovrebbe fare, cerco di utilizzare i test unitari per verificare cosa fa.

Userei static in molti metodi / classi perché era più conciso. Quando ho iniziato a scrivere test quella pratica è cambiata molto rapidamente.

Eccezioni verificate

Un'idea straordinaria sulla carta: definisce il contratto in modo chiaro, senza possibilità di errore o dimenticanza di verificare alcune condizioni di eccezione. Sono stato venduto quando ne ho sentito parlare per la prima volta.

Naturalmente, in pratica si è rivelato un tale casino. Al punto da avere oggi librerie come Spring JDBC, che nasconde le eccezioni verificate legacy come una delle sue caratteristiche principali.

Che qualcosa di utile fosse codificato solo in una lingua particolare. Nel mio caso credevo che il C fosse il miglior linguaggio in assoluto e non ho mai avuto motivo di codificare nulla in nessun'altra lingua ... mai.

Da allora ho imparato ad apprezzare molte lingue diverse e i vantaggi / funzionalità che offrono. Se voglio codificare qualcosa di piccolo - velocemente - userei Python. Se voglio lavorare su un progetto di grandi dimensioni, dovrei scrivere codice in C ++ o C #. Se voglio sviluppare un tumore al cervello, codificherei in Perl .

Quando ho dovuto fare un po 'di refactoring, ho pensato che fosse più veloce e più pulito iniziare subito e implementare il nuovo design, fissando le connessioni fino a quando non funzionavano. Poi ho capito che è meglio fare una serie di piccoli refactoring per progredire lentamente ma in modo affidabile verso il nuovo design.

Forse la cosa più grande che è cambiata nelle mie pratiche di codifica, così come in altre, è l'accettazione di classi esterne e librerie scaricate da Internet come base per comportamenti e funzionalità nelle applicazioni. A scuola all'epoca in cui frequentavo il college eravamo incoraggiati a capire come migliorare le cose tramite il nostro codice e fare affidamento sul linguaggio per risolvere i nostri problemi. Con i progressi in tutti gli aspetti dell'interfaccia utente e del consumo di servizi / dati, questa non è più una nozione realistica.

Ci sono alcune cose che non cambieranno mai in una lingua e avere una libreria che racchiude questo codice in una transazione più semplice e in meno righe di codice che devo scrivere è una benedizione. La connessione a un database sarà sempre la stessa. La selezione di un elemento all'interno del DOM non cambierà. L'invio di un'e-mail tramite uno script lato server non cambierà mai. Dover scrivere questa volta spreca tempo che potrei usare per migliorare la mia logica di base nell'applicazione.

Inizializzazione di tutti i membri della classe.

Ho usato per inizializzare esplicitamente ogni membro della classe con qualcosa, di solito NULL. Mi sono reso conto che questo:

• normalmente significa che ogni variabile viene inizializzata due volte prima di essere letta
• è sciocco perché nella maggior parte delle lingue inizializza automaticamente le variabili su NULL.
• effettivamente impone un leggero calo delle prestazioni nella maggior parte delle lingue
• può gonfiare il codice su progetti più grandi

Come te, ho anche abbracciato i modelli IoC nel ridurre l'accoppiamento tra i vari componenti delle mie app. Rende la manutenzione e lo scambio di parti molto più semplici, purché riesca a mantenere ogni componente il più indipendente possibile. Sto anche utilizzando più framework relazionali a oggetti come NHibernate per semplificare le faccende di gestione del database.

In poche parole, sto usando framework "mini" per aiutare a creare software in modo più rapido ed efficiente. Questi mini-framework consentono di risparmiare molto tempo e, se eseguiti correttamente, possono rendere un'applicazione estremamente semplice da mantenere lungo la strada. Plug 'n Play per vincere!