Riflettendo sul progetto finito senza altre critiche tecniche?

3

Sono una cooperativa (al college, ma lavoro 3 mesi, poi corsi per 3 mesi, lavoro di nuovo per 3 mesi, ecc. fino alla mia laurea) presso un'azienda del dipartimento IT. Il mio lavoro di solito ha a che fare con la scrittura di software, ma non siamo una società di software e gran parte del software è scritto in India. Questo termine di lavoro (3 mesi) mi è stato dato un grande progetto, per progettare alcuni software per visualizzare i dati estratti da un altro dei nostri sistemi.

Alla fine di questo termine sono finito con due software per, uno al 100% (i dati che tiravano indietro) e l'altro 80% (il front-end grafico). Mi sono divertito e ho imparato molto come sempre, ma non sono molto contento dei risultati del codice. Non ho mai avuto la possibilità di una revisione del codice o di una possibilità di apprendere le strategie di progettazione e analisi per il motivo che ho menzionato sopra nell'anno in cui sono stato qui (4 termini).

Ecco come è andato il progetto, e riflette come ho fatto praticamente tutti i progetti fino ad oggi, anche se è più chiaro in questo progetto poiché questa è la cosa più grande che ho fatto finora. La prima cosa che ho fatto è stata la presentazione di come l'intero sistema avrebbe operato da un livello elevato. Di solito non lo faccio, ma mi è stato chiesto dal mio capo. Quindi, mi sono tuffato nel problema e ho iniziato a sbattere via. Per me, trovo che aiuti (ed è più divertente allo stesso tempo) a mettere giù qualcosa e lavorare per rivedere l'organizzazione poco dopo, così da poter continuare in modo organizzato. Da lì l'edificio ha rallentato un po 'quando il progetto si è ingrandito. Mi sentirò molto più confuso, ma inizierò anche a disegnare più cose, fermandomi a pensare a come ciò che sto costruendo si inserirà nell'intero sistema. Questo ha continuato per un po 'fino a quando il mio termine di 3 mesi era quasi scaduto. Qui, ho iniziato a correre per fare le cose. Ho iniziato a distruggere alcune organizzazioni a favore di cose veloci in modo da ottenere un prototipo funzionante (mi è stato chiesto solo un prototipo quindi ho pensato che andasse bene e se il progetto fosse andato avanti potrei sempre rivederlo) . È qui che la mia intera cosa ha iniziato a crollare perché non ho avuto il tempo di riflettere correttamente su come gran parte di ciò che stavo codificando avrebbe influenzato tutto il resto. Ora mi sento come se, nella fase finale, avessi un sacco di codice flessibile e strettamente accoppiato con un prototipo a malapena funzionante.

Con il senno di poi, ecco quello che vedo:

  • Ho fatto un buon lavoro sulla panoramica originale e mi ha aiutato anche perché potevo suddividere l'intera cosa in pochi blocchi principali. I problemi cominciarono a sorgere quando entrai nei dettagli di ogni chunk. C'era una buona idea fissa su cosa avrebbe fatto ogni pezzo, ma non le parti specifiche che facevano funzionare quel pezzo (non so cosa avrei potuto fare di più per spiegare comunque ogni pezzo. trovare quando si tratta di dettagli come questo, lo scopro mentre vado).
  • C'erano molte cose sul sistema che stavo estraendo dati da ciò che non conoscevo all'inizio e avrei dovuto avere molte più informazioni su come il sistema funziona nel suo complesso. Tuttavia, all'inizio del termine sono sempre timido e tende a non fare domande. Questo probabilmente ha anche contribuito al fatto che di solito non conosco le specifiche di ogni pezzo fino a quando non lo realizzo.
  • Anch'io sono stato vittima di un po 'di creep dell'oscuramento dato che alcune funzionalità sono state aggiunte all'elenco delle cose da fare con circa un mese e mezzo da percorrere.
  • Non sembro mai sapere esattamente dove voglio andare su parti specifiche. Provo qualcosa e se ciò non funziona, provo qualcos'altro fino a quando non funziona o ottengo qualcosa che è più ordinato. È questo il modo giusto di fare le cose?

