Cosa fare quando il tuo collega di lavoro non capisce il design che cerca di essere mantenuto [chiuso]

8

Un progetto software su cui sto lavorando coinvolge me e un altro programmatore. Il progetto prevedeva un back-end del motore con un front-end MVC. Inizialmente ho fatto molto del lavoro sul progetto e quindi ho impostato alcune semplici metodologie di progettazione che riguardano principalmente l'astrazione e la strategia dei modelli.

Per un po 'sono stato fuori dal motore e ho lavorato sul sito web. Tuttavia, ho mantenuto un interesse per il motore, poiché mi è stato comunicato che potrei esserci di nuovo a un certo punto.

Il progetto è in una scadenza molto ravvicinata, quindi stiamo tutti correndo come se fossi finito per finire sia sul front end che sul back end.

Non mi considero un grande programmatore e quindi non cerco mai di applicare un particolare design o una serie di metodologie alle persone, dato che non sono sempre sicuro di avere ragione e di avere altre persone che offrono le loro opinioni per cercare di trovare soluzioni migliori. Tuttavia ho notato delle modifiche apportate a questo codice del motore che sta davvero iniziando a infastidirmi. Quando ho affrontato lo sviluppatore per suggerire che ha fatto il lavoro in un altro modo, ha detto di non vedere il punto in cui sembrava esserci poco beneficio considerando le scadenze ravvicinate.

Dovevo cercare di spiegare che il problema che aveva messo in campo poteva significare ulteriore sviluppo dopo il rilascio e non pensavo fosse giusto fare in modo che gli altri prendessero il gioco quando ora potevamo sistemarlo. Ho passato circa 30 minuti a esaminare ciò che avevo fatto e alla fine mi ha chiesto di scrivere il codice in modo tale da poterlo copiare.

La base di ciò che avevo impostato inizialmente era:

  • Una classe astratta x
  • Una classe factory astratta per creare istanze concrete di x

Ciò che era accaduto era che aveva messo un paio di istruzioni if che potevano essere facilmente messe come metodi virtuali / astratti nella classe astratta e poi implementate di conseguenza, dato che la nuova modifica seguiva già lo stesso principio di altri metodi sulla classe astratta .

Questo mi sembra banale, tuttavia non è nemmeno riuscito a capirlo anche quando gli ho mostrato le classi coinvolte.

Ora la mia domanda è:

  1. È ingiusto presumere che avrebbe dovuto cogliere questo concetto. Mi rendo conto che siamo in scadenza, ma ho pensato che fosse banale. Il programmatore dovrebbe essere almeno di livello intermedio.
  2. Questo è successo in un certo numero di posti e ho sempre cercato di farlo cambiare, ma non sembra. Dovrei semplicemente ignorarlo?
  3. Dovrei sollevare questo problema da qualche altra parte, o semplicemente succhiarlo e quando tornerò sul progetto andremo in giro a cambiare tutte queste cose.

La sua parte del progetto non sarà terminata ed è per questo che dovrò tornare ad aiutarlo. Anche io non lo voglio, dato che ha preso un progetto non eccezionale, ma con un'architettura ok e in realtà ha messo un sacco di codice disordinato che più spesso non ha seguito ciò che si stava cercando di ottenere.

Se la domanda è troppo vaga o scarsa, faccelo sapere e proverò a modificarla di conseguenza.

MODIFICATO: il progetto dovrebbe continuare dopo la scadenza iniziale poiché sono già in programma i lavori di follow-up e il lavoro che non abbiamo seguito e che è stato concordato per l'implementazione successiva.

    
posta dreza 02.08.2011 - 05:33
fonte

5 risposte

9

