Come esercitare deliberatamente l'ingegneria del software? [duplicare]

C'è una differenza tra ciò che facciamo come ingegneri del software e ciò che farebbe un violinista (o qualsiasi altra cosa che richieda la pratica fisica). Un violinista trascorre ore praticando metodicamente perché stanno insegnando al cervello schemi molto specifici su come interagire con uno strumento.

La pratica dell'ingegneria del software implica anche modelli di apprendimento. Più progetti fai, più imparerai (si spera) su cosa funziona e cosa no. Non esiste una ricetta standard per scrivere un ottimo software (ecco perché alcune persone paragonano la nostra professione a un "mestiere" piuttosto che a una scienza pura). Quindi il mio consiglio # 1, scrivi il codice, poi scrivi altro codice. E non pensare che se quello su cui stai lavorando sia divertente, non ti sta insegnando tanto. Dico scegli qualcosa che sia divertente; manterrà il tuo interesse più a lungo e ti divertirai molto di più.

Non è necessario unirsi a un progetto open source se non lo si desidera. Basta fissare un obiettivo per te stesso, qualcosa ti interesserebbe e iniziare a programmare. Non hai nemmeno bisogno di finirlo, quindi non rimanere deluso se a metà del progetto decidi di lasciarlo e andare a qualcos'altro. Soprattutto quando ti allontani da quel progetto, devi andare via con abilità migliori e più conoscenza della tecnologia che hai usato.

Suggerimento n. 2, leggi Programmatore pragmatico . Prendersi cura di questo libro è che proprio mentre si pensa a come scrivere un software, una volta ogni tanto è necessario fare un passo indietro e rivedere il processo per pensare di scrivere un software. Ogni volta che lavori, non limitarti a metterlo su un riparo e vai avanti, ma guarda un'altra volta e pensa a come potresti averlo fatto meglio. Non devi andare e in realtà rifarlo, ma a pensarci, eserciterà il tuo cervello a riconoscere gli schemi che ho menzionato nell'introduzione.

Consiglio n. 3, parla con altre persone che sono appassionate di scrivere codice. Ascolta cosa hanno fatto e come si sono avvicinati alle cose. E spiega loro cosa stai facendo. Ho pochi amici al lavoro e periodicamente vorrei semplicemente entrare nel loro cubo e abbozzare rapidamente il design del software su cui sto lavorando. A volte annuiscono, ma altre volte potrebbero dire, bene se sposti questa scatola qui e ti liberi di questa lezione, potresti risparmiare 2 giorni di lavoro e ottenere vantaggi A, B e C.

Consiglio n. 4, dopo aver fatto pochi progetti e trovato alcuni modelli. Torna indietro e leggi libri come il famoso libro GoF . Se hai già lavorato, a) riconosci alcune delle cose di cui parlano gli autori eb) scoprirai diversi modi in cui potresti aver contattato i tuoi progetti.

Consiglio n. 5, continua sempre a leggere e sfidare te stesso. Non entrare mai nella modalità che ora conosco la tecnologia X, quindi sono un esperto. Non importa quanto pensi di aver imparato, ricorda, c'è infinitamente di più là fuori per te per l'assorto, quindi in un grande schema di cose, non lo sai ancora molto. Continua a leggere i blog; impara una nuova lingua. Ad esempio, ho letto di F # e della programmazione funzionale, anche se principalmente programma in C ++ e ho iniziato ad applicare concetti funzionali al mio codice orientato agli oggetti. In alcuni punti questo ha semplificato notevolmente l'uso di più thread e la sincronizzazione dei dati.

Nessuna delle precedenti è ingegneria del software. È tutto solo programmazione in modo casuale.

Software Engineering (SE) è una disciplina ingegneristica che si occupa di un approccio sistematico, rigoroso e disciplinato alla progettazione, allo sviluppo, al funzionamento e alla manutenzione del software, e allo studio di questi approcci; cioè, l'applicazione dell'ingegneria al software.

In particolare, il software può essere progettato quando si applicano tecniche di ingegneria. Per apprendere tali tecniche, la cosa migliore è studiare un Master SE pertinente. Quando insegni a te stesso, potresti imparare a programmare, ma non riesco a immaginare che tu stia imparando l'ingegneria da solo.