Le mie domande:

Che cosa avrei potuto fare meglio? So che nessuno qui conoscerà le specifiche del mio progetto ma non c'è nessun altro con conoscenze di programmazione che potrebbe dirmi come potrei crescere in questa situazione. < br> Come potrei recensirmi meglio? Poiché non ho mai avuto nessun altro in grado di rivedere la mia codifica e non sto lavorando direttamente con altri codificatori, come avrei potuto riflettere meglio sul mio progetto, entrambi dopo, e durante il progetto?
La domanda su cosa potrei fare meglio è diretta principalmente alle parti in grassetto della mia spiegazione, in cui mi sento più preoccupato di come mi sono avvicinato al problema.

    
posta Coburn 26.03.2014 - 21:30
fonte

2 risposte

1

Benvenuti in quasi tutti i progetti di sempre. Quello che hai descritto è in realtà abbastanza normale nel settore, anche nei progetti di squadra. Conoscendo il dominio del progetto alla fine del progetto, si può sapere che di solito si possono trovare cose che avrebbero potuto essere fatte meglio. E poiché le pressioni per rispettare le scadenze incombono, è spesso necessario scendere a compromessi. Entrambe queste idee rientrano in una categoria nota come "debito tecnico".

Il fatto che tu abbia riflettuto su questo e abbia persino fatto questa domanda mostra che vuoi imparare e migliorare. Questa è una grande caratteristica che, se mantenuta, produrrà l'esperienza che nel tempo risponde alle tue domande su "Cosa avrei potuto fare meglio?" e "Come potrei recensirmi meglio?"

Tutti i migliori sviluppatori che conosco sono i tipi che cercano costantemente di affinare le loro abilità. Sono i tipi che di solito guardano al codice di mesi fa e pensano: "Yikes, perché ho fatto un tale casino". (Anche se hanno anche alcune gemme levigate che resistono alla prova del tempo.)

Andando avanti, suggerirei:

  • Continua a provare e continua a controllarti.
  • Scopri i modelli di codifica che aiutano in questi tipi di situazioni.
  • Ricerca su metodologie e processi di sviluppo del software che ti aiuteranno a tenere sotto controllo un progetto.
  • Cerca opportunità di collaborare con gli altri in un progetto in modo che tu possa imparare da loro.
  • Trova un buon equilibrio tra iterare per migliorare il codice e definirlo "abbastanza buono" da fare.
risposta data 02.05.2014 - 06:26
fonte
2

Un paio di pensieri.

  1. Tre mesi non sono un sacco di tempo. Che hai un progetto completo funzionante, e un altro 80% fatto in quel momento (utilizzando l'intero SDLC), è abbastanza impressionante. Nella mia esperienza, i datori di lavoro si aspettano che ciò avvenga in un contesto di cooperative; essere una cooperativa è principalmente un processo educativo, non una spinta al prodotto.

  2. Nel bene o nel male, ottenere un prodotto funzionante fuori dalla porta è generalmente considerato più prezioso che attraversa tutte le migliori pratiche T e tratteggia ogni stile di codifica.

There was a good set idea on what each piece would do, but not the specific parts that made that piece work

È compito di un Software Engineer progettare e codificare implementazioni di problemi specificati. Alcuni problemi sono meglio specificati di altri. Per migliorare su una specifica (presumo che tu avessi un insieme formale di requisiti ), puoi scrivere una Specifica di progettazione software. La SDS descrive l'API pubblica di ogni classe nel tuo progetto e indica cosa dovrebbe fare (gli input e gli output attesi, ecc.). Questo può costituire la base per i Test unitari che formalizzano tali requisiti in una specifica codificata.

I started destroying some of the organization in favor of quick things so that I could get a working prototype

Man mano che acquisisci esperienza nello sviluppo di software, per te sarà più facile combinare la prototipazione rapida con una struttura di progettazione sensata.

    
risposta data 26.03.2014 - 21:46
fonte

Leggi altre domande sui tag