Da quando ho supervisionato forse più di 200 sviluppatori negli ultimi 25 anni, penso che la percentuale di sviluppatori che si trova intuitivamente a proprio agio con il tipo di astrazione di design di cui si parla è qualcosa come un terzo. Il mio approccio si è evoluto dal prevedere di aggiustare questo con coaching, allenamento e incoraggiamento, a lavorare ancora sull'allenamento, ecc., Ma riconoscere che questo conforto ha una qualità innata, e spesso non puoi cambiarlo. Hai chiesto se è giusto. Penso che il fatto che non sia giusto è che il management si aspetti che un membro del team di sviluppo si assuma la responsabilità di questa tensione e dell'impatto. Se hai un capo in giro, prova a spiegare la tensione a loro in THEIR termini non tuoi. Non si tratta dell'altro sviluppatore, ma dell'efficienza, dell'impatto futuro e del rischio = bottom line e quindi una chiara responsabilità di gestione. Cerca soluzioni organizzative che sfruttino le tue abilità pertinenti. Puoi intraprendere ulteriori lavori di guida alla progettazione, e l'altro fare più della finitura. Non dare per scontato che tutti gli sviluppatori non vorrebbero questo ruolo - molti sviluppatori amano essere bravi a finire le cose per soddisfare i clienti in fretta - e sono grati per un ambiente di progettazione di qualità fornito da qualcun altro.

    
risposta data 02.08.2011 - 10:39
fonte
4

A volte non è il concetto ma il tempo necessario per farlo. Le persone non ottengono le cose quando le spiegano velocemente a qualcuno, ma danno loro il tempo di andare a cercarsi e poi lo capiscono. A volte ci vuole un po 'di tempo perché il concetto thr affondi.

Capisco che le scadenze siano limitate e che la conoscenza sia limitata che potrebbe avere avuto un impatto maggiore di quello che vorresti, ma in questo caso (e qui faccio supposizioni), lo hai indicato a modello di design di fabbrica documento, o ti aspettavi che capisse il tuo codice agitandolo sotto il suo naso urlando "non lo capisci , semplicemente non capisci ":)

Potrei anche aver fatto lo stesso io stesso - mostrare alle persone il codice, aspettarsi che capiscano all'istante, sentirsi frustrati quando sembrano vuoti, ingrandirle nel vano tentativo di farle capire, arrabbiarsi quando ottengono ancora di più confuso, poi o gomitoli fuori strada e fallo da solo o mi viene detto di sgattaiolare via e fallo da solo se sono così dannatamente intelligente. Che è tutta una reazione comprensibile ai miei poveri tentativi di insegnante.

    
risposta data 02.08.2011 - 10:53
fonte
3

Classi astratte, fabbriche di classe, non fraintendermi, ma suona come un'artiglieria per uccidere un uccello. I modelli sono lì per risolvere i problemi non per crearli. Hai ammesso che il progetto è un progetto di 2 persone.

Ciò che il tuo collega sta facendo male, però, è che non sta seguendo le linee guida. Farà un po 'di casino a valle. Se il progetto è astratto in tutti i modi, allora dovrebbe cercare di seguire.

    
risposta data 02.08.2011 - 09:04
fonte
1

Non volevi forzare il modello su di lui dall'inizio, ma avresti potuto avere una breve discussione su alcune delle cose che hai fatto. Sotto i limiti di tempo, dubito che sarà in grado di cogliere il tuo concetto abbastanza per essere in grado di implementarlo velocemente come il suo 'hack'. Vuoi che aggiusti le cose ora per impedire a qualcun altro / te di doverle risolvere in seguito, ma il progetto non verrà fatto in tempo. O non capisce cosa stavi facendo o sente che ci vorrà troppo tempo e non vale la pena rischiare.

Deve essere noto quando il progetto può essere completato e sollevare preoccupazioni su questi limiti in futuro e la necessità di ulteriore tempo. Avrai qualche difficoltà a convincere tutti a vederlo a modo tuo se il cliente è soddisfatto. Potrebbe non essere giusto, ma è la realtà.

    
risposta data 02.08.2011 - 05:51
fonte
1

Probabilmente non è un problema tecnico, sicuramente non è un problema di programmazione. Sembra niente più che il tradizionale dibattito sulla "programmazione per il futuro possibile contro le scadenze di oggi", che è un caso specifico di "Non mi piace il modo in cui l'altro ragazzo fa il suo lavoro, voglio che lo faccia a modo mio ". Succede ogni giorno in tutti i luoghi di lavoro con più di 1 membro dello staff.

Le tue abilità di gestione e di vendita saranno più importanti di qualsiasi superioirty tecnica nel tuo progetto se vuoi "vincere" questo.

Suggerisco di leggere libri come "Come vincere gli amici e influenzare le persone" e "Di che colore sei il paracadute" e altri libri sulle abilità delle persone.

    
risposta data 02.08.2011 - 10:32
fonte

Leggi altre domande sui tag