Domanda:
Il consulente IT se n'è andato e nessuno può capire il suo stile di programmazione
Rose
2015-09-23 02:16:42 UTC
view on stackexchange narkive permalink

C'è un piccolo gruppo di programmatori in cui lavoro. Qualche anno fa il nostro capo ha portato un consulente per aiutarci a passare a un nuovo linguaggio di programmazione. Da allora il nostro capo si è "dimesso" e ora abbiamo un nuovo capo. Il consulente se n'è andato di recente e tutto ciò su cui stava lavorando è stato diviso tra gli sviluppatori esistenti. Questo consulente principalmente "lavorava da solo" mentre noi tutti ci sedevamo a chiederci cosa stesse facendo, prendeva indicazioni solo dal capo che ora non c'è più. Tutti i loro incontri sembravano segreti, nessuno degli sviluppatori esistenti aveva voce in capitolo o input in alcun modo.

Il problema è che nessuno degli sviluppatori esistenti può lavorare sul nuovo codice perché non capisce come lavori. Il consulente era troppo qualificato. I suoi modi avanzati di programmazione ci hanno lasciato in una situazione in cui anche le richieste più semplici non possono essere completate.

Ora dobbiamo gestire questa risorsa internamente, ma non ci è stata data l'esperienza o la conoscenza per farlo. Come possiamo gestire questo problema?

