Disaccordo con il capo del progetto sugli standard di codifica [chiuso]

Quindi sto lavorando a un nuovo progetto insieme al mio responsabile del progetto nell'ultimo anno.

Inizialmente avevamo i nostri sottoprogetti che risiedevano in repository git separati, avevo poca interazione con il suo codice, quindi l'odore del codice non mi dava fastidio. Circa 6 mesi dopo ho iniziato a mantenere e aggiungere funzionalità al suo codice, mentre stavo assumendo un ruolo più importante nel progetto.

Ora che sono lo sviluppatore principale di entrambi i sottoprogetti (il team sta per crescere; è ancora sopra di me), queste cose mi infastidiscono e volevo prendermi cura di loro, ma mi è stato rifiutato:

1. Nessuna parentesi graffa, funzioni maiuscole, utilizzo di virgolette miste (doppia e singola con logica nascosta), non utilizzo ===, classi enormi con funzioni enormi. In conclusione, potrebbe essere migliore.
2. Affidamento all'opzione di PHP per disattivare avvisi / avvisi. Il codice è pieno di usi non controllati di variabili e chiavi dell'array. Le variabili vengono definite all'interno di ifs.

Argomenti di cui sopra 2 problemi:

1. Non voler applicare uno stile di codifica alle persone.
2. Considerata una funzionalità linguistica, che si presta a un codice più breve / più efficiente.

Credo che alcune regole debbano essere rispettate e il codice dovrebbe essere difensivo. Mi sono offerto di usare le impostazioni predefinite di PHPStorm per la formattazione, usare parentesi graffe e una convenzione di denominazione accettata dalla comunità.

Voglio allineare entrambi i progetti per utilizzare le stesse linee guida, in quanto inseparabili.

Ho sbagliato? Impongo le mie preferenze personali?

Se riesci a fare un valido motivo per capire perché il tuo è migliore (e quali sono i maggiori problemi che potrebbero derivare dall'utilizzare il suo), penso che tu non stia imponendo preferenze personali, ma piuttosto cercando di creare un progetto per il successo.

Se riesce a capire meglio perché il suo è migliore e che tipo di problemi impedirà al tuo di farlo, allora ti farà vincere.

Il management superiore decente dovrebbe essere in grado di vedere il merito in questo, ma questi sono i punti di cui (e dovrebbero) preoccuparsi: non se sia più facile per gli sviluppatori o "non voler costringere tutti a lavorare come un robot" (che è un punto ridicolo, ma non usarlo come punto dolente per il management superiore). Dovrebbero (dovrebbero) preoccuparsi della stabilità in corso del progetto.

Per il mio commento sopra:

Se è il capo del progetto, ciò sembra implicare che è sostanzialmente il suo appello.

Questo era il mio pensiero. Se vuoi cambiare lo standard ma non si sta muovendo su di esso, o a) capire come andare al di sopra di lui, b) andare da qualche altra parte per lavorare, o c) provare per quelle piccole cose che potresti essere in grado di fare senza irritarlo troppo.

Andare al di sopra di lui funzionerà solo se farai un valido motivo per cui dovrebbero esserci standard migliori.

Fondamentalmente:

• voi non fate come il suo stile di codifica. Questo è il tuo diritto
• lo trova OK così com'è e trova passare giorni / settimane / più semplicemente adattare lo stile è una perdita di tempo . Questo è il suo diritto.

Mettiti nei suoi panni. Quali sono i vantaggi del tuo impegno, oltre a costare all'azienda un sacco di soldi (il tuo stipendio)? È sempre così pignolo? Non vede che ci sono cose più importanti da fare in questo momento?

In sostanza, si deve trovare una sorta di compromesso si può vivere con, o il vostro rapporto diventerà acida. Dipende anche molto da come comunichi con lui. Metti da parte il tuo ego e cerca di essere d'aiuto ... perché alla fine gli stai chiedendo cose che vorresti, non qualcosa a cui lui ha interesse. In altre parole, gli stai chiedendo un favore .

Spesso dipende anche da come lo chiedi. Esempi:

Ciò che vuoi:

rendendo il codice più bello

Cosa non dire:

il tuo codice fa schifo così com'è

Cosa dire:

Lo apprezzerei molto se potessi rendere entrambi i progetti coerenti, solo le basi, e mi ci vorrà solo un giorno.

Ciò che vuoi:

non più avvisi non controllati

Cosa non dire:

il tuo codice fa schifo così com'è

Cosa dire:

Conosco un modo rapido per sbarazzarsi di questo e quell'avvertimento. Quindi, riattivandoli, potremmo rilevare più rapidamente se qualcosa potrebbe essere rotto in futuro.

E infine:

So che non è una priorità. Quindi posso farlo volentieri una volta che le cose ad alta priorità sono prima fuori dal tavolo.

Oppure, se ciò non funziona o se hai una brutta relazione con lui, considera di andartene. Se non riesci a risolvere le cose ora, è improbabile che migliori in futuro ... e metta da parte il tuo ego.

Nota a margine

Penso che sia più comune che le persone anziane siano più indulgenti. Sanno che il codice verrà spazzato via tra un decennio o due (perché i cambiamenti tecnologici, anche le API, i team, i partner commerciali, i requisiti, le decisioni globali, qualunque cosa ...). Hanno meno ego e si concentrano sul farlo funzionare piuttosto che sull'essere perfetto. Anche se tendo alla perfezione me stesso, non posso biasimarli.

Questo sarà probabilmente controverso ma ...

Abbiamo parlato e abbiamo concordato di non essere d'accordo e di inoltrarlo alla direzione superiore

Mai. Mai. Fare. Questo. MAI. Ogni volta che lo fai, ci riporta indietro di un decennio. Ecco come andrà a finire:

• Senior manager 1: "Ci è stato chiesto di affrontare questo problema blah, blah, blah, qualcosa sugli standard di codifica e perdere tempo".

• Senior Manager 2: "E stanno chiedendo a noi di risolvere le loro guerre secchione tappeto erboso, perché?"

• Senior manager 3: "Perché sono bambini piagnucolosi che non sanno comunicare e non si preoccupano / capiscono qual è il valore dell'azienda? *"

• Senior manager 2: "Deve essere così. Chi è pronto per il golf?"

Poi arriva te e il tempo di revisione delle prestazioni del tuo capo:

"[senior manager per il tuo capo]: mi dispiace, ma c'è qualche preoccupazione che tu non sia in grado di gestire i tuoi rapporti diretti e che tu non stia seguendo le migliori pratiche (anche se non ho idea di cosa tu faccia se non digitare un jumbo mumbo che rende il software funzionante) "

"[senior manager per te]: mi dispiace ma c'è qualche preoccupazione che non ti relazioni bene con i tuoi coetanei e hai problemi a seguire le indicazioni del tuo supervisore immediato."

Ed è per questo che siamo per lo più sottopagati rispetto al valore che creiamo. **

Devi o A) superarlo o B) passare a un negozio che ha le norme un po 'più vicine ai tuoi gusti. FWIW, farei B (e spero di passare a una lingua che non consenta tali atrocità). Ma mai inoltrare mai una controversia tecnica alle cause, a meno che non implichi qualcosa di illegale o potenzialmente catastrofico (gap di sicurezza spalancata). Semplicemente fastidioso non lo taglia ***.

* Per il bene di chi leggerà questo e fraintenderà, non sto dicendo che l'OP e il suo capo siano così (mi rendo conto che la qualità / leggibilità del codice ha un impatto diretto sui profitti dell'azienda), sto dicendo che saranno percepiti in questo modo dalla direzione non tecnica.

** Per le persone che ritengono che il mio ritratto dell'alta dirigenza come incapace di comprendere non sia realistico, capire che i gestori si preoccupano (idealmente) di gestire le persone nel modo in cui ci occupiamo della gestione del codice. Potrebbero essere all'oscuro di questioni tecniche, ma conoscono le persone, e questo è il motivo in più che portare loro una disputa che A) probabilmente non sono qualificati per risolvere e B) che probabilmente due di voi avrebbero dovuto essere in grado di risolvere senza aiuto ti fa sembrare cattivo.

*** Sì, mi rendo conto che il debito tecnico può accumularsi fino al punto di affondare il business. Semplicemente non penso che le parentesi graffe ti salveranno (detto questo, non ho mai omesso le parentesi graffe e preferisco fortemente che anche gli altri non lo facciano).

IMHO, stai affrontando uno sviluppatore "funzionante", non uno che si occuperà del prossimo inseguimento. Le sue argomentazioni sono semplicemente inutili.

Tutto ciò che dici sul suo codice è solo pigrizia da parte sua. Avere progetti seguendo lo stesso standard di codifica riguarda il rigore. Non sei robot; siete ingegneri; dovresti essere rigoroso.

Potresti sottolineare con alcuni esempi che stai avendo difficoltà a leggere il suo codice, e questa è una perdita enorme di produttività per te, ma non ho idea reale di come portarglielo.

Ma probabilmente ti risponderò qualcosa è il tono:

Funziona, non ha senso cambiare

Il mio consiglio: se è davvero schietto e non vuole dirigere nulla, lascialo andare. Attendi che si verifichino errori / bug / evoluzione nel suo progetto. Quando arriva, basta correggere e riscrivere la parte di codice modificata / aggiunta in modo corretto; non andare da lui per dire nulla al riguardo. Non ti imporrà il suo stile di programmazione, dato che non sei comunque un robot ...

Quando lavori su un progetto, devi stabilire delle priorità.

La priorità n. 1 è quella di andare d'accordo con i tuoi colleghi. La priorità n. 1 è seguita da un enorme divario. Poi arrivano priorità per cose come il codice che funziona, testabile, testato, documentato, mantenibile ecc. Poi arriva un altro enorme divario, e poi arrivano gli standard di codifica.

E cambiare il codice esistente per renderlo conforme ai nuovi standard di codifica è davvero basso nell'elenco delle priorità.

PS. "Micro-ottimizzazione" vs "computer superveloci": argomento totalmente sbagliato. L'argomento contro la micro-ottimizzazione non è che i computer sono veloci, l'argomento è che il tempo sprecato in micro-ottimizzazioni significa che non hai tempo a cercare risparmi reali .

PS. Se ti serve solo un giorno per apportare modifiche che migliorano l'aspetto del codice, ma sconvolgono il tuo collega e ti rendono nemico, un giorno hai sprecato qualcosa che è controproducente.

PHP non è il gruppo più elitario della nostra professione. In realtà stai criticando il suo sistema software probabilmente duramente vinto. Il tuo standard professionale è superiore al suo.

Quindi se non hai margine di manovra per migliorare il codice sotto le tue responsabilità, l'ultima soluzione è una sola: andare avanti .

Non conosco l'attuale mercato PHP al tuo posto, ma potresti prima diversificare un po '. Impara anche un po 'di linguaggio hype o una nicchia come C #.

Potresti non ottenere un lavoro così bello, ma verrai oltre, professionalmente. Quindi abbi pazienza e studia da solo. Soldi sicuri. Quindi chiedi un po 'di margine di manovra nei tuoi progetti o accetta un'offerta di lavoro.

Trovo difficile credere che il numero 1 sia la sua vera ragione per non voler cambiare gli standard di codifica. Se possiedi la base di codice, dovresti essere in grado di applicare qualunque standard di codifica che tu (e gli altri sviluppatori) accettiate. Se raggiungi il consenso con gli altri sviluppatori (supponendo che il lead non stia più facendo alcun lavoro di sviluppo), non c'è motivo per cui si preoccupi davvero, tranne questo:

La correzione dello stile della base di codice è il miglior uso del tuo tempo in questo momento?

Sono sicuro che hai dei risultati. Quanto tempo ci vorrà per passare e migliorare lo stile ovunque nell'altra base di codice? Cosa succede se si introducono bug correggendo lo stile in modo errato? Dallo zio Bob:

Naturalmente il codice errato può essere ripulito. Ma è molto costoso. Man mano che il codice marcisce, i moduli si insinuano l'uno nell'altro, creando molte dipendenze nascoste e intricate. Trovare e rompere le vecchie dipendenze è un compito lungo e arduo.

Migliorare lo stile di codice come questo non è quasi mai un buon uso del tempo come elemento di sprint autonomo . Il modo in cui mi piace apportare questo tipo di miglioramenti è ciò che chiamo la "Politica del buon vicinato": non andare in giro a riparare tutto lo stile e la struttura logica che puoi trovare, perché probabilmente investi tutto il tempo che vuoi e continuerai non essere fatto. Anziché: ogni volta che stai apportando una modifica a una parte del codice, correggi lo stile mentre sei lì e lascialo migliore di quello che hai trovato. Se stai lottando per implementare una funzione perché il codice è progettato male, correggi lo stile per sbloccarti piuttosto che battere la testa contro di esso.

In questo modo, ogni modifica:

1. Ha una motivazione aziendale oltre alla motivazione del perfezionismo tecnico
2. Non sarà visto come un grande investimento nel tempo (perché non lo è!)
3. Stabilirà buone abitudini stilistiche proprio perché tu e il tuo team lo state facendo nel tempo
4. Non presenterà un grosso rischio per la base di codice perché non stai cambiando troppo in una volta

Tra qualche mese guarderai in alto e noterai che il "pacchetto terribile" non è più così male e il tuo capo vedrà che la sua squadra è più felice. Ma poiché non è stato un confronto diretto, lo sarà già e non avrà nulla di cui lamentarsi perché non hai perso tempo (nella sua mente) aggiungendo un grande progetto di refactoring all'elenco delle cose da fare. Probabilmente non ti dirà mai che avevi ragione, ma che comunque non è l'obiettivo (giusto?).

Poni queste domande sul tuo vantaggio.

• Sono abituati a lavorare da soli o con una squadra molto piccola?
• Hanno principalmente codificato in questo negozio?
• Sono abituati a prendere le decisioni?
• Sono abituati a "solo farlo"?
• Hanno scritto la maggior parte del codice?

Se le risposte sono "sì", allora dipingerò un'immagine di un particolare tipo di programmatore principale. Se corrisponde a quello che hai vissuto, forse ti aiuterà a metterti in testa. In caso contrario, ignora questa risposta .

Questo è qualcuno che è stato lì fin dal primo giorno, ha trascorso anni nello stesso lavoro lavorando sulla stessa base di codice, è abituato ad avere la propria strada e non ha molta esperienza con altri modi.

Non considerano le altre persone quando scrivono codice poiché tutto ha un senso per loro. Certo che lo fa, l'hanno scritto o hanno passato anni a capirlo.

Considerano lo stile di codifica come una preferenza personale, non uno strumento per ridurre la manutenzione e i bug. Quando discutono dello stile di programmazione, faranno fatica ad ascoltare i tuoi argomenti perché probabilmente non hanno mai pensato molto al perché fanno le cose a modo loro. Quello che sentiranno è "Voglio farlo a modo mio" o "Voglio farlo nel modo nuovo, elegante e alla moda".

Sono disposti a modo loro. Perché lo hanno fatto allo stesso modo per così tanto tempo tutti i loro strumenti, editor e cervello micro-configurati esattamente nel loro stile. Qualsiasi deviazione da questo stile entrerà in conflitto con questo modo di lavorare attentamente organizzato, ma molto fragile. I tentativi di cambiamento porteranno lamentele sul loro editore, sugli strumenti, sul modo in cui a loro piace lavorare o sul fatto che siano "difficili da leggere". Rifiutano il cambiamento perché si sono impacchettati così tanto nello status quo che non possono cambiare.

Questo è qualcuno che non ha mai appreso correttamente l'ingegneria del software e l'architettura del software. In un certo senso fanno il botto insieme qualunque cosa funzioni.

Hai un problema di persone, non tecnologico.

Dovrai riqualificare il tuo vantaggio o dovrai smettere.

Andare alla gestione è l'ultima risorsa . Sia per i motivi indicati da @JaredSmith sia perché perderai. Questo ragazzo ha passato anni a fare soldi per loro. Ha scritto la loro compagnia. Si è spento in numerosi incendi. Per te è uno chef da cowboy che fa gli spaghetti. Per loro è un eroe che ha costruito e salvato la compagnia.

Per riqualificarti dovrai ...

• Guadagna la sua fiducia.
• Scopri come pensa.
• Affronta le sue paure riguardo al cambiamento.
• Rendi il cambiamento più semplice.
• Mostra come questo è meglio per lui .

Prendi sul serio il suo stile ed entra nella sua testa. Chiediglielo. Perché fa le cose come fa? Cosa vede quando lo legge? Come interagisce con i suoi strumenti? Come si muove attraverso il codice? Conoscere tutte queste cose ti permetterà di comprendere e affrontare le sue obiezioni.

Trova la radice obiettiva delle sue obiezioni soggettive, rendile fruibili. "È difficile da leggere" è soggettivo e non fornisce informazioni. Non puoi farci niente. "Sono daltonico e l'evidenziazione della sintassi non funziona" è oggettivo, ti dà informazioni e puoi fare qualcosa al riguardo. Consiglierei un libro intitolato Come arrivare a Sì per saperne di più.

Una volta che hai riscontrato il problema alla radice, il vero problema che sta riscontrando, vedi se riesci a risolverlo o mitigarlo. Quindi non è un problema. Probabilmente avranno ancora problemi emotivi con il cambiamento, ma almeno non possono più sostenere che si tratti di un problema reale.

Fallo un po 'alla volta. Questa è una persona che lo fa da anni. È abituato a vedere determinati schemi nel codice e ad usarli per capirlo. Cambiare improvvisamente tutti questi schemi sarà confuso. Per quanto frustrante possa essere quello di portarli lentamente al passo con le buone pratiche conosciute, devi affrontarlo.

Sostenere uno stile di comunità standard. Questo elimina l'argomentazione che riguarda le preferenze personali e mette la pressione su di loro per giustificare perché il loro diverso stile è molto meglio. Se prevedi di assumere, semplifica l'integrazione di nuovi assunti.

Sostenere lo stile di codice automatizzato. Rendi seguendo lo stile corretto una pressione di un pulsante. Usa uno strumento che inizia con uno stile standard, che ti consente di configurarlo secondo i tuoi gusti e che può ridisegnare il codice con la semplice pressione di un pulsante. Rendere il più semplice possibile seguire lo stile rimuove molti argomenti su quanto sarà difficile da seguire. Possono codificare come preferiscono e quando hanno finito premono un pulsante e segue uno stile che altri possono leggere.

Dal momento che questa persona non è nella mentalità di pensare agli altri, dovrai mostrare come questi cambiamenti li giovano. Può essere semplice come "dato che questo è lo standard ora, non dovrai più affrontare questa lotta con la prossima persona che assumi". Oppure può essere "se abbiamo dei test puoi essere più aggressivo nel cambiare il codice e preoccuparti di meno nel cambiare le cose". Oppure "se ci sono buoni documenti, le persone non dovranno continuare a disturbarti con domande su come funziona il codice". Perché questo sia efficace, devi sapere cosa vogliono: ad alcune persone piace essere disturbate, le fa sentire importanti.

È una strada lunga, lunga. Dovrai decidere se hai la pazienza di gestire e riqualificare il tuo capo. Pensa a te stesso più come al loro insegnante che al suo frustrato sentimento, e potresti sentirti meglio.

Ho sbagliato?

Non conosco PHP, quindi non posso esprimere un giudizio diretto, ma suppongo per amor di discussione che il tuo stile di codifica preferito sia "migliore" del codice che hai incontrato, poiché il tuo è più in linea con strumenti automatizzati esistenti.

Quindi non hai torto a suggerire miglioramenti allo stile di codifica.

In conclusione, non con il codice con cui voglio lavorare

Potresti avere torto a rifiutare di lavorare con un codice che non soddisfa i tuoi standard preferiti, ma solo nella misura in cui lavorando per l'azienda hai accettato di lavorare con il loro codice in primo luogo. Alla fine non è "sbagliato" lasciare il tuo lavoro se ti richiede di non essere di tuo gradimento, dato che è tuo diritto, e potresti trovare un lavoro migliore come risultato.

Impongo le mie preferenze personali?

No. È il capo del progetto e tu no. È la sua chiamata, anche se in questo caso è "delegato verso l'alto".

Potrebbe anche aver deciso di delegare verso il basso a te, come sviluppatore principale dei sottoprogetti, e darti la mano libera per fissare gli standard di codifica per quei sottoprogetti e colleghi che lavoreranno su di essi in futuro. Ma per qualsiasi motivo si sente abbastanza fortemente che non dovresti standardizzare. Anche se ha torto sullo stile di programmazione non puoi aspettarti di rivendicare un'autorità che non ti ha concesso.

Tuttavia, poiché dice "Non mi piace applicare gli stili di codifica", puoi almeno scrivere un nuovo codice nel tuo stile preferito (e l'hai fatto). In definitiva, ciò potrebbe comportare opportunità per dimostrare i vantaggi oggettivi del tuo stile. Sarebbe un buon momento per riprovare.

Puoi anche (penso) ragionevolmente chiedere alle persone che modificano i file, di farlo nello stile in cui il file è già scritto. Ciò ti consente di mantenere gli standard nei file che hai scritto. Sfortunatamente il rovescio della medaglia è che dovresti modificare i file che ha scritto in qualcosa di simile al suo stile.

Anche supponendo che si disponga di una suite di test davvero buona e che quindi si possa fare il refactoring in relativa sicurezza, ci sono ancora (certamente certi margini) motivi per non passare in rassegna e ridisegnare interi file. Il principale è che è un incubo che cerca di unire, riordinare o ripristinare le modifiche apportate prima e dopo un grande cambiamento strutturale. Ma può darsi che in questo particolare progetto non accada quasi mai.

[Il mio manager dice che non gli piace] imporre stili di codifica alle persone [perché] non siamo robot.

Ti sei mai chiesto perché non buttiamo via il codice sorgente dopo averlo compilato e ha superato tutti i test? Il codice sorgente è per gli umani e non è solo per gli umani scrivere, ma anche per leggere .

Prima o poi qualcuno avrà un motivo per tornare indietro e leggere il codice. Forse dovranno cambiarlo, forse per documentarlo, forse per riutilizzarlo. Qualunque cosa. Succederà e il codice sarà molto più facile da leggere e con cui lavorare se è tutto in uno stile coerente.

Anche uno stile cattivo è meglio di nessuno stile.