it-swarm.it

Come dire al tuo capo che il suo stile di programmazione è davvero cattivo?

Sono uno studente e nel mio tempo libero lavoro per una grande impresa come Java. Il lavoro è buono, ma il problema è che il mio capo scrive un codice molto strano. non voglio lamentarmi, ma secondo me alcuni problemi sono davvero strani. Ad esempio:

  • non conosce booleani. Tutte le condizioni booleane sono stringhe chiamate "YesOrNo" e quindi nella condizione che utilizza if (YesOrNo == "Yes")

  • ci sono molti caratteri molto strani nei nomi dei metodi e variabili come é õ ô o è

  • tutti i loop sono loop infiniti nello stile di for (;;). Quindi alla fine del ciclo la condizione viene testata e se le condizioni soddisfatte si rompono; è chiamato.

Non so se dovrei dirgli che penso che questa non sia una buona pratica, dal momento che è il mio capo e decide come e cosa fare. D'altra parte alcuni dei suoi esempi sono davvero molto strani.

Qualche suggerimento su come affrontarlo? E sono solo io a pensare che sia un cattivo stile?

63

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 questo modo (migliori pratiche, migliori prestazioni, minori possibilità di errori, più facile da leggere/mantenere per altri programmatori, ecc.).

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

Se è aperto al miglioramento, probabilmente cambierà il suo modo di scrivere codice. Se preferisce ancora usare il suo stile di codifica sul tuo, non è probabile che cambi opinione.

78
Rachel

Promuovere l'uso di analisi statiche automatizzate e strumenti di controllo dello stile come linter e finder di bug (in qualunque lingua tu usi). Se tutti gli utenti dell'azienda iniziano a usarli (ad esempio, sono obbligati prima del check-in), non viene individuato.

Il motivo per cui sto suggerendo questo è che:

1) Le persone generalmente impiegano meglio a censurare dagli strumenti automatizzati rispetto ai loro colleghi o subordinati.

2) Questi strumenti coprono molti problemi che possono essere considerati stile scadente.

3) Potresti forse modificare le regole dietro le quinte per il suo cattivo stile al di là di ciò che è incorporato nello strumento. Ad esempio, applicare un determinato 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 su cose non coperte dalle linter.

Un certo numero di aziende rispettate (come il mio datore di lavoro) impone un controllo dei filacci prima del check-in. L'opinione è che il cattivo stile sia un debito tecnico. Puoi sempre usare "Beh, se X e Y e Z lo stanno facendo, probabilmente è una buona idea".

39
Uri

Penso che non dovresti assolutamente dirgli niente del genere . Tali affermazioni possono facilmente causare una reazione difensiva in lui, che quasi sicuramente chiuderà ogni possibilità per lui di imparare e potrebbe persino causare problemi per te.

Invece, cerca (e persino prova a creare) opportunità di discutere casualmente discutere lo stile di codifica e le problematiche del linguaggio e menzionalo come "best practice" di cui sei a conoscenza. Naturalmente, devi prima assicurarti che ciò che suggerisci sia davvero una best practice ampiamente conosciuta e accettata.

Inoltre, prova a discutere gli stessi problemi anche con altri membri del team. È importante comprendere il "consenso" (parlato o non espresso) all'interno del team per quanto riguarda lo stile e la qualità dei codici . (Se tutti gli altri scrivono un codice pulito e di alta qualità, hai un caso molto diverso rispetto a se il resto del gruppo è composto da programmatori reali che scrivono con orgoglio programmi FORTRAN in qualsiasi lingua.) Potrebbero anche raccontare di più sullo sfondo storico del progetto e lo stile di programmazione del tuo capo, che ti aiuta a orientare meglio i tuoi sforzi.

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

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

24
Péter Török

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

21
gruszczy

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

Ripeto, SPETTACOLO, non dirlo.

Sai che dire delle azioni, più forte, delle parole ... è vero.

8
Jack Marchetti

Esattamente quale posizione ricopre il tuo capo? È uno sviluppatore, responsabile della tecnologia? Quanti altri sviluppatori ci sono in azienda? L'azienda ha standard di codifica e revisioni del codice?

È 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 e i peer sono tutti uguali, allora le tue opzioni sono limitate.

6
Qwerky

Ecco la mia raccomandazione:

  • Dichiara bene il tuo caso.
  • Se il tuo manager non è ricettivo * dal tuo punto di vista e ritieni di avere ragione, cerca pascoli più verdi e non trovare scuse.

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

  1. A lungo termine, è dannoso per la carriera di un programmatore perpetuare cattive pratiche. La perpetuazione di cattive pratiche genera cattive abitudini.
  2. Un negozio di programmazione che non è ricettivo a punti di vista alternativi soffoca l'immaginazione.
  3. Quando sai che stai perpetuando cattive pratiche e la tua squadra non è ricettiva a punti di vista alternativi, il tuo morale è destinato ad affondare e questo renderà la tua vita miserabile. Quindi lascia al più presto.

* Distinzione importante: aspettarsi che qualcuno sia ricettivo nei confronti del proprio punto di vista non equivale a aspettarsi che qualcuno realizzi rendimento nei confronti del punto di vista. Apprezzo sempre le persone che considerano il mio punto di vista, mentre ho poco rispetto per le persone che sono morbide e cedono al mio punto di vista senza motivo sufficiente o prove per farlo.

6
Jim G.

Le azioni parlano più forte delle parole:

Un approccio diverso:

  • È necessario lead con l'esempio.
  • Assicurati che i progetti che fai siano i migliori che puoi fare.
  • È necessario Excel in termini di prestazioni, meno bug, 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à tutto ciò che funziona meglio.
6
Darknight

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

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

Fallo non più di una volta ogni due giorni. Se non accetta il tuo suggerimento, non menzionarlo mai più (per alcune settimane). Alcuni si attaccheranno. E lentamente migliorerà.

4
Morons

Chiedi al tuo capo di confrontarlo con un altro modo in cui ti è stato insegnato. Potrebbe avere una ragione legittima. Non lo saprai fino a quando non lo chiedi. Potrebbero esserci dei vecchi standard di codifica che sta cercando di mantenere o semplicemente non le importa. Non dare alcuna indicazione che pensi che il boss abbia automaticamente torto. Oh, e fallo privatamente. Questo è per i tuoi scopi educativi.

4
JeffO

Dipende. Se il codice che stai recensendo è un codice nuovo di zecca, chiedi di avere recensioni di codici in quanto ti aiuteranno a "aggiornarti" e mostreranno 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 incontrare e sei costretto a mantenerlo, fai in modo di eseguire il refactoring lento. Una dichiarazione di tipo qua e là mentre si sta ancora completando l'attività da svolgere. Ora il problema qui è che la stringa YesOrNo potrebbe assumere altri valori come Maybe che può portare a codice errato se non stai attento.

4
Woot4Moo

La prima cosa che vorrei fare è scoprire come reagisce alla critica. Se fossi il capo, beh, non farei niente di male, vero? - Preferirei essere detto proprio 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 è quello che è stato suggerito prima: gli spieghi cosa intendi, ma lasci la decisione a lui: "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 suggerisci t suggerire?"

E potresti chiedere una metaquestione prima: "Mr. X, se ho trovato qualcosa nel tuo codice, che è comunemente segnalato 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? "

Dipenderebbe dalla mia relazione quale formulazione sceglierei e quale approccio.

4
user unknown

Il tuo capo non sa come programmare e non dovrebbe farlo. La mia esperienza mi ha detto che supporre che qualcuno chiamato capo sia anche più esperto o migliore di te è un errore. Potrebbe essere migliore in altre cose, ma il punto di gestione e gerarchia è delegare le cose alla persona più appropriata. Un capo è qualcuno che ha avuto la possibilità di avviare un'attività commerciale o alla fine è entrato in una posizione manageriale 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 era collegato a un generatore elettrico a benzina, perché sosteneva che gli hacker potevano entrare attraverso la rete elettrica mentre la macchina era ancora non protetta. Ho lasciato immediatamente. Allora ho imparato una lezione preziosa: il capo non ha sempre ragione, e talvolta smettere è l'unica risposta preziosa.

Quindi, per tornare al tuo caso, potresti avere un caso in cui solo la ricerca di un altro lavoro (sì, crisi, yadda yadda ... lo so) può essere la cura migliore. Non perdere tempo prezioso.

4
Stefano Borini

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

4
chiurox

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

3
Chris

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

Ci sono due problemi con questo. Prima di tutto, non credo di averlo mai detto in faccia, ma immagino che lo sapesse. Rimase professionale, io no, IOW.

In secondo luogo, c'erano delle ragioni per quello che ha fatto, e mi ci è voluto solo del tempo per capire quanto fossero complesse e brutte le mie "soluzioni" così giuste.

Dei tre punti della domanda, i segni diacritici non sono strani per tutti, e mentre non lo userei per loop, mi irrita la famiglia C ... mentre la sintassi e come (non) si adatta il mio stile di rientro, quindi posso forse vedere da dove viene.

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

3
Steve314

Immagino che potrebbe funzionare -

  1. Chiedi al tuo manager di rivedere il tuo codice che non presenta alcun errore.
  2. Quindi vedi se il tuo manager ti chiede perché non farlo "a modo suo"
  3. Se fa questa domanda, potresti chiedergli perché sarebbe un modo migliore.

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

3
k25

Ci sono stato prima. Ero uscito da Uni e dopo circa un anno di lavoro per un ragazzo, mi sono reso conto che conoscevo molto più di lui sulla programmazione, ma erano affari suoi, e ha chiamato i colpi - e non volevo offenderlo Comunque! Ho deciso che il modo migliore per aggirare il problema era discutere i vantaggi di avere convenzioni di codifica comuni in tutta l'azienda che anche tutti noi dovremmo seguire e vedere come ha reagito. Sorprendentemente, ha pensato che fosse un'ottima idea, e mi ha chiesto di redigere un elenco di standard, che entrambi abbiamo poi rivisto insieme, 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 saranno migliori dei tuoi.

Dalla mia esperienza personale, tuttavia, non ha funzionato. Nonostante abbia trascorso 2 giorni alla ricerca e alla compilazione di un ottimo documento di standard e convenzioni di codifica - era già impostato a modo suo, non vedeva davvero i vantaggi delle convenzioni di codifica o scriveva codice che metteva meno stress sul server, che ha reso i nostri lavori più veloce e più facile, e tagliare i costi.

Alla fine sono partito per trovare un posto che ha preso lo sviluppo un po 'più serio. Non è stato affatto male, dato che la ricerca che ho fatto sulle convenzioni di programmazione aiuta davvero fino ad oggi.

3
user16731