Come dire al tuo capo che il suo stile di programmazione è davvero pessimo? [duplicare]

Chiedigli di spiegarti il suo codice

Digli che non hai mai visto X programmato in quel modo prima e chiedigli perché lo codifica in quel modo. Mostragli il modo in cui lo codifichi e spiega perché lo fai in quel modo (best practice, prestazioni migliori, meno possibilità di errori, più facile per gli altri programmatori leggere / mantenere, ecc.).

Assicurati di preparare tutti i tuoi argomenti in anticipo e concentrati sul motivo per cui il tuo metodo è il migliore, invece del perché il suo metodo è il peggiore. Dopo, vedi se supporta ancora il suo metodo sul tuo.

Se è aperto al miglioramento, probabilmente cambierà il suo modo di programmare. Se preferisce ancora usare il suo stile di codifica sui tuoi, non è probabile che cambi la sua opinione.

Promuovi l'uso di analisi statiche automatizzate e strumenti di controllo dello stile come linters e bug finder (in qualsiasi lingua tu usi). Se tutti i membri dell'azienda iniziano a utilizzarli (ad es. Sono incaricati prima del check-in), non vengono scelti.

La ragione per cui ti sto suggerendo è questa:

1) In genere le persone si comportano meglio per censurare dagli strumenti automatici rispetto ai loro colleghi o subordinati.

2) Questi strumenti coprono un sacco di problemi che possono essere considerati di cattivo gusto.

3) Potresti modificare le regole dietro le quinte per il suo cattivo stile al di là di ciò che è incorporato nello strumento. Ad esempio, applica un certo stile di variabile.

4) Alcune persone si rendono conto che il loro codice non è così buono e in realtà iniziano a prestare maggiore attenzione anche a cose non coperte dai linters.

Un bel po 'di aziende rispettate (come il mio stesso datore di lavoro) costringono a un controllo dei pelucchi prima del check-in. Il punto di vista è che il cattivo stile è il debito tecnico. Puoi sempre usare "Bene, se X e Y e Z lo fanno, probabilmente è una buona idea".

Penso che non dovresti dirgli assolutamente niente di simile . Tali affermazioni possono facilmente causare una reazione difensiva in lui, che quasi sicuramente ne bloccherà ogni possibilità di apprendimento, e potrebbe anche causare problemi per te.

Cerca invece (e anche cerca di creare) opportunità di discutere casualmente dei problemi di stile e idioma di codifica e menzionagli le "migliori pratiche" che conosci. Ovviamente, devi assicurarti innanzitutto che ciò che suggerisci sia in realtà una best practice ampiamente conosciuta e accettata.

Inoltre, prova a discutere gli stessi problemi anche con gli altri membri del team. È importante comprendere il "consenso" (espresso o non esplicito) all'interno del team in merito allo stile e alla qualità di codifica . (Se tutti scrivono codice pulito e di alta qualità, si ha un caso molto diverso rispetto a quando il resto del gruppo è composto da programmatori reali che scrivono con orgoglio i programmi FORTRAN in qualsiasi lingua.) Potrebbero anche raccontare meglio il background storico del progetto e lo stile di codifica del tuo capo, che ti aiuta a indirizzare meglio i tuoi sforzi.