Questa potrebbe essere una domanda per http://programmers.stackexchange.com poiché riguarda più come decifrare il codice che sul posto di lavoro. Tuttavia, puoi chiedere al consulente per un giorno di spiegare il suo codice?
`Il consulente era troppo qualificato. I suoi modi avanzati di programmazione ... `Questo non sembra un individuo * troppo * qualificato, ma piuttosto un lupo solitario. Un programmatore che crea codice complicato e difficile da capire ** non ** è un buon programmatore, non importa quanto bene funzioni quel codice.
Voto per chiudere questa domanda come fuori tema perché non sembra riguardare la navigazione sul posto di lavoro come definito nel Centro assistenza.
@Lilienthal Il richiedente ha un problema con un ex dipendente che non fornisce informazioni sul passaggio di consegne su una risorsa aziendale: si tratta principalmente di un problema sul posto di lavoro
Solo una nota a margine, leggere e comprendere un codice errato fa parte del tuo lavoro di programmatore. Il codice di tutti gli altri fa schifo. Anche il tuo di qualche settimana fa fa schifo. Tutto il codice fa schifo. Non aspettarti mai che non faccia schifo.
@JaneS - Penso che questa domanda potrebbe funzionare in entrambi i posti. C'è l'aspetto del programmatore di come lo capiscono. e c'è l'aspetto sul posto di lavoro di come scoppiano e affrontano il problema aziendale che hanno.
I commenti non sono per discussioni estese; questa conversazione è stata [spostata in chat] (http://chat.stackexchange.com/rooms/29462/discussion-on-question-by-rose-it-consultant-left-and-no-one-can-understand- il suo).
Sette risposte:
Kent A.
2015-09-23 02:53:20 UTC
view on stackexchange narkive permalink

È una situazione molto comune che si presenta sul posto di lavoro: il supereroe onnisciente ora se n'è andato (nel bene o nel male, e per qualsiasi motivo), e il team di persone normali normali è lasciato a prendere e continua.

Passaggio 1. Parla con i tuoi dirigenti e informali dei fatti. Non accusare, giudicare o criticare. Spiega solo che quando tu e il team avete iniziato a esaminare il software, è molto difficile seguirlo e ci vorrà più tempo per acquisire familiarità con ciò che contiene. Di conseguenza, il nuovo lavoro sarà più lento per un periodo di tempo.

Passaggio 2. Dividi e conquista. Come squadra, dividi il software in qualsiasi modo tu possa concordare e ognuno di voi si impegna a diventare l'esperto del team nella propria parte di codice. Immergiti. Apporta piccole modifiche, prova a prevedere i risultati, ricostruisci e verifica se hai previsto correttamente. Datevi una scadenza (forse 1 o 2 settimane). Crea la documentazione per te stesso.

Passaggio 3. Insegna a vicenda i tuoi risultati. Riunisciti regolarmente per discutere di ciò che stai trovando. Ritenetevi reciprocamente responsabili della produzione di una buona documentazione che può essere combinata in una sorta di manuale. Invia la documentazione alla tua direzione affinché si accorga che stai facendo progressi.

Passaggio 4. Ripeti finché non sei competente.

Nel Passaggio 2, potrebbe includere lo svolgimento del lavoro effettivo come un modo per immergersi e capire come funziona tutto.

È una bugia che il guru fosse troppo qualificato per il lavoro. Quello che è realmente accaduto è che tu e il resto della squadra gli avete permesso di affrontare tutto, e non vi siete applicati all'apprendimento del sistema come avreste dovuto. Potrebbe essere il peggior software progettato mai, o potrebbe essere un'opera d'arte. Ma non lo saprai mai finché non ne prendi possesso, sia professionalmente che emotivamente.

Buona risposta. Vorrei solo aggiungere che, a meno che il consulente non abbia inventato una nuova lingua, ci sono risorse ovunque per quasi tutte le lingue. Non capisco perché il tuo team non sia stato attivo nell'apprendimento completo della nuova lingua o almeno abbastanza per eseguire semplici operazioni di gestione e alterazione. Se ho capito, era lì da anni, ma alla fine era un consulente. Cosa pensava che sarebbe successo il tuo team / capo? Colorami perplesso. Immagino di considerarla un'esperienza di apprendimento, fare ciò che ha detto Kent e spiegarlo al tuo capo nel miglior modo possibile.
Renditi conto che non esiste un prerequisito affinché il programmatore sia super intelligente per non comprendere il proprio codice. Possono essere super stupidi e anche le persone non capiranno il codice.
Per # 2, ti suggerisco anche di iniziare a capire come aggiungere test (o eseguire quelli esistenti) in modo che mentre modifichi le cose, sai se hai rotto qualcosa man mano che arrivi alla velocità e apporti modifiche. La scrittura di questa infrastruttura di test ti aiuterà anche a capire come funziona. Questo ti aiuterà a prendere confidenza con il codice di base.
L'ho visto in entrambi i modi. I programmatori che pensavano di essere super intelligenti e creavano un pasticcio eccessivamente complesso, e i programmatori che sono stati schiaffeggiati per aver tentato di utilizzare le tecniche attuali in un negozio che era bloccato nel passato. Per alcuni negozi, l'iniezione di dipendenza e la programmazione funzionale sembrano marziane.
Aggiungerei un passaggio 5 per determinare se il mantenimento del codice originale vale il tempo / l'upskill per un nuovo sviluppatore. Potrebbe essere più conveniente eseguire il refactoring / sostituire il codice mentre procedi.
Potrebbe valere la pena sottolineare l'importanza di essere onesti riguardo a qualsiasi mancanza di capacità nel team. Se si tratta di una nuova lingua o stile di codifica, può essere difficile da capire per le persone. Hai il background di dire che non ci è mai stato concesso molto tempo per interagire con il consulente o il codice, quindi c'è una lacuna nelle nostre conoscenze. Se sei disposto a imparare, chiedi tempo e / o formazione per aiutarti. Se non lo sei, evidenzia la necessità di un nuovo membro del team con un set di abilità diverso.
@kevincline: E al contrario, non ho mai visto nessuno essere rimproverato per aver usato un codice troppo semplice :) Può sempre essere ottimizzato se necessario.
@kevincline, In un lavoro precedente mi è stato detto una volta di limitare l'uso dei puntatori e di non utilizzare l'aritmetica dei puntatori nel codice C perché rendeva il mio codice "difficile da capire". Perché i puntatori sono difficili. O qualcosa.
@kevincline Ho visto succedere esattamente quella cosa, tranne per il fatto che il programmatore stava usando Inversion of Control invece dell'iniezione di dipendenza. Nessuno capiva il suo codice e lui non poteva ottenere il supporto della direzione, quindi se ne andò, e ci vollero anni e più del 50% del fatturato del management prima che il dipartimento di sviluppo prendessimo un altro colpo a quei moderni paradigmi di programmazione. Ma quando l'abbiamo fatto, lo abbiamo fatto insieme.
@Juha: nella mia esperienza "semplice" spesso significa "copia-incolla, facilmente comprensibile riga per riga, ma non testato, non verificabile, non mantenibile"
Kilisi
2015-09-23 02:30:40 UTC
view on stackexchange narkive permalink

