Le cose stanno cadendo a pezzi e tu stai riflettendo su di esso. Tu provi a farlo meglio la prossima volta. Quindi la buona notizia è: sei sulla buona strada, e ciò che stai sperimentando in questo momento è chiamato apprendimento.
Lascia che ti racconti una storia. Una volta, ero in una situazione simile. C'era un pezzo di codice che divenne improvvisamente più complesso quando noi (due persone inesperte) riuscimmo a gestirlo. I segni erano simili a quelli che si vedono: il codice ha iniziato a diventare fragile e la correzione di un bug ha introdotto due nuovi bug. In poche parole, l'intera cosa ha iniziato a sviluppare una sorta di vita propria e incontrollabile.
In quel momento abbiamo scoperto che il test dell'unità può essere un ottimo strumento. Sono passati anni prima che queste cose iniziassero a diventare mainstream, ed è stata l'unica intuizione che ha sostanzialmente salvato il progetto. Abbiamo iniziato a scrivere casi di test in modo metodico, cosa che ci ha permesso di lasciare il codice in uno stato migliore dopo che il problema successivo era stato risolto. Per ogni problema risolto e per ogni nuova funzionalità, abbiamo aggiunto almeno un caso di test per assicurarci che tutto funzioni e nessuno dei problemi identificati e risolti riattivi la loro brutta testa - e se così fosse, saremmo almeno avvertiti immediatamente. / p>
Il libro che stavo leggendo in quel momento ci ha aiutato con questa intuizione. È stato " Scrivere codice solido " di Steve Maguire. Certo, è un po 'obsoleto nei dettagli, ma la maggior parte dei principi in quel libro sono ancora validi oggi, e non solo per i programmatori C. Il messaggio di base è di fare qualsiasi cosa tu possa fare e di utilizzare qualsiasi strumento sia adatto a rendere il tuo codice solido.
I jumped right into programming without giving a second though to design. [...] I cant get anything done, the code is very inconsistant, and the whole thing is a mess.
Il miglior consiglio qui è probabilmente: non aver paura di buttare via il codice e riscrivere roba che non funziona. Ci vorrà un po 'più di tempo oggi, è vero, ma lo scambi con benefici molto più grandi a lungo termine, perché non devi più occuparti del casino. Fai testare la tua unità per verificare il risultato previsto. Prendi in considerazione l'utilizzo di TDD, potrebbe essere quello che ti serve per far domare la bestia. E per ultimo, prova la gestione degli errori.
Ive definitely learned the importance of design in software development, but I dont know how one designs software to begin with.
Questo è qualcosa che dovresti assolutamente imparare, sia in teoria che in pratica. Cerca di studiare buone soluzioni nel codice di altre persone, ad esempio i progetti Open Source sono un'ottima fonte. Cerca di capire che cosa fa il codice, magari chiedi alle persone ogni volta che non lo capisci.
Un buon modello e un libro anti-pattern possono essere d'aiuto (ad es. il materiale del GOF), ma dovresti provare a mettere in pratica gli schemi per assicurarti di capire veramente come funzionano e per cosa sono adatti. Cerca di implementare ancora parte del tuo codice con questi principi in mente. Sviluppa la capacità di vedere il quadro generale dietro ciò che stai facendo. Come hai potuto dividere quella grande palla di fango in piccoli pezzi riutilizzabili? Quali modelli puoi identificare? Come progettare l'interfaccia tra questi componenti? Quindi provalo, esercitati e impara. Parla con le persone e lascia che le esaminino.