Programma più professionale (pianificazione, notazione, ...) [chiuso]

Il fatto che a volte si refactoring il codice non è una cosa negativa; essere preparati a farlo dimostra l'impegno a scrivere il miglior codice possibile.

Sembra che tu stia cercando un modo più rigido per definire il software in anticipo. Certamente pensare e pianificare è importante, ma andare troppo lontano nella direzione di Big Design Up Front (BDUF) ha il suo i problemi. Questi includono non conoscere tutti i requisiti in anticipo e non essere abbastanza flessibili da modificare il progetto se (quando) i requisiti cambiano. Come molte cose che sono difficili, è un compromesso tra due estremi di un pendolo. Potresti trovare interessante leggere il Metodo a cascata e i suoi problemi.

Le dimensioni limitate del tuo progetto indicano che un approccio dinamico ha più lati positivi che negativi. Rifare la tua via d'uscita da eventuali svolte sbagliate probabilmente non sarà difficile.

Ti incoraggio a dare un'altra occhiata a TDD. Non è che il codice sia stato dimostrato corretto (non lo è, anche se fornirà ulteriori prove che lo sia). Il vantaggio principale è che ti dà la sicurezza di rifattorizzare di più. L'idea è che i test siano verdi, che tu cambi l'implementazione e interrompa i test, poi li riaccendi di nuovo. Se hai dei buoni test, evita quelle brutte situazioni in cui cerchi di cambiare molto e mettiti nei guai e non riesci a capire perché le cose si sono rotte (ovviamente se stai usando il controllo del codice sorgente il rollback è un comando di distanza).

Per quanto sia difficile da testare puoi usare oggetti fittizi . Questi ti permettono di isolare classi per i test che sono strongmente intrecciati (altamente accoppiati). Se segui TDD, scoprirai che naturalmente scrivi classi che stanno da sole. Ciò semplifica il test, ma rende felice anche il codice (accoppiamento basso e alta coesione).

Se sei interessato a questo, ti raccomando di leggere il libro di Martin Fowlers Refactoring: migliorare il design del codice esistente .

È come hai fatto a far funzionare le cose? Hai avuto successo soddisfacendo tutte le tue scadenze e soddisfacendo tutti i tuoi clienti? È questo il modo in cui hai sempre lavorato e hai intenzione di lavorare con altri sviluppatori di software con aspettative leggermente diverse di te?

Potrei darti un sacco di consigli su come farei personalmente le cose, ma la domanda è davvero ciò che tu e il tuo team sentite davvero funziona per voi. Se stai facendo queste domande solo per interesse, allora forse non sei ancora pronto a cambiare il modo in cui fai le cose. Se d'altra parte hai sentito che sei un compito e il carico di lavoro ha avuto la meglio su di te, e pensi che il modo in cui lavori non funzioni, allora forse hai bisogno di rivedere la tua metodologia e affrontare questi problemi prima ad un livello molto più alto.

Gli strumenti di pianificazione non ti aiuteranno a decidere che cosa necessiti di refactoring. Questi strumenti sono semplicemente lì per aiutarti a organizzare il tuo lavoro e ripartirlo secondo la tua metodologia di sviluppo preferita.

A proposito di TDD, tuttavia, se non riesci a vedere come potresti usarlo, allora non testerai il tuo software abbastanza o del tutto, o avrai il regime di test più rigido in atto che smentisce il tuo bisogno al test unitario. Il TDD in sé è un modo molto diverso di scrivere software in quanto decidi come vuoi che funzioni il tuo sistema, e prima di implementarlo, definisci come lo testerai, quindi scrivi il tuo codice per superare i test. Fornisce un mezzo per semplificare ciò che fai e sposta l'attenzione dal test sul funzionamento del codice prima di consegnarlo, per fornire codice funzionante che funzioni già.

Se senti la necessità di fornire diagrammi per mostrare come funzionano i tuoi sistemi, chiedi a te stesso quale sarà il valore nella produzione e nella manutenzione di tutta la documentazione aggiuntiva. Certo, può essere utile documentare come un sistema particolarmente difficile da definire funzioni ad un livello elevato, ma più dettagliata è la documentazione, più difficile sarà mantenere.

Dal contenuto del tuo post, mi sembra che tu non abbia davvero imparato COME scrivere software. Se questo è il caso (potresti essere nuovo o autodidatta), allora raccomanderei almeno la seguente lettura:

• Sviluppo del primo software Head - Un buon primer
• Pulisci codice
• Refactoring
• Sviluppo software agile

Raccomando anche di considerare lo sviluppo basato sul comportamento come alternativa al TDD. Impara come scrivere software senza aggiungere pile di ulteriore e inutile burocrazia che potresti non aver bisogno.

Ciò che rende uno sviluppatore software professionale è il modo in cui gestisci la tua relazione con i tuoi clienti, come ti avvicini ai problemi e come li risolvi in modo innovativo. Inoltre, è il modo in cui si lavora per ridurre al minimo il disordine nel codice, quanto accuratamente si prova e quanto velocemente si adatta ai cambiamenti, come si gestisce il flusso di lavoro e come si tiene il passo con le best practice del settore comunemente accettate. Beh, ovviamente c'è molto di più, ma è un punto di partenza.