Quanto è stato progettato prima? [duplicare]

Quindi inizi sempre a sviluppare i tuoi sviluppi scrivendo l'interfaccia utente? Direi che questo modo di fare è generalmente associato allo sviluppo di "prototipi" in ambienti professionali, ma poi di nuovo non necessariamente. Nelle piccole aziende che scrivono applicazioni "piccole" e che iniziano con l'interfaccia utente accade molto spesso ( anche capita anche più spesso che l'applicazione "piccolo" è stato avviato cresce e cresce e cresce e diventa un'applicazione mostro che richiede di refactoring, sviluppatori aggiuntivi. .. ma io divago )

Quindi non è necessariamente una cattiva idea, dipende dalla dimensione / complessità dell'applicazione che si sta scrivendo e tu l'hai detto tu stesso che stai scrivendo questi programmi per te stesso. Psicologicamente, avere un'interfaccia utente può anche aiutare a farti vedere i tuoi progressi e questo ti dà motivazione. Considerando che se stai scrivendo il tuo code-behind e i casi di test in primo luogo potrebbe essere necessario un giorno di rugiada prima di iniziare realmente a soffermarti sull'interfaccia utente ... A meno che la tua mente non accetti che anche i casi di test siano traguardi:)

Tuttavia, come hai detto tu stesso, facendo prima l'interfaccia utente senza pensare alla dorsale dell'applicazione , ti porteranno nei guai. È molto allettante iniziare la parte "divertente" (sono come te, mi piace avere interfacce chiare). Ma prima, e anche per i piccoli programmi, fermati un attimo, prendi un foglio di carta e disegna alcuni diagrammi su come funziona la tua applicazione. Come reagiranno i tuoi componenti agli eventi dell'interfaccia utente. Quali sono le regole aziendali (o di gioco!) Da implementare. Prepara un breve elenco di cose da attuare e definisci le priorità in base a ciò che ritieni sia fondamentale. Inoltre, durante la programmazione, resisti all'impulso di implementare funzionalità / opzioni non critiche che inevitabilmente ti verranno in mente, annotale e osservale dopo il raffreddamento.

Dovresti sforzarti di ottenere la massima separazione tra interfaccia utente e logica aziendale / di gioco. Idealmente, il tuo codice di gioco dovrebbe funzionare se hai un gioco a riga di comando (ad esempio: "gioca e2e4"), un'interfaccia utente 2D semplice o un'interfaccia utente 3D a pieno titolo basata sull'ultima versione di DirectX. completa separazione non è un lavoro facile ed è dove la conoscenza di Object-Oriented e programmazione puntuale sarà molto utile.

Ora, la cosa buona è che entrambi ami programmare e scrivere programmi, e tu sei solo un po 'troppo entusiasta ... No scratch. Sei entusiasta e questa è una buona cosa.

Riguardo al soggetto del refactoring, potresti non sentirne il bisogno, ma forse è perché sai che il tuo codice è un disastro e che ci vorrebbe un'eternità per cambiare le cose. Tuttavia, se organizzi le tue idee un po 'prima di iniziare, dovresti avere meno codice per il refactoring (ma ci sarà (dovresti?) Essere sempre una piccola voce nella tua testa che dice "questo potrebbe funzionare meglio se ..."). Controlla altre domande su questo sito web sul tema del refactoring, altre persone hanno coperto molto meglio di quanto avrei potuto fare io.

Infine, se ritieni di non scrivere codice OO corretto dai un'occhiata ad alcuni libri che potresti leggere per migliorarlo, ad esempio: link

"Qual è il modo corretto / migliore per iniziare a progettare un software che è un po 'complicato come un gioco di scacchi"

Penso che tu voglia evitare la complessità e cercare la semplicità nella progettazione di artefatti software. Un libro che ti posso raccomandare caldamente sull'argomento è Domain Driven Design di Eric Evan, che delinea varie strategie per la progettazione software con un strong pregiudizio per avere un livello di dominio discreto in atto per i tuoi progetti software.