Un altro modo è chiedergli di ordinare Java efficace per te, perché ritieni di averne bisogno diventare un programmatore migliore. (Nel caso in cui non l'hai ancora letto, in effetti ne hai bisogno.) Allora puoi parlargli delle soluzioni e delle pratiche meravigliose contenute in questo libro.

Se è aperto a migliorare se stesso, raccoglierà i tuoi suggerimenti (e il libro). Altrimenti, puoi ritirarti senza perdere la faccia e sforzando la tua relazione.

Se il tuo capo è simpatico, chiedigli semplicemente: "Amico, WTF?"

In tutti i casi in cui pensi che "il mio è meglio" non dire mai a qualcuno che pensi, mostralo.

Ripeto, SHOW, non dirlo.

Sai che parlare di azioni, più strong, parole ... è vero.

Esattamente quale posizione ha il tuo capo? È uno sviluppatore, leader tecnologico? Quanti altri sviluppatori ci sono in azienda? L'azienda ha standard di codifica e recensioni di codici?

È improbabile che il tuo capo cambi le sue cattive abitudini (IMHO) ma potresti essere in grado di utilizzare un gruppo di pari o gli standard aziendali per influenzarlo. Se il suo codice fa segue gli standard ei peer sono tutti uguali, le tue opzioni sono limitate.

Ecco la mia raccomandazione:

• indica bene il tuo caso.
• Se il tuo manager non è ricettivo * al tuo punto di vista, e senti che hai ragione, cerca pascoli più verdi e non fare scuse.

Ti consiglio di cercare pascoli più verdi per tre motivi:

1. A lungo termine, è dannoso per la carriera di un programmatore perpetuare le cattive pratiche. Il perpetuarsi delle cattive pratiche genera cattive abitudini.
2. Un negozio di programmazione che non è ricettivo ai punti di vista alternativi soffoca l'immaginazione.
3. Quando sai che stai perpetuando le cattive abitudini e la tua squadra non è ricettiva ai punti di vista alternativi, il tuo morale è destinato a sprofondare, e questo renderà la tua vita miserabile. Quindi, lascia il PIÙ PRESTO.

* Distinzione importante: aspettarsi che qualcuno sia ricettivo al tuo punto di vista non è come aspettarsi che qualcuno ceda al tuo punto di vista. Apprezzo sempre le persone che considerano il mio punto di vista, mentre ho scarso rispetto per le persone che sono teneri e cedono al mio punto di vista senza sufficienti ragioni o prove per farlo.

Le azioni parlano più delle parole:

Un approccio diverso:

• Devi condurre con l'esempio.
• Assicurati che i progetti che fai siano i migliori che puoi fare.
• Devi eccellere in termini di prestazioni, meno errori, ecc.
• Una volta che puoi dimostrare che il tuo approccio e il tuo stile sono migliori del tuo capo, a meno che non sia molto arrogante, penso che naturalmente quella persona seguirà ciò che funziona meglio.

Gli darei puntatori a piccole dosi, quando lo vedi fare qualcosa di "cattivo"

"Hmm, dai un'occhiata a questo approccio per quello {Indicando sul suo schermo}, mi piace farlo in questo modo a causa di bla bla bla."

Fai questo più di una volta ogni altro giorno. Non accetta il tuo suggerimento, non lo menzionerà mai più (per alcune settimane). Alcuni si attaccheranno. E lentamente migliorerà.

Chiedi al tuo capo di confrontarsi con un altro modo in cui ti è stato insegnato. Potrebbe avere una ragione legittima. Non lo saprai finché non lo chiedi. Potrebbe esserci qualche vecchio standard di codifica che sta cercando di mantenere o potrebbe non interessarsene. Non dare alcuna indicazione pensi che il capo sia automaticamente sbagliato. Oh, e fallo in privato. Questo è per i tuoi scopi educativi.

Dipende. Se il codice che stai recensendo è un codice nuovo di zecca, chiedi di avere recensioni sul codice in quanto ti aiuterà a "portarti a tutta velocità" e mostrerà che sei interessato all'apprendimento. Il capo potrebbe trovarlo utile in quanto gli dimostrerà che stai cercando di fare la cosa giusta. Se questo è il vecchio codice che ti è capitato di incappare e sei costretto a mantenerlo, rendilo un punto per fare un lento refactoring. Una dichiarazione di tipo qua e là mentre si sta ancora completando l'operazione in corso. Ora il problema è che String YesOrNo può assumere altri valori come Maybe che può portare a codice non funzionante se non stai attento.

Prova a mostrargli brevi frammenti di codice di esempio da siti / luoghi / libri stimabili che realizzano cose simili.

La prima cosa che farei è scoprire come reagisce ai critici. Se io fossi il capo, beh, non farei niente di sbagliato, vero? - Preferirei che mi venisse detto in faccia, tutto in una volta, ma in modo rispettoso. A seconda del temperamento e della cultura, il tuo capo potrebbe essere diverso.

Ma la maggior parte di loro ha bisogno di rispetto. Un buon modo per dimostrare che lo rispetti è ciò che è stato suggerito prima: spiega cosa intendi, ma lasciagli la decisione: "Questa è la mia ragione, ma forse ho supervisionato qualcosa. Dopo la mia spiegazione:"

if (YesOrNo == "Yes")
if (YesOrNo == "yes")
if (YesOrNo == "YES")
if (YesOrNo == "oui")
if (YesOrNo.equals ("Yes"))
if ("Yes".equals (YesOrNo)) // might be null

"cosa tu suggerisci?"

E potresti chiedere a una metaquestion prima: "Signor X, se ho trovato qualcosa nel tuo codice, che è comunemente riportato come una pratica migliorabile - come dovrei segnalartelo? Tutto in una volta o passo dopo passo? O dovrei evitare di menzionarlo a tutti i costi? Migliorare silenziosamente il codice? "

Dipenderà dalla mia relazione quale formulazione sceglierei e quale approccio.

Il tuo capo non sa come programmare e non dovrebbe farlo. La mia esperienza mi ha detto che supponendo che qualcuno chiamato boss sia anche più esperto o migliore di te è un errore. Potrebbe essere migliore in altre cose, ma il punto di gestione e la gerarchia è di delegare le cose alla persona più appropriata. Un capo è qualcuno che ha avuto la possibilità di avviare un'impresa, o alla fine è entrato in una posizione dirigenziale per le sue capacità manageriali, non necessariamente per le sue capacità di programmazione.

Una volta avevo un capo che fingeva di aver installato un computer mentre ero collegato a un generatore elettrico a benzina, perché sosteneva che gli hacker potevano entrare attraverso la rete elettrica mentre la macchina non era ancora protetta. Ho lasciato immediatamente. Ho imparato una lezione importante allora: il capo non ha sempre ragione, ea volte smettere di fumare è l'unica risposta valida.

Quindi, per tornare al tuo caso, potresti avere un caso in cui solo cercare un altro impiego (sì, crisi, yadda yadda ... lo so) potrebbe essere la cura migliore. Non perdere tempo prezioso.

Vivo nel settore in cui non riesco a trovare gli errori del mio capo. Quindi, meglio, vorrei generare i casi in cui gli errori compaiono nel codice e fargli vedere l'errore, quindi gli suggerirò le modifiche richieste e il possibile motivo [nel tuo caso sei sicuro del motivo ..: - D] dell'errore. Qualsiasi sviluppatore, sia buono o cattivo, non accetterà l'errore fino a quando non vedrà il bug.

Una volta ho avuto un grosso problema con lo stile di un boss.

Ci sono due problemi con questo. Prima di tutto, non credo di averlo mai detto in faccia, ma immagino che lo sapesse. È rimasto professionale, non l'ho fatto, IOW.

In secondo luogo, c'erano delle ragioni per quello che ha fatto, e mi ci è voluto solo un po 'di tempo per capire quanto fossero eccessivamente complicate le mie "soluzioni".

Dei tre punti della domanda, i segni diacritici non sono strani a tutti, e mentre non lo userei per il ciclo, mi irritano i C ... mentre la sintassi e come (non ) si adatta al mio stile di indentazione, quindi posso forse vedere da dove proviene.

Anche la cosa booleana potrebbe avere una spiegazione in termini di abitudini introdotte da un'altra lingua (il che non è una giustificazione, ovviamente).

Immagino che questo potrebbe funzionare -

1. Chiedi al tuo manager di rivedere il tuo codice che non presenta nessuno degli errori che fa.
2. Poi vedi se il tuo manager ti chiede perché non farlo "in modo"
3. Se ti fa questa domanda, potresti chiedergli perché sarebbe un modo migliore.

In questo modo capirai perché pensa che la sua strada sia corretta.

Sono stato lì prima. Ero appena uscito da Uni e dopo circa un anno di lavoro per un ragazzo, mi sono reso conto che sapevo molto più di lui sulla programmazione, ma era affar suo, e ha chiamato i colpi - e non volevo offenderlo Comunque! Ho deciso che il modo migliore per farlo era di discutere i vantaggi di avere convenzioni di codifica comuni in tutta la società che dovremmo anche tutti attaccare, e vedere come ha reagito. Sorprendentemente, ha pensato che fosse una grande idea e mi ha chiesto di stilare una lista di standard, che entrambi abbiamo poi rivisto insieme e finalizzato ecc.

La cosa importante qui è che sei solo un fallibile come lui e che solo perché alcuni dei suoi modi sono strani / sbagliati, alcuni di loro saranno migliori dei tuoi.

Dalla mia esperienza personale tuttavia non ha funzionato. Nonostante abbia passato 2 giorni a cercare e compilare un ottimo documento di standard e convenzioni di codifica - era già impostato nei suoi modi, non vedeva davvero il vantaggio nelle convenzioni di codifica o scriveva codice che metteva meno a dura prova il server, che rendeva i nostri lavori più veloce e più facile, e tagliare i costi.

Alla fine sono partito per trovare un posto che ha richiesto uno sviluppo un po 'più serio. Non è stato affatto male, poiché la ricerca che ho fatto sulle convenzioni di codifica è davvero di grande aiuto fino ad oggi.