Sembra abbastanza semplice. Dì al tuo nuovo capo, è un problema di cui deve essere consapevole. E prima è, meglio è perché questo potrebbe rapidamente degenerare in un problema molto serio per l'azienda se fosse necessario un lavoro urgente e nessuno sapeva da dove cominciare.

Spiega al nuovo capo in pratica quello che ci hai appena detto e poi lascia che se ne occupi lui. Con un po 'di fortuna potresti persino ricevere una formazione retribuita per migliorare le tue competenze a spese dell'azienda.

È sempre meglio avere una soluzione in mente quando si parla di problemi a un capo. In questo caso il miglioramento delle competenze è un'opzione che vorrei menzionare, il che significherebbe una pausa da altri compiti in modo che tu o un altro sviluppatore possiate concentrarvi meglio.

Un'altra possibile soluzione da menzionare è un consulente da portare a breve lavorare con gli sviluppatori.

Quindi in pratica lascia che il capo faccia il suo lavoro e prenda le sue decisioni.

Penso che questa sia una cattiva soluzione, soprattutto per una piccola impresa in cui il costo di una gaffe come questa non può essere assorbito.
ignorarlo è una soluzione peggiore, vedere un problema, risolverlo o portarlo a qualcuno che può, è comunque la mia politica. Soprattutto per una piccola impresa che dispone di risorse limitate. E prima è, meglio è se si desidera mantenere i costi il ​​più bassi possibile nel lungo periodo.
@KentAnderson buon punto, avrei potuto formularlo meglio, lo intendevo più in termini di "è un problema di cui il capo deve essere consapevole"
guest
2015-09-23 08:00:44 UTC
view on stackexchange narkive permalink

Ciò di cui hai bisogno è una panoramica dell'architettura e la persona migliore per fornirla è il consulente. Se parlare con lui non sta portando da nessuna parte, lascia che prepari diagrammi, come tutto è collegato insieme, ad alto livello.

Con queste informazioni, guarda il codice, prova a identificare le cose o dove vorresti Fare cambiamenti. Quindi, in un secondo round, lascia che descriva in modo più dettagliato le cose che vuoi cambiare e dove farlo.

Gli dai un elenco di funzioni AF e per ogni funzione ti dice il file e forse nome della funzione. Quindi provi a implementare le tue modifiche. Cerca di coinvolgerlo il meno possibile, in modo da capire meglio dove sono i tuoi deficit e cosa devi imparare.

Non provare a migrare direttamente le cose nelle tue lingue conosciute. C'è una ragione per cui è stato portato qui e la sua lingua potrebbe essere migliore. Cerca di impararlo, in modo da poter prendere una decisione istruita quali parti mantenere e quali parti spostare in un linguaggio familiare o completamente diverso.

Prova anche a capire quali parti del suo codice sono standard per quella lingua e quale ha appena hackerato insieme. Prova a passare a soluzioni standard dove ritieni opportuno. Ciò rende la manutenzione futura molto più semplice e ridurrà la formazione per i nuovi colleghi che già conoscono la lingua e il modo standard di fare le cose.

Solo per curiosità, di che tecnologia stiamo parlando? :)

gnasher729
2015-09-23 13:52:23 UTC
view on stackexchange narkive permalink

L'80% della risposta appartiene allo sviluppo del software (probabilmente programming.stackexchange).

Il 20%: devi dire al tuo nuovo manager o nuovo capo il prima possibile cosa sta succedendo. Probabilmente il modo migliore per lui di risolvere il problema è assumere un appaltatore esperto per un mese per valutare il codice di quella persona (solo perché pensi che fosse troppo qualificato non lo rende così; una persona altamente qualificata lascerebbe codice che puoi raccogliere ).

Dopo quel mese, l'azienda deve decidere che il codice di questa persona è solo spazzatura e non può essere recuperato, oppure chiedere a quell'appaltatore di rimanere per altri pochi mesi, mettere il codice in una forma che possa essere mantenuto e addestrare alcuni di voi per essere in grado di assumersi il lavoro.

D'altra parte, quella valutazione potrebbe essere molto rapida: ad esempio, scrivo molto codice in Objective-C con blocchi, e se non l'hai mai visto, sembra spaventoso. Ci vuole una settimana per impararlo e due settimane per amarlo. Quindi in quella situazione qualcuno potrebbe entrare e dire "questo è solo un normale codice Objective-C, devi solo impararlo" (si applicherebbe a qualsiasi altra lingua).

Jonathan Rosenne
2015-09-23 13:17:04 UTC
view on stackexchange narkive permalink

Il refactoring è la strada da percorrere. Costerà tempo e denaro e probabilmente avrai bisogno di un consulente specializzato per farlo.

Ciò significa che prendi il codice complicato e impenetrabile e lo modifichi passo dopo passo, preferibilmente utilizzando strumenti ma anche a mano e test di regressione ogni passaggio. Il refactoring spazia da cose relativamente semplici come la ridenominazione di variabili e procedure a nomi più comprensibili, alla ristrutturazione del codice. Ogni passaggio è gestibile individualmente e non cambia ai risultati del codice. Ovviamente mantieni il codice originale separatamente poiché sarà il tuo metro e punto di riferimento.

A proposito, nel processo molto probabilmente scoprirai bug nel codice originale ed è una decisione difficile quando farlo correggili - durante il refactoring o dopo che è stato completato - perché se li aggiusti troppo presto potresti perdere la possibilità di confrontare l'output del codice refactoring con l'output del codice originale.

Buona fortuna.

Questa sembra una soluzione molto intensa per la parte di codice di questo particolare problema, ma una bella spiegazione del refactoring
Quando hai detto: "* probabilmente avrai bisogno di un consulente specializzato per farlo *" ho pensato che fosse divertente. Non sono sicuro, era uno scherzo? Sembra che sia mancato a tutti, incluso te se non lo intendevi come tale!
Stavo solo cercando di essere gentile.
Keltari
2015-09-23 07:39:32 UTC
view on stackexchange narkive permalink

Questo non è raro. Sono stato in situazioni simili e può essere opprimente. Parla con il tuo supervisore e spiega la situazione, come hanno detto altre persone.

La prima cosa che farei è chiedere all'ex consulente se è disposto a tornare e spiegare il suo codice. Potrebbe essere gentile e farlo gratuitamente. Tuttavia, potrebbe tornare solo se lo paghi.

A questo punto spetta a te e al tuo team di sviluppo prendere appunti e porre quante più domande possibile. Impara il più possibile su come e perché ha scritto il suo codice nel modo in cui ha fatto.

MACMAN
2015-09-23 13:35:16 UTC
view on stackexchange narkive permalink

Per prima cosa controlla lo stile di codifica. Ha usato un framework? In tal caso, prima controlla la documentazione del framework e cerca di capire il concetto. Una buona revisione del codice è la prossima cosa che devi fare. Una revisione del codice rivelerà come e perché viene implementato un determinato codice. Una task force speciale può essere affidata al R&D e alla revisione del codice. Una volta trovato il flusso di codifica, si tratta di iniziare da lì.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...