Metodi di progettazione del software per Java o qualsiasi altro linguaggio di programmazione

Consiglierei di leggere alcuni libri per iniziare.

Un libro generale sull'arte, l'artigianato e l'ingegneria dietro lo sviluppo del software è Il programmatore pragmatico: da Journeyman a Master . Questo libro parla di tutto, dal trattare con le persone al supporto degli strumenti per il tuo sviluppo. Copre un sacco di terreno in un pacchetto molto piccolo, e ho persino riletto questo libro di tanto in tanto. Il consiglio è applicabile a tutti nello sviluppo del software, dal programmatore al project manager.

Rapid Development: Taming Wild Software Schedules . È il libro utilizzato nel corso di processo e di gestione dei progetti che ho seguito e copre una serie di importanti modelli e metodologie di processo, quando vengono applicati, e le migliori pratiche comunemente accettate per la gestione dei progetti. Tuttavia, come la maggior parte del lavoro, si concentra sui progetti di squadra rispetto ai singoli.

Dal lato della codifica, Codice completo: un manuale pratico di costruzione del software è una lettura consigliata. Si concentra su come scrivere codice buono, pulito, con concetti che si applicano a un certo numero di lingue. L'enfasi è sulla programmazione procedurale e orientata agli oggetti, ma il consiglio può essere applicato a qualsiasi linguaggio o paradigma.

Per la progettazione di software orientato agli oggetti, i testi classici includono Modelli di progettazione: elementi del software orientato agli oggetti riutilizzabile e Refactoring: migliorare il design del codice esistente . Esistono numerosi libri e risorse in questo campo e molte decisioni di progettazione sono guidate dalle tecnologie che stai utilizzando e dai requisiti del tuo progetto. Per l'architettura del sistema software, un testo classico è Architettura software in pratica che tratta argomenti che vanno dalle viste architettoniche allo sviluppo della linea di prodotti . Questo era il libro usato nel mio corso di architetture software, ma alcuni professori stavano usando Architettura dei sistemi software: Lavorare con le parti interessate usando i punti di vista e le prospettive al suo posto.

Tuttavia, non puoi leggere questi libri. L'importante è applicare ciò che hai letto ai tuoi progetti al lavoro, a scuola e a casa. Puoi leggere tutto ciò che desideri, ma se non applichi le tue conoscenze, non ha senso.

Nei miei progetti, molto di ciò che faccio è guidato dai miei obiettivi, sia in termini di sviluppo personale che di requisiti del progetto. Non troverai una metodologia o un processo valido per tutti, quindi la soluzione migliore è esaminare le best practice comunemente utilizzate, scoprire cosa funziona per te e il tuo team e imparare dagli errori per i progetti futuri.

Quello che faccio è guardare se un progetto simile è già stato fatto. Non ha bisogno di essere esattamente lo stesso, ma qualcosa legato al mio nuovo progetto.

Eseguo il reverse engineering del codice java in un modello ed estrapro diagrammi UML per visualizzare il codice. Cerco di capire come funziona e la logica. Una volta capito, ridisegno ciò di cui ho bisogno e generare di nuovo un nuovo codice java.

Non c'è alcun copyright sul codice che ottengo perché non copio il codice originale di un altro progetto. Guardo solo lo scheletro e genera codice dal modello. Il codice generato è quindi pulito senza copyright. Solitamente supera l'80% dello scheletro della prima bozza. Non penso che questo sia un comportamento brutto risparmiando tempo per farlo !! Non posso solo invertire .java ma anche il codice .class. O anche mescolarli se più di un progetto. Ho subito capito il quadro generale del progetto e posso copiare ciò di cui ho bisogno.

Finalmente ho inserito il mio codice personale in questo codice generato per personalizzarlo. Penso che l'utilizzo di un progetto già stabile sia un fattore chiave per avere una buona architettura. Non sono un genio ma funziona davvero bene e mi risparmia un sacco di tempo. Mi sono reso conto che, poiché ho usato un progetto già fatto, in genere hanno fatto un'architettura espandibile che è davvero importante se hai bisogno di evolvere il tuo progetto. Se avessi creato una struttura solo per i primi requisiti che ho ottenuto, sarei rimasto bloccato in seguito.

Questa è una domanda molto ampia e devo prima dire che ogni azienda / sviluppatore ha diverse metodologie e processi di progettazione. Quindi parlerò solo per la mia personale esperienza.

Il primo passo è chiedersi quali sono tutte le specifiche. Non solo devi pensare al prodotto finale, ma anche al processo e alla vita della tua applicazione dopo la distribuzione. Gli altri programmatori stanno lavorando su di esso? In tal caso, tu (e il tuo team) potresti voler sviluppare prima l'intero framework in modo che ognuno di voi possa lavorare contemporaneamente su diversi aspetti dell'applicazione. L'applicazione sarà estesa in futuro? In tal caso, dovrai assicurarti di fornire un livello sufficientemente elevato di astrazione (corretta gerarchia OOP, ecc.) Per abilitarlo. Ci saranno degli sviluppatori di terze parti che stanno lavorando per estendere la tua applicazione (tramite plugin, ecc.)? In tal caso, devi assicurarti che la tua applicazione sia sicura e che i tuoi utenti siano adeguatamente protetti (assicurandoti che le tue variabili / classi abbiano gli appropriati modificatori di accesso).

Suppongo che le specifiche dell'applicazione siano già definite chiaramente. In caso contrario, è necessario farlo al più presto. Non c'è niente di peggio che avere una specifica che cambia mentre si sviluppa una grande applicazione. Ora, mentre programmi, dovresti tenere a mente tutte queste idee (dopotutto, qual è il punto su cui capire tutte queste domande se non hai intenzione di prestare attenzione).

Il prossimo elenco sta scegliendo le tecnologie e i framework (se ne stai usando uno a tutti). Non vuoi essere bloccato a fare un grande progetto da zero. Fai molte ricerche sui pro e contro di ciascuno e valuta di conseguenza. Scegliere la struttura giusta può significare la differenza tra un progetto di 10 ore e uno di 100 ore.

Google è il tuo migliore amico. Se qualcosa di sub-task richiede una quantità significativa di tempo per il codice, cercalo. Ho risparmiato innumerevoli ore semplicemente digitando una semplice query di ricerca e copiando + codice di incollatura. Non plagiare però, è male;) Ma non usare ciecamente il codice altrui. Solo perché è pubblicamente disponibile sul Web non significa che sia il pezzo di codice più efficiente o il pezzo di codice più sicuro. Rivedi sempre attentamente ciò che trovi.

Ora finalmente quando non puoi usare e riutilizzare ogni ultimo pezzo di codice che puoi, quindi scrivi il tuo. Rendilo pulito, conciso ed efficiente. Soddisfa tutte le tue esigenze e rendilo il miglior codice possibile. A nessuno piace leggere codice brutto / inefficiente.

Forse questo è il mio stesso cruccio (anche se sono sicuro che ne infastidisce molti altri), ma per favore formatta il tuo codice in modo piacevole e coerente. La codifica può essere un'arte, fammi un favore e non farlo apparire come se lo avessi digitato con le mani legate dietro la schiena.

Alcune delle metodologie che ho visto hanno usato molto:

• Codice e amp; Difficoltà. Tu codifichi qualcosa. Se non funziona, cambi qualcosa. Continui a farlo finché non funziona abbastanza bene da ingannare la gestione che è fatta. Questo è lo sviluppo "Agile" al suo peggio: "qual è la quantità minima di lavoro che posso farla franca?". Inutile dire che non sono un fan di questa metodologia, ma potresti riconoscerla dai tuoi colleghi o da te in una brutta giornata! È molto difficile ottenere un lavoro produttivo se non sai già esattamente a cosa stai mirando nel risultato finale.

• Prototipazione Throwaway. Inizi a bagnare i piedi con il codice & fissare la mentalità, con una differenza estremamente importante. Dal giorno 0 sai che butti via questo codice & correggi il prototipo una volta che ne sai abbastanza da farlo "giusto" o almeno molto meglio della prima volta. Questa è una metodologia molto utile per tecnologie molto nuove, algoritmi e problemi sconosciuti. La più grande difficoltà è avere l'autodisciplina per buttare via il prototipo e partire da zero. Potresti pensare che questo metodo impieghi il doppio del tempo, ma in realtà non lo fa: una volta che sai come fare qualcosa ti serve meno tempo per farlo. Hai ancora bisogno di sapere in qualche modo a cosa miri, ma puoi provare alcuni prototipi diversi solo per definire esattamente ciò che funziona meglio.

• Big Design Up Front. Se realizzi progetti per l'esercito, il governo, la NASA, il campo medico o le organizzazioni innamorate di CMMI L5, lo riconoscerai. Tutto è specificato nei minimi dettagli nei documenti e nelle specifiche prima che venga scritto qualsiasi codice di produzione. Funziona bene se riesci a ottenere tutto correttamente dal giorno 0 e nessun requisito cambia. In quasi tutti i casi, comunque, cambierà , quindi è possibile che molti sforzi di progettazione siano stati prematuri. Se si dispone di un documento a fini regolamentari, ovviamente è necessario farlo, ma ci sono sempre modi per avere una progettazione e documentazione "appena sufficienti" prima di iniziare la codifica vera e propria. Lato positivo: in ogni momento sei in grado di sapere esattamente qual è il tuo obiettivo finale, se riesci ancora a trovarlo tra le pile di documenti.

• Solo abbastanza design in primo piano - il mio metodo più usato. Molte delle cose che faccio non sono abbastanza nuove da richiedere la prototipazione "usa e getta", ma non voglio rimanere bloccato in Big Design Up Front e sprecare un sacco di sforzi, né voglio codificare e amp; sistemo la mia giornata e finisco con un "disegno" acciottolato che odio davvero. Quindi prendo i requisiti solitamente sottostimati e realizzo alcuni progetti su carta o in qualche tipo di strumento di progettazione (possono essere diagrammi UML in Enterprise Architect o solo disegni in Paint Shop Pro). Ne discuto con le persone responsabili dei requisiti finché non ho la sensazione di sapere di cosa hanno bisogno. Non concentrarti su ciò che chiede il cliente, e nemmeno su quello che vogliono, cerca di capire di cosa hanno bisogno e come meglio puoi fornirlo. Quindi scrivi la tua prima versione in codice - non proprio un prototipo usa e getta (se sei in the money, vorrai continuare a lavorarci su), ma non lucidato fino alla perfezione totale (perché potresti ancora sbagliare). Presenta la tua versione e sondare la reazione del tuo cliente. O continuare a lucidare, o provare un'altra strada se non sta andando veramente dove è necessario.