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

Sono Elvis, sto provando molto a imparare ad essere Einstein. Lavoro per Mort.

Di che diavolo sta parlando questo pazzo idiota!?!? (Devi solo leggere i primi paragrafi)

Se non hai voglia di leggere quel link, in sostanza, sono un programmatore professionista e il mio capo è (questo è quasi esatto):

il programmatore professionale line-of-business che non ha una laurea in informatica ma ha molta familiarità con Office e VBA e che in genere scrive applicazioni di produttività condivise tra i suoi colleghi

Detto questo, gran parte del mio lavoro consiste nel prendere il suo codice combinato e renderlo pronto per la produzione. Tuttavia, lo stile molto scarso e il cultismo del carico rendono questo difficile. Ciò è aggravato dal fatto che non è disposto a leggere libri di programmazione o permettermi di aiutarlo a riformattare il suo codice.

Ci sono altre strategie per aiutare qualcuno che non è un programmatore professionista, non sarà mai un programmatore professionista a scrivere in futuro un codice più leggibile e utilizzabile per me da usare e interpretare?

Osservando 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 di specializzazione in cui ci vogliono esperti di dominio (chiamiamoli scienziato) per capire come incorporare e personalizzare gli algoritmi per i problemi a portata di mano.

Piuttosto che lamentarsi dello scienziato e aspettarsi che cambino, renditi conto che non dovresti aspettarti che lo scienziato si preoccupi molto della "qualità del codice". Spesso è difficile convincere altri sviluppatori di software a preoccuparsi della "qualità del codice" e tanto meno di qualcuno i cui interessi principali risiedono nel dominio e non nella programmazione.

La tua destinazione dipende in gran parte dal grado di fiducia che lo "scienziato" ha nella tua capacità di comprendere il loro lavoro. Se hanno la certezza che puoi capire il loro codice e non lo confonderanno quando modifichi le cose, di solito non c'è un problema. Faranno affidamento sulla tua esperienza.

Tuttavia, se lo scienziato non vuole che tu modifichi il suo codice, è molto probabile che tu non abbia "guadagnato" ancora la sua sicurezza. In tal caso, invece di concentrarti sul fissare lo scienziato, dovresti concentrarti sul "riparare" te stesso. Quello che intendo con ciò è prendere provvedimenti per guadagnare la loro fiducia. Probabilmente il modo più semplice per farlo è il seguente:

Come parte del processo di test:

1. Inizia a trasformare gli algoritmi in qualcosa di più facile da capire (ad es. Diagrammi, PDL, notazione matematica)
2. Impara a capire gli algoritmi.
3. Assicurati di identificare i casi limite.
4. Chiedi allo scienziato se la tua rappresentazione "alternativa" semplificata è corretta
5. E PIÙ IMPORTANTE identificare i problemi che hai riscontrato; E senza sembrare "accusatorio" dire qualcosa del tipo "Stavo guardando l'algoritmo e ho notato che XYZ dovrebbe fare questo o dovrebbe farlo?". Niente guadagnerà la loro fiducia meglio di questo proiettile.

Una volta che inizi a trovare bug e hai dimostrato interesse nella 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 sentiranno nemmeno più la necessità di codificare un prototipo. Scriveranno semplicemente qualcosa in una di quelle notazioni "alternative" che hai insegnato loro (senza che nemmeno se ne accorgano) e avranno la certezza che capirai cosa significano.

In ogni caso, il mio primo tentativo sarebbe quello di offrire alcuni suggerimenti su come lo scienziato possa 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 dal passare la codifica a qualcun altro e non dovrà preoccuparsi di tutti i piccoli dettagli che vanno nella scrittura del codice. Preferirebbero di gran lunga 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 ad arpiare per qualcosa che hanno già rifiutato o deciso di non voler fare, anche se hai ragione al 100%. In realtà, ciò danneggerà una relazione, che tu sia il suggeritore o il suggeritore. Concentrati solo su ciò che TU 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 "prendendo il suo codice acciottolato e rendendolo pronto per la produzione", sembra che il tuo il team di due uomini sarebbe più produttivo quando ti lascerebbe la programmazione e si concentrerà sulla parte manageriale del progetto.

Tuttavia, questo presuppone che tu abbia ragione. Noi programmatori tendiamo sempre a ignorare il codice scritto da altre persone molto peggio del nostro. Questo preconcetto è davvero difficile da sconfiggere e ci porta a sottovalutare i nostri colleghi. Ciò che consideri "programmazione di culto del carico" potrebbe essere "best practice comprovata" dal suo punto di vista, e ciò che consideri "applicazione elegante di schemi orientati agli oggetti" potrebbe essere "inutile ingegneria eccessiva" per lui. Difficile da dire per me, perché conosco solo il tuo lato della storia.