"So che se mi viene chiesto di modificare qualsiasi funzione del mio programma, potrei essere in disordine perché non sono stati progettati correttamente (anche se funzionano come richiesto)."

È facile essere saggi con il senno di poi e segnalare i difetti di un'applicazione quando è in uno stato di preparazione, ma è necessario riconoscere che l'intero processo di sviluppo del software è un processo continuo e nuove strategie / tecnologie emergono quasi ogni anno Forse non interpreterò ciò che stai dicendo qui, ma sembra che tu manchi un po 'di confidenza. Le persone ti danno un feedback sul tuo codice? Un modo per iniziare a far girare la palla è fare delle revisioni del codice o persino un paio di programmi. Alla fine, aumenterai la tua sicurezza e sarai in grado di affrontare un progetto software senza troppe preoccupazioni. In genere, non penso mai a un progetto software come "finito" in quanto tale. Può sempre essere migliorato e riordinato in diversi modi. Sii un critico del tuo lavoro, quando hai scritto una classe / metodo pensa a come potrebbe essere migliorato, immagina che il codice ti sia stato inviato da un altro sviluppatore per la revisione. Che consiglio vorresti dargli di migliorarlo?

Per quanto riguarda la lettura, sicuramente leggere Domain Driven Design e darei un'occhiata a Codice completo . Dovresti anche avere The Pragmatic Programmer da qualche parte vicino alla parte superiore della tua lista di lettura. Puoi fare tutta la lettura del mondo, ma per ottenere sicurezza e migliorare, devi sviluppare attivamente progetti software, essere critico del tuo lavoro e anche ottenere feedback da altri sviluppatori.

Whenever I strike an idea that excites me I just start a new project in my IDE .That.. and I start designing the interface—which means to me as placing menubars ... Recently I started a chess game in Java and I followed that pattern: first programmed the black-white grid, then registered a mouse listener etc. without thinking about warriors/objects of chess game.

Niente di male in questo, dobbiamo iniziare da qualche parte.

One thing that annoys me is that I have never been able to completely use object-oriented features of object-oriented programming, though I understand it. I have the habit of taking on things when it comes. This could be the reason of the poor design I end up with.

Penso che i tuoi disegni poveri siano il risultato di una mancanza di esperienza e conoscenza. Sai che i tuoi disegni non sono buoni perché sono difficili da modificare, ma non sai come migliorarli. La cosa divertente del software è che è infinitamente mutevole; puoi continuare ad aggiungere codice bit per bit e migliorare il design mentre procedi. Ma devi ancora sapere quali cambiamenti potrebbero migliorare il design. Vi raccomando di leggere Refactoring di Martin Fowler e Design Patterns di Gemma et. al. Tuttavia, tieni presente che l'idea non è quella di scegliere gli schemi di progettazione prima della codifica, ma di riconoscere gli schemi di progettazione applicabili al codice.

Una grande parte del design è la funzionalità. Non frammentarlo e limitarlo solo alle arti. Così, mentre costruisci l'architettura, ti intreccia con esso e visualizzi un design che unifica non solo lo rende più carino ma anche sempre più funzionale.

Esempi di questo sono: il lavoro di Leonardo Da Vinci, Apple Design ecc.

Anche wikipedia ha una buona voce su "Form over Function": link

Adotto una vista simile anche se la funzione è abbastanza rigida in cui è possibile personalizzare e abbellire il prodotto senza necessariamente ostacolarlo. La nostra sensibilità umana è ancora lì, non importa quanto tempo cerchiamo di essere funzionali e obiettivi.

Un buon esempio è l'iMac con la sua maniglia in alto. Nessuno ha spostato il proprio iMac, ma ha consentito a un messaggio inconscio emanato "Controllo / gestione umana" su una macchina. Piccolo tocco ma ha fatto spostare molte vendite!