Per me, aiuta a scomporre un pezzo più grande di software in blocchi più piccoli. E poi rompere quei pezzi in parti ancora più piccole e così via. Ogni programma software è una raccolta di piccoli pezzi di logica.
Pensa ad un blog, per esempio. Vuoi essere in grado di creare e modificare post che altri possono leggere. Subito puoi dividere il progetto in admin e sezioni pubbliche. Come minimo, l'amministratore richiede agli utenti amministratori, una pagina di accesso e una sezione per la gestione del blog. La sezione per la gestione del blog può essere suddivisa in un'interfaccia CRUD (Crea, Leggi, Aggiorna, Elimina). La creazione di un nuovo post del blog richiede un controllo per assicurarsi che l'utente amministratore abbia i privilegi giusti, un modulo, la convalida del modulo e la possibilità di salvare nel database. E così via.
Più si interrompe un problema o una funzionalità, più diventa gestibile. È dividere e conquistare. Una volta che sei riuscito a mappare il tuo software in questo modo, puoi dare un'occhiata a come diverse parti interagiscono tra loro. Dove potresti ripetere il codice? Cosa può essere astratto? Questo dovrebbe essere un processo iterativo sia come pianifichi che mentre scrivi il codice stesso.
Suggerirei di capire quale sia il set di funzioni minimo da cui iniziare e di implementarlo prima di aggiungerne altri. Dovrai codificare in modo difensivo in modo che le modifiche future non siano troppo difficili, ma allo stesso tempo non vuoi implementare le mezze funzioni che potrebbero non essere mai completate. È una linea difficile da percorrere tra la flessibilità e l'essere disposti a uccidere spietatamente i tuoi cari, a prendere in prestito un riferimento letterario. Essere bravi in quel particolare atto di bilanciamento viene solo dall'esperienza.
E questo è quanto, come hanno detto le altre risposte: esperienza. L'unico modo per ottenerlo è iniziare. Non preoccuparti tanto di renderlo perfetto sin dall'inizio. Prima di tutto fai in modo che il codice funzioni, quindi rendilo bello, quindi rendilo veloce.
Inoltre, a differenza di questo paragrafo, non aggiungere la sicurezza alla fine come un ripensamento. Dovresti avere un'idea dei modi in cui il tuo software potrebbe essere compromesso, ma come inizio, non fidarti mai dell'input dell'utente.