Aiutare qualcuno che non è e non sarà mai un programmatore professionista scrivere il codice che è più leggibile e utilizzabile da usare e interpretare [chiuso]

Guardando le tue risposte in molti dei commenti non so se ti rendi conto che ciò che stai vivendo è abbastanza comune, in particolare quando lavori in campi speciali dove ci vogliono esperti del dominio (chiamiamoli lo scienziato) per capire fuori come incorporare e adattare algoritmi per problemi a portata di mano.

Piuttosto che lamentarsi dello scienziato e aspettarsi che cambino, basta rendersi conto che non ci si dovrebbe aspettare che lo scienziato si preoccupi molto della "qualità del codice". Spesso è difficile convincere altri sviluppatori di software a preoccuparsi della "qualità del codice", figuriamoci di qualcuno i cui interessi principali si trovano nel dominio e non nella programmazione.

Dove vai da qui dipende in gran parte dal grado di fiducia che lo "scienziato" ha nella tua capacità di comprendere il loro lavoro. Se hanno fiducia nel fatto che tu possa capire il loro codice e non lo maccano quando modifichi le cose, di solito non c'è un problema. Faranno affidamento sulla tua esperienza.

Tuttavia, se lo scienziato non vuole che tu cambi il loro codice, è altamente probabile che tu non abbia ancora "guadagnato" la loro fiducia. Se questo è il caso, allora piuttosto che concentrarti sulla riparazione dello scienziato, dovresti concentrarti sul "riparare" te stesso. Ciò che intendo è di prendere provvedimenti per ottenere la loro fiducia. Probabilmente il modo più semplice per farlo è il seguente:

Come parte del tuo processo di test:

1. Inizia a trasformare gli algoritmi in qualcosa di più semplice da capire (ad esempio diagrammi, PDL, notazione matematica)
2. Impara a comprendere gli algoritmi.
3. Assicurati di identificare i casi limite.
4. Chiedi allo scienziato se la tua rappresentazione "alternativa" semplificata è corretta
5. E PIÙ IMPORTANTI identifica i problemi che hai trovato; E senza sembrare "accusatorio" dire qualcosa come "Stavo osservando l'algoritmo e ho notato che XYZ doveva fare questo o è supposto farlo?". Nulla guadagnerà la loro sicurezza meglio di questo proiettile.

Quando inizi a trovare bug e hai dimostrato interesse per la loro area di interesse, le probabilità diventano molto più alte che almeno ti permetteranno di iniziare a modificare il codice per renderlo più "professionale". Spesso, non sentono nemmeno la necessità di codificare un prototipo più a lungo. Scriveranno semplicemente qualcosa in una di quelle "alternate" notazioni che hai insegnato loro (senza che loro se ne rendano conto) e avranno fiducia che capirai cosa significano.

Con ogni mezzo, il mio primo tentativo sarebbe di offrire alcuni suggerimenti su come lo scienziato potrebbe meglio aiutare a "comunicare" meglio per aiutarti; ma sembra che tu ci abbia provato. Quindi l'unico passo su cui hai il controllo è quello che fai. Guadagna la loro fiducia e quasi sempre l'esperto di dominio sarà sollevato per passare la codifica a qualcun altro e non dovrà preoccuparsi di tutti i piccoli dettagli che riguardano la scrittura del codice. Preferirebbero piuttosto concentrarsi sul miglioramento degli algoritmi.

A volte, tutto ciò che puoi fare è offrire un suggerimento e lasciarlo dopo. Non impressionerai il tuo capo o un anziano se continui a insistere su qualcosa che hanno già rifiutato o hai deciso che non vogliono farlo, anche se sei corretto al 100%. In realtà, ciò danneggerà una relazione, sia che tu sia il suggeritore o il suggerente. Concentrati solo su ciò che puoi fare per semplificare il tuo lavoro.

Quando è davvero "qualcuno che non è un programmatore professionista, non sarà mai un programmatore professionista" come dici tu e quando gran parte del tuo lavoro è davvero "prendere il suo codice accostato e renderlo pronto per la produzione", sembra che il tuo team di due uomini sarebbe più produttivo quando lascerà la programmazione per te e si concentrerà sulla parte gestionale del progetto.

Tuttavia, questo presuppone che tu abbia ragione. Noi programmatori tendiamo sempre a ignorare il codice scritto da altre persone come peggio del nostro. Questo preconcetto è davvero difficile da sconfiggere e ci porta a sottovalutare i nostri colleghi. Quello che consideri "programmazione settoriale del carico" potrebbe essere "best practice comprovate" dal suo punto di vista, e quello che consideri "l'applicazione elegante di modelli orientati agli oggetti" potrebbe essere per lui "una inutile sovrastruttura". Difficile dirlo, perché conosco solo la tua versione della storia.

Il disprezzo per il codice di altri popoli diventa più strong e più i nostri stili di programmazione sono diversi. In quel caso è un istinto positivo, perché mescolare diversi stili di programmazione in un progetto lo rende molto difficile da mantenere.

Quando entrambi non siete in grado di imitare lo stile dell'altro, allora potreste definire responsabilità chiare. Rendi responsabile una persona per una parte dell'applicazione e l'altra per l'altra. Definire interfacce chiare tra i due moduli insieme, ma lasciare l'implementazione interna a quella responsabile. Per renderlo più consapevole dei bug nel suo codice, potresti scrivere dei test unitari per lui e indicare quando il suo codice ovviamente non si comporta in base al contratto dell'interfaccia che hai specificato insieme.

Stabilendo una chiara proprietà del codice puoi raggiungere una migliore coesistenza dei tuoi diversi stili. Inoltre, quando entrambi siete responsabili di correggere i bug nel loro codice, non dovrete navigare tra loro spesso il codice.

Devi chiederti: qual è il tuo obiettivo finale qui? 1. per aiutare il tuo capo? 2. per aiutare l'azienda? 3. per aiutare te stesso? E prima di rispondere a "tutto quanto sopra", rallenta. Il tuo primo compito è definire chiaramente il tuo obiettivo primario, perché la risposta dipende da questo.

Se l'obiettivo è:

1. Aiuta il tuo capo? Give It Up. Sembra che non lo chieda. Hai detto: "Sa che il suo codice è cattivo, ma fa quello di cui ha bisogno". Bene, allora, fine della discussione. A meno che e fino a quando il tuo capo non sia soddisfatto della situazione attuale, non cambierà, e si risentirà dei tuoi sforzi per aiutarlo. Se ad un certo punto nel futuro egli "sente il dolore" dello status quo, si spera che tu ti sia affermato come un mentore affidabile e saprà dove venire per chiedere aiuto.

2. Aiuta la tua azienda? La situazione attuale sta minacciando la linea di fondo? Le scadenze sono a rischio? Il management superiore sta aumentando il suo calore? In caso contrario, quindi Give It Up. (Questo è essenzialmente il punto che Jimmy Hoffa ha fatto nel suo commento al tuo post originale.) Se, tuttavia, la situazione attuale rappresenta un rischio inaccettabile per il tuo dipartimento / azienda, allora è necessario un cambio di processo. In tal caso suggerirei di sederti e delineare una divisione del lavoro diversa . La chiave qui è di spiegare che il tempo speso per rifattorizzare il codice del tuo capo sarebbe meglio spendere la scrittura di un nuovo codice. Dici che non hai tempo per scrivere tutto da solo, ma non è quello che sto suggerendo. Devi capire come massimizzare i tuoi rispettivi punti di forza. Smetti di pensarlo come un Mort e pensa a lui come a uno sviluppatore junior con una conoscenza di dominio superiore. Questo è un accordo di lavoro comune molto nel settore e dovresti imparare a prosperare in esso. Ad esempio, assicurati che lui sappia che tu conosci l'essenziale della sua esperienza (ripeti spesso questo passaggio), e allora suggerisci umilmente quanto segue strategia (o qualcosa di simile) come percorso più rapido per portare le sue conoscenze sul mercato: (a) suddividere il lavoro in "agili" sprint, (b) collaborare pesantemente in anticipo (in ogni sprint) definendo i requisiti generali e architettura. (c) Lascialo andare e costruisci il prototipo per elaborare tutte le decisioni algoritmiche, mentre costruisci l'infrastruttura che hai concordato nel passaggio precedente. (d) Implementa i suoi algoritmi nella tua struttura mentre costruisce dei test per verificarlo. (e) Conduci il tuo V & V insieme in un ambiente di programmazione peer. (ad esempio, "Questo test non è riuscito, perché? errore logico algoritmico o errore di codifica?"; iterare qui).

3. Aiuta te stesso Sii onesto qui. Se tutto quello che stai facendo è lamentarti del fatto che non ti piace il tuo lavoro, ti suggerisco di dedicare più tempo a pensare al n. 2 sopra. Se non ti interessa della compagnia E non ti piace il tuo lavoro, inizia a distribuire il tuo curriculum. Se ti interessa della tua azienda ma non ti piace il tuo lavoro, allora concentrarti su # 2 dovrebbe aiutare su entrambi i conti. Ma in quel caso, è un "win-win" solo se è chiaro a tutti che la tua passione deriva sinceramente dal desiderio di aiutare il team, e non solo da una frustrazione egocentrica nel tuo incarico.

Non sono sicuro che aggiungerò qualcosa a questa discussione, ma avendo lavorato in scenari simili in cui una violazione di Access sta colpendo una riga con ShowMessage('Hello'); o simile, solo per scoprire che la stessa linea ha più codice, fuori dallo schermo a destra,

Credo che tu abbia due opzioni di base:

1. Esegui il codice . Se il codice funziona e sta facendo ciò che dovrebbe fare, a meno che il tuo capo non ti chieda specificatamente di correggere il codice, lasciatelo così com'è. Ciò può anche indurlo a capire che il tuo codice sembra più bello e lascia il lavoro a te (come indicato anche da Dunk nella sua risposta).
2. Se sei molto determinato per rendere il codice professionale, crea una libreria / framework che può utilizzare. Se c'è un modello sugli errori / strategie che si risolvono comunemente, potresti essere in grado di racchiuderli in alcuni file di libreria e darglielo come "libreria di base per la società" , che puoi utilizzare anche come interfaccia comune.