Esempio: Il programmatore arriva e inizia a scrivere codice, ottimizzando il codice, ecc. (Tutto ciò che conta per un programmatore è il codice e nient'altro che il codice). I progetti complessi sono spesso in ritardo, il budget viene superato fino a pochi ordini di grandezza e il software non risolve bene i requisiti. Questo è noto come crisi del software. La risposta è la disciplina SE.

SE arriva e vuole capire il dominio del problema come prima cosa. Viene applicato un approccio ingegneristico, in particolare Requirements Engineering (RE) (requisiti elicitazione - > analisi dei requisiti - > specifica dei requisiti - > convalida dei requisiti).

Il risultato di RE è in genere un insieme di modelli come modello contestuale, modello comportamentale e modello di processo aziendale. Da questi modelli, SE comprende il problema aziendale e progetta una soluzione software.

Il design in genere significa che SE traduce i modelli dei requisiti in architettura di sistema basata su componenti e quindi progetta il design dei componenti per ciascun componente singolarmente. Ciò si traduce in una specifica specifica dei limiti dei componenti, delle interfacce dei componenti e delle classi da cui comporre i componenti.

Il passo successivo è qualcuno che arriva a queste interfacce (solitamente generate automaticamente) e ne crea l'implementazione. Quella persona potrebbe essere un programmatore. Infine, SE segue con la convalida del software in cui tutto è testato rispetto alla progettazione e ai requisiti originali.

In SE, i progetti hanno in genere un piano di progetto che consente agli ingegneri di pianificare, controllare e monitorare i progetti. In particolare, il software è progettato in base al tempo, al budget, alle specifiche.

Durante la fase di implementazione del software, la documentazione viene prodotta per ogni artefatto e vengono generati molti elementi di configurazione (CI). Questi devono essere gestiti in qualche modo. Di solito, in SE, sono presenti un repository SCM (Software Configuration Management) e Change Management. Un'altra parte di SE è Software Process (SP), ad esempio RUP, Scrum, DSDM, Crystal, Waterfall, ...

SP deve essere documentato e rigorosamente seguito come nella documentazione, senza eccezioni, in modo che i risultati siano sempre riproducibili. (ISO 9000). Questo si riferisce alla qualità del software.

Un altro argomento di SE è Software Measurement and Estimation che ti consente di misurare l'efficienza del tuo SP, le prestazioni del team, le dimensioni del progetto (LOC - Lines of Code) ovvero COCOMO, la consegna stimata del progetto (giorni uomo) e simili.

C'è ancora molto altro da fare a SE di questa breve risposta. Applicare approcci SE invece di scrivere solo codice è come pratichi SE.

Dato che SE è ancora un campo emergente, succede che i non-ingegneri si chiamano ingegneri. A meno che non stiano applicando approcci ingegneristici, sono semplicemente programmatori.

Per ulteriori letture, vedi Ingegneria del Software di Ian Sommerville e www.ieee.org / www.computer.org. In queste risorse, SE è la disciplina ingegneristica. Su Stack Overflow e in molte aziende, sfortunatamente, prendono in prestito il termine SE e lo usano come un altro nome per la programmazione.

Due elementi che mi vengono in mente sono Project Euler e la sfida AI di Google . Soprattutto se lo fai in una lingua diversa dalla tua lingua di lavoro del giorno, questi tipi di problemi sono abbastanza limitati per allungare le tue abilità, ma anche abbastanza semplici da avere un approccio chiaro.

Ho fatto la sfida AI quest'anno, e quello che trovo più affascinante è che il problema è abbastanza semplice da essere risolto con algoritmi di base, ma se raggiungi il limite di tempo per turno il modo ingenuo. Devi capire non solo la parte rote delle basi, ma anche le ragioni sottostanti dietro di loro per farlo funzionare entro i limiti di tempo.

Dopo aver scritto un blocco di codice che funziona e supera un test, chiediti "questo codice può essere migliore?". In questo contesto, meglio non significa necessariamente più veloce o più efficiente, anche se questo fa parte di esso. La chiarezza del codice è anche importante - qualcuno può guardarlo e capire cosa sta facendo. Chiediti se vuoi inviare quel codice a un potenziale datore di lavoro come rappresentante del tuo miglior lavoro.

Non farlo solo per il tuo codice personale. Vieni in siti come questo e rispondi alle domande che ti richiedono di fornire un esempio funzionante. Scrivere codice che un giorno potrebbe essere copiato e utilizzato da persone che stanno imparando può essere un potente motivatore. Assicurati di farlo con il tuo vero nome in modo da non avere altra scelta che rivendicarlo come tuo.

Un altro modo per farlo - e vedo che lo sei - è scrivere un blog che richiede di fornire il codice. Di nuovo, questo ti costringe a scrivere un codice che sarà di pubblico dominio, aperto alle critiche.

Quando scrivi un codice che sarà letto e scrutato da altri, penso che sia l'equivalente delle scale di pratica.

Un approccio potrebbe essere quello di prendere un progetto relativamente non banale (per esempio oltre 1000 righe) e portarlo in altre lingue. Scoprirai che questo mette in evidenza molte ipotesi fatte per te dalla tua lingua.

Un altro approccio potrebbe essere quello di determinare un progetto più ampio - almeno 10KLoC secondo la tua stima - e iniziare a scriverlo, scrivendolo velocemente. Continua a scriverlo, e poi dopo aver raggiunto l'obiettivo, mantienilo. Questo ti insegnerà a gestire le codebase che si mutano nel tempo.

Solo alcuni pensieri.

In che modo uno scrittore pratica la scrittura di libri?

OK, quello che intendevo dire è che scrivere codice non è come padroneggiare uno strumento musicale. Il ruolo di un programmatore è più di uno scrittore o di un compositore che cerca di trovare il giusto accordo. Quindi dovresti chiederti come fanno questi professionisti a praticare il loro mestiere. In realtà, penso che la nostra professione abbia più cose in comune con quelle che con altre discipline ingegneristiche.

Uno scrittore pratica la scrittura scrivendo libri e un compositore pratica componendo componendo musica, quindi un programmatore dovrebbe praticare la programmazione programmando.