Dopo 14 mesi di scrittura del Tecniche di progettazione colonna, è giunto il momento per me di portare la colonna ad una stretta. Sto dicendo addio - per un po '.
In questa puntata finale di Tecniche di progettazione , discuto quello che ho puntato a realizzare con questa colonna e con il mio libro di prossima uscita basato su questo materiale,flessibile Java. discuto il processo di sviluppo del software, la qualità del software, e quale ruolo le linee guida e idiomi presentati in questa colonna può svolgere nell'aiutare a raggiungere la qualità. Io do i link a tutti i precedenti articoli che compongono questa colonna, nonché di argomenti correlati discussione-forum. Infine, guardo al futuro.
Come 'Tecniche di progettazione' è cominciato
Nell'autunno del 1997, dopo aver finito il mio libro Dentro la Java Virtual Machine,ho portato la mia prima JavaWorld colonna - Under the Hood - al termine. Avevo passato un anno e mezzo immerso nella macchina virtuale Java, e ha voluto rivolgere la mia attenzione su un nuovo progetto di scrittura. Per il mio nuovo progetto, ho deciso di unire ciò che sapevo di Java con quello che sapevo sulle buone pratiche di sviluppo software in generale. Ho voluto provare e catturare qualunque cosa che rende il software "buono" dal punto di vista del programmatore, applicare a Java, e mettere il tutto in un libro.
Anche se il mio obiettivo era quello di aiutare i programmatori avere successo nei loro progetti software basati su Java, non volevo cercare di inventare una metodologia - una teoria completa del modo migliore per gestire un progetto software. Metodologie sono difficili da definire, a mio parere, perché il modo "migliore" per gestire un progetto dipende tanto dal progetto particolare e le persone coinvolte in esso. È difficile generalizzare, per definire una metodologia che è universalmente utile. A volte, se si sta lavorando da soli e il progetto è piccolo, una rapida hack è il modo migliore per andare. Si avvia la codifica e può effettivamente progettare come codice. Più persone che diventano coinvolti nel progetto, tuttavia, il più importante è di avere una metodologia formale o processo da seguire. Tuttavia, non avevo alcun interesse nel tentativo di aggiungere una metodologia diversa per i tanti che già esisteva. Ho voluto puntare il mio progetto di scrittura a un bersaglio più piccolo.
In questa puntata finale di Tecniche di progettazione , discuto quello che ho puntato a realizzare con questa colonna e con il mio libro di prossima uscita basato su questo materiale,flessibile Java. discuto il processo di sviluppo del software, la qualità del software, e quale ruolo le linee guida e idiomi presentati in questa colonna può svolgere nell'aiutare a raggiungere la qualità. Io do i link a tutti i precedenti articoli che compongono questa colonna, nonché di argomenti correlati discussione-forum. Infine, guardo al futuro.
Come 'Tecniche di progettazione' è cominciato
Nell'autunno del 1997, dopo aver finito il mio libro Dentro la Java Virtual Machine,ho portato la mia prima JavaWorld colonna - Under the Hood - al termine. Avevo passato un anno e mezzo immerso nella macchina virtuale Java, e ha voluto rivolgere la mia attenzione su un nuovo progetto di scrittura. Per il mio nuovo progetto, ho deciso di unire ciò che sapevo di Java con quello che sapevo sulle buone pratiche di sviluppo software in generale. Ho voluto provare e catturare qualunque cosa che rende il software "buono" dal punto di vista del programmatore, applicare a Java, e mettere il tutto in un libro.
Anche se il mio obiettivo era quello di aiutare i programmatori avere successo nei loro progetti software basati su Java, non volevo cercare di inventare una metodologia - una teoria completa del modo migliore per gestire un progetto software. Metodologie sono difficili da definire, a mio parere, perché il modo "migliore" per gestire un progetto dipende tanto dal progetto particolare e le persone coinvolte in esso. È difficile generalizzare, per definire una metodologia che è universalmente utile. A volte, se si sta lavorando da soli e il progetto è piccolo, una rapida hack è il modo migliore per andare. Si avvia la codifica e può effettivamente progettare come codice. Più persone che diventano coinvolti nel progetto, tuttavia, il più importante è di avere una metodologia formale o processo da seguire. Tuttavia, non avevo alcun interesse nel tentativo di aggiungere una metodologia diversa per i tanti che già esisteva. Ho voluto puntare il mio progetto di scrittura a un bersaglio più piccolo.
La mia area di interesse, e la mia area di competenza, stava scrivendo il codice "bene" e lo sviluppo di progetti "buoni". Volevo scrivere un libro Java po 'simile a Kent Beck Patterns Smalltalk migliori pratiche e di Scott Meyer Effective C + + - in altre parole, un libro di linee guida e idiomi che potrebbero aiutare i programmatori a fare "bene" software basato su Java.
Inoltre, volevo scrivere un po 'su cosa significa "buoni" nel contesto del software. I programmatori generalmente in grado di riconoscere buon codice o un buon progetto quando lo vedono, ma che qualità o di qualità deve un pezzo di codice o un disegno deve essere "buono"? Speravo di affrontare questo problema nel mio progetto di scrittura pure.
La Tecniche di progettazione colonna nasce dal mio desiderio di ottenere il materiale fuori alla luce del giorno in modo che avrei potuto ottenere un feedback da parte della comunità Java come ho scritto. Risposte stato importante per me, perché ho sentito che le linee guida di programmazione, anziché essere tagliato in pietra da alcuni cosiddetti guru lavorare da solo su una montagna, dovrebbero rientrare da una discussione tra le persone che effettivamente hanno a lavorare con un altro codice. Attraverso la Tecniche di progettazione colonna, ho voluto condurre una discussione su disegno di Java, per facilitare la discussione, ho creato un forum di discussione sul mio sito web. (Vedere la sezione flessibile Forum Java per i collegamenti a tutti gli argomenti del forum di discussione.)
Anche se alcuni argomenti pertinenti rimangono che non ho ancora coperto inTecniche di progettazione colonna, è giunto il momento per me di rivolgere la mia attenzione alla realtà scrivere il libro, flessibile Java. Sarò pubblicare il testo del libro-in -progress sul mio sito Web, artima.com, in modo da poter seguire come vado. Sarò anche mantenere il forum di discussione aperto, e vi incoraggio tutte le risposte si possono avere da offrire. Se si desidera ricevere aggiornamenti periodici del mio corso, è possibile unire la mia mailing list. (Vedi Risorse per i collegamenti a tutte queste cose.)
Lo sviluppo di software come 'conversazione'
Recentemente sono stato ospite a un seminario di progettazione object-oriented insegnato da Bruce Eckel e Larry O'Brien. A un certo punto della loro seminario, Bruce e Larry ha dato ai partecipanti una due-pagina "dichiarazione di lavoro" per un progetto software. I partecipanti divisi in gruppi di quattro o cinque, e ogni gruppo ha cominciato a discutere come sarebbe progettare software per soddisfare i requisiti fissati nella dichiarazione di lavoro. Ho vagato da gruppo a gruppo, ascoltare e partecipare alle discussioni. Mentre ogni gruppo aveva la propria personalità, i gruppi avevano molto in comune. In particolare, ho visto in tutti i gruppi lo stesso processo di base in azione, un processo che avevo visto più e più volte in progetti software reali su cui avevo lavorato. Mi piace chiamare questo processo "la conversazione."
Vedo il processo di sviluppo del software come una conversazione, perché durante tutto il processo popolo deve comunicare tra loro, e l'efficacia di tale comunicazione è fondamentale per il successo del progetto. All'inizio di un progetto, ad esempio, una persona o gruppo deve decidere e comunicare i requisiti del progetto. Tali requisiti possono venire in molte forme, da un commento verbale disinvolto nel corridoio di una serie di incontri che si traduce in un documento scritto formale.Indipendentemente da ciò, l'obiettivo deve essere definito e in qualche modo presentato ai programmatori che saranno disegnando l'arco e scoccare la freccia.Questo è il primo aspetto della conversazione.
Una volta (la versione iniziale) i requisiti è stato definito e comunicato, gli sviluppatori devono arrivare insieme ad un certo punto e discutere su come costruire un sistema che soddisfa tali requisiti. E 'questa parte della conversazione che stavo osservando a Bruce e Larry di laboratorio: un gruppo di sviluppatori seduti intorno a un tavolo, brainstorming, nominando le cose, disegnare diagrammi, discutere, ridere, litigare, insistendo, compromettendo, decidendo. Questo scarnatura fuori di un disegno determinato i requisiti è un altro aspetto della conversazione. Non solo il gruppo di decidere su un disegno attraverso l'interazione di gruppo, ma deve anche, in qualche modo comunicare il progetto ad altri che vi aiuteranno a scrivere il codice.
Da qualche parte lungo la strada, naturalmente, codice deve ottenere scritto, e anche questa attività è parte della conversazione. Il codice è parte della conversazione perché gli sviluppatori della stessa squadra devono spesso, guardando il codice, capire quello che gli altri sviluppatori hanno fatto. Tutte le modifiche apportate dovranno poi essere compresi dagli sviluppatori che arrivano al codice tardi. Così, quando si scrive il codice non sono solo comunicando con il computer (dicendogli cosa fare), si è anche comunicando con altri programmatori che possono sempre guardare il codice.
Ci sono molti altri aspetti della conversazione. Le persone che testano il software deve capire che cosa è che stanno testando. I manager devono comunicare con gli sviluppatori, gli sviluppatori con i dirigenti, gli sviluppatori con altri sviluppatori, dirigenti con altri dirigenti, e così via. Per tutta la durata del progetto, piccole e grandi correzioni di direzione devono essere comunicati. Le priorità cambiano.Requisiti cambiano. Problemi imprevisti sono scoperti lungo la strada. Tutte queste cose devono essere comunicati in modo efficace come il processo continua.
Dove 'Flessibile Java' adatta
Quindi, quale parte di questa vasta conversazione speravo di affrontare nella mia scrittura? In parole povere, ho voluto concentrarmi sul codice.
Quanto raro è che il codice mantenimento di qualcun altro è simile a entrare in un edificio ben progettato, che si ammira, come si cammina intorno e pianificare come aggiungere un'ala o fare un po 'rimodernate. Più spesso, mantenendo il codice di qualcun altro è come essere gettato a capofitto in un grande mucchio di viscido, immondizia puzzolente. Devi trovare un modo per riorganizzare la spazzatura per correggere un bug o fare un miglioramento. Fate regolarmente scoperte terribili che Grattugiare contro i tuoi sensibilità di progettazione. Ora non mi piace nuotare in giro spazzatura, e (spero) non lo fai neanche. Così, il mio obiettivo ambizioso per la mia scrittura era per cercare di contribuire a ridurre la quantità di "codice spazzatura" nel mondo - di scrivere un libro che potrebbe aiutare i programmatori a produrre progetti migliori e il codice.
Ma cosa significa 'bene' significa?
Il guaio è, che cosa fa un disegno o un pezzo di codice "migliore" di un altro? Che cosa rende un buon progetto? Ciò che rende il codice buono? Per rispondere a queste domande fondamentali, mi piacerebbe prima piace citare alcuni paragrafi dal mio primo Tecniche di progettazione articolo, in una sezione chiamata "scimmie di sviluppo di software sulla schiena":
Nel mondo reale, come si lavora per progettare e implementare software, avete diverse preoccupazioni da tenere a mente - ". Scimmie sulla schiena" diversi Ogni scimmia compete con gli altri per la vostra attenzione, cercando di convincere a prendere la sua particolare preoccupazione per il cuore come si lavora. Un grande, scimmia pesante pende sulla schiena con le braccia intorno al collo e grida ripetutamente: "È necessario soddisfare il programma!" Un'altra scimmia, questo arroccato sulla cima della testa (come non c'è più spazio sulla schiena), batte il petto e grida: "È necessario implementare con precisione le specifiche!" Ancora un'altra scimmia salta su e giù sulla parte superiore del monitor urla, "Robustezza, affidabilità, robustezza!" Un altro continua a cercare di arrampicarsi la gamba gridando: "Non dimenticare le prestazioni!" E ogni tanto, una piccola scimmia fa capolino timidamente a voi da sotto la tastiera. Quando questo accade, le altre scimmie diventano silenziosi. La scimmietta emerge lentamente da sotto la tastiera, si alza, si guarda negli occhi, e dice: "È necessario rendere il codiceflessibile-. Facile da leggere e facile da cambiare Con questo ", tutte le altre scimmie urlano e saltano sul scimmietta, costringendolo di nuovo sotto la tastiera con la scimmietta fuori dalla vista, le altre scimmie ritornano alle loro posizioni abituali e. riprendere la loro attività abituali.Come ci si siede lì nel vostro cubicolo e lavorare sul software, che scimmia dovrebbe ascoltare? Purtroppo, nella maggior parte dei casi bisogna ascoltare tutti. Per fare un "buon lavoro", sarà necessario trovare un modo per mantenere tutte queste scimmie felice - di trovare un giusto equilibrio tra queste preoccupazioni spesso contrastanti.
In sostanza, la mia opinione è che un buon design e il codice trovare un equilibrio tra flessibilità, prestazioni, e di altre preoccupazioni, ma si appoggiano pesantemente verso la flessibilità. Credo che la flessibilità dovrebbe raramente essere sacrificato in nome della performance. Pertanto, le linee guida e gli idiomi ho presentato nel Tecniche di progettazione colonna miravano principalmente ad aiutare una certa flessibilità nel codice e design Java. Il libro è decisivo, flessibile Java, avrà la stessa attenzione.
Perché la flessibilità?
Perché mi sento che la flessibilità è generalmente la qualità più importante che si può dare ai vostri disegni e codice? La ragione è che, come uno dei miei manager utilizzati per dirla, "software è un prodotto vivo." Codice non è statica. Esso viene costantemente ottimizzato, migliorato, fisso, e così via, da un team di programmatori, una squadra che di solito è in costante flusso di sé.
Il codice è come un testo magico che è in continua espansione e contrazione, cambiando forma su volere di un gruppo di sommi sacerdoti e sacerdotesse élite che sanno come prendersi cura per la cosa. La flessibilità è importante proprio perché il codice deve essere costantemente cambiato, giorno per giorno, mese per mese, anno all'altro. Il più flessibile il codice è - cioè, più è facile da capire e cambiare - il più fluido ed efficiente questa attività fondamentale di sviluppo del software può avvenire.
Quindi, la flessibilità è il focus principale delle linee guida e idiomi ho presentato inTecniche di progettazione colonna. Spero che gli articoli in questa colonna hanno aiutato la conversazione di sviluppo software in molti angoli del mondo, e che continuino a farlo in futuro. Come sempre, i numeri precedenti
di JavaWorldrimarranno on-line, così si dovrebbe sempre essere in grado di arrivare a progettare Tecniche di materiale.
Nessun commento:
Posta un commento
Nota. Solo i membri di questo blog possono postare un commento.