Lo sdegno per il codice di altre persone diventa più forte quanto più diversi sono i nostri stili di programmazione. In questo caso è un istinto positivo, perché mescolare diversi stili di programmazione in un progetto rende molto difficile mantenerlo.

Quando entrambi non siete in grado di imitare lo stile dell'altro, allora potreste definire responsabilità chiare. Rendere una persona responsabile per una parte della domanda e l'altra persona 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 test di unità per lui e sottolineare quando il suo codice ovviamente non si comporta secondo il contratto di interfaccia che hai specificato insieme.

Stabilendo una chiara proprietà del codice è possibile raggiungere una migliore coesistenza dei diversi stili. Inoltre, quando entrambi siete responsabili della correzione dei bug nel loro codice, non dovrete navigare spesso nel codice degli altri.

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

Se il tuo obiettivo è:

1. Aiuta il tuo capo? Lasciar perdere. Non sembra chiederlo. Hai detto: "Sa che il suo codice è cattivo, ma fa quello di cui ha bisogno." Bene, quindi, fine della discussione. A meno che e fino a quando il tuo capo non sarà insoddisfatto della situazione attuale, non cambierà e si risentirà dei tuoi sforzi per aiutarlo. Se ad un certo punto in futuro "sentirà il dolore" dello status quo, si spera che ti sarai affermato come un mentore affidabile e che saprà dove chiedere aiuto.

2. Aiuta la tua azienda? La situazione attuale sta minacciando i profitti? Le scadenze sono a rischio? Il management superiore sta aumentando il suo calore? In caso contrario, allora rinuncia. (Questo è essenzialmente il punto che Jimmy Hoffa ha fatto nel suo commento al tuo post originale.) Se, tuttavia, la situazione attuale in realtà rappresenta un rischio inaccettabile per il tuo dipartimento / azienda, allora un cambiamento di processo è in ordine. In tal caso, ti suggerisco di sederti e delinearne uno diversodivisione del lavoro. La chiave qui è spiegare che il tempo che dedichi al refactoring del codice del tuo capo sarebbe meglio speso a scrivere nuovo codice. Dici che non hai tempo di scrivere tutto da solo, ma non è quello che sto suggerendo. Devi capire come massimizzare i tuoi rispettivi punti di forza. Smetti di pensare a lui come un Mort e pensa a lui come uno sviluppatore junior con una conoscenza del dominio superiore. Questo è un accordo di lavoro molto comune nel settore e ti stupirebbe imparare a prosperare in esso. Ad esempio, assicurarsi che egli sa che si sa quanto sia essenziale la sua esperienza è (ripetere questo passaggio spesso), e poisuggerisco umilmente la seguente strategia (o qualcosa di simile) come un percorso più rapido per ottenere le sue conoscenze sul mercato: (a) suddividere il lavoro in sprint "agili", (b) collaborare pesantemente in anticipo (in ogni sprint) definendo l'over -tutti i requisiti e l'architettura. (c) Lascialo partire e costruire il prototipo per elaborare tutte le decisioni algoritmiche, mentre costruisci l'infrastruttura concordata nel passaggio precedente. (d) Implementa i suoi algoritmi nella tua struttura mentre costruisce test per verificarlo. (e) Conduci i tuoi V&V insieme in un ambiente di programmazione tra pari. (ad es. "Questo test ha avuto esito negativo; perché? errore logico algoritmico o errore di codifica?"; ripetere qui).

3. Aiuta te stesso? Sii onesto qui. Se tutto ciò che stai facendo è lamentarti che non ti piace il tuo lavoro, ti suggerisco di passare più tempo a pensare al n. 2 sopra. Se non ti interessa l'azienda E non ti piace il tuo lavoro, inizia a distribuire il tuo curriculum. Se ti preoccupi della tua azienda ma non ti piace il tuo lavoro, concentrarti su # 2 dovrebbe aiutarti su ENTRAMBI gli account. Ma in quel caso, è un "win-win" solo se è chiaro a tutti che la tua passione deriva davvero 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 su una linea con ShowMessage('Hello');o simili, solo per scoprire che la stessa linea ha più codice, fuori dallo schermo al giusto,

Credo che tu abbia due opzioni di base:

1. Lascia correre il codice . Se il codice funziona e fa quello che dovrebbe fare, a meno che il tuo capo non ti stia specificatamente chiedendo di sistemare il suo codice, lascialo così com'è. Ciò potrebbe anche portarlo a capire che il tuo codice sembra più bello e lasciare il lavoro a te (come indicato anche da Dunk nella sua risposta).
2. Se sei molto determinato a rendere il codice professionale, crea una libreria / framework che possa usare. Se esiste un modello sugli errori / strategie che correggi comunemente, potresti essere in grado di racchiuderli in alcuni file di libreria e darglielo come "libreria di base per l'azienda" , che puoi anche usare come interfaccia comune.