Standard di codifica Python vs. produttività

Lavoro per una grande organizzazione umanitaria, su un progetto di software che potrebbe aiutare a salvare vite umane nelle emergenze accelerando la distribuzione di cibo. Molte ONG hanno un disperato bisogno del nostro software e siamo in ritardo di settimane.

Una cosa che mi preoccupa in questo progetto è ciò che penso sia un'eccessiva attenzione agli standard di codifica. Scriviamo in python / django e utilizziamo una versione di PEP0008, con varie modifiche, ad esempio la lunghezza delle righe può arrivare a 160 caratteri e tutte le righe dovrebbero andare così a lungo se possibile, senza righe vuote tra le importazioni, regole di avvolgimento delle righe che si applicano solo a determinati tipi di classi, molti modelli che dobbiamo usare, anche se non sono il modo migliore per risolvere un problema ecc. ecc.

Uno sviluppatore di base ha trascorso una settimana riscrivendo una parte importante del sistema per soddisfare gli allora nuovi standard di codifica, eliminando diverse suite di test nel processo, poiché la riscrittura significava che erano "non validi". Abbiamo trascorso due settimane a riscrivere tutte le funzionalità perse e a correggere i bug. È lo sviluppatore principale e la sua parola ha un peso, quindi ha convinto il project manager che questi standard sono necessari. Gli sviluppatori più giovani fanno come gli viene detto. Sento che il project manager ha un forte sentimento di dissonanza cognitiva su tutto ciò, ma è comunque d'accordo con esso con veemenza, poiché non è sicuro di cos'altro fare.

Oggi ho avuto seri problemi perché avevo dimenticato di mettere alcuni spazi dopo le virgole in un argomento di parole chiave. Sono stato letteralmente urlato da altri due sviluppatori e dal project manager durante una chiamata su Skype. Personalmente penso che gli standard di codifica siano importanti, ma penso anche che stiamo perdendo molto tempo a ossessionarli, e quando ho verbalizzato questo ha provocato rabbia. Sono visto come un piantagrane nella squadra, una squadra che è alla ricerca di capri espiatori per i suoi fallimenti. Dall'introduzione degli standard di codifica, la produttività del team è crollata in modo misurabile, tuttavia ciò non fa che rafforzare l'ossessione, ovvero lo sviluppatore principale semplicemente incolpa la nostra non aderenza agli standard per la mancanza di progressi. Crede che non possiamo leggere il codice reciproco se non aderiamo alle convenzioni.

Questo sta iniziando a diventare appiccicoso. Ora sto cercando di modificare vari script, autopep8, pep8ify e PythonTidy per cercare di abbinare le convenzioni. Eseguiamo anche pep8 contro il codice sorgente ma ci sono così tante modifiche implicite al nostro standard che è difficile seguirle tutte. Lo sviluppatore principale sceglie semplicemente i difetti che lo script pep8 non rileva e ci grida alla prossima riunione stand-up. Ogni settimana ci sono nuove aggiunte agli standard di codifica che ci obbligano a riscrivere il codice esistente, funzionante e testato. Grazie al cielo abbiamo ancora dei test (ho ripristinato alcuni commit e risolto un sacco di quelli che ha rimosso).

Nel frattempo c'è una crescente pressione per rispettare la scadenza.

Credo che un problema fondamentale sia che lo sviluppatore principale e un altro sviluppatore principale si rifiutino di fidarsi degli altri sviluppatori per fare il loro lavoro. Ma come affrontarlo? Non possiamo fare il nostro lavoro perché siamo troppo impegnati a riscrivere tutto.

Non ho mai incontrato questa dinamica in un team di ingegneri del software. Ho sbagliato a mettere in discussione la loro aderenza agli standard di codifica? Qualcun altro ha vissuto una situazione simile e come l'ha affrontata con successo? (Non sto cercando una discussione, ma solo soluzioni reali che la gente ha trovato)

Gli standard di codifica non sono il problema. Il problema è che il management non riesce a capire quale sia il problema. Questo porta a "Fai qualcosa ... qualsiasi cosa!" modalità. Stai cercando una soluzione razionale, ma è un problema irrazionale. Il meglio che puoi fare è:

• Esprimi critiche costruttive sulle loro idee, ma una volta presa la decisione non lamentarti continuamente.
• Fai tutto il possibile per semplificare le riscritture.
• Smetti di stressare. Le scadenze perse sono un problema di gestione, non tuo. Fai del tuo meglio, ma non assumerti la responsabilità delle loro decisioni sbagliate.
• Se conosci qualcosa che potrebbe aiutare, diglielo. La tua menzione di standup sembra che tu stia cercando di fare agile, ma il resto non sembra molto agiley. Vedi se riesci a fornire funzionalità limitate in anticipo invece di cercare di rispettare una grande scadenza con tutto. Crea user story per le riscritture in modo che sia chiaro come incidono sul backlog.
• Inizia a cercare un altro lavoro. Sul serio. Le aziende in tale stato non sono lontane dall'iniziare a licenziare le persone.
• Ottieni alcune magliette "detto così" :-)

Qualcuno deve decidere se la vera priorità è la spedizione o il rispetto rigoroso degli standard di codifica. So quale sarebbe la mia preferenza; se sta superando i test unitari e di collaudo, dico nave. Una volta spedito, l'azienda può decidere se spendere o meno il tempo e il denaro per riparare il debito tecnico.

I problemi con spazi dopo le virgole possono essere facilmente risolti con uno strumento di prettificazione del codice. Trova uno strumento che applica tutte le convenzioni di codifica ed esegui tale strumento su tutto il codice modificato prima che avvengano la compilazione e il test. Gli IDE decenti lo fanno già, mentre stai scrivendo il codice.

Ho sbagliato a mettere in discussione la loro aderenza agli standard di codifica?

Dipende dal gruppo. Personalmente , penso che tutto dovrebbe essere messo in discussione. Alcune persone considerano questo interrogativo un affronto; che non mi fido di loro.

Qualcun altro ha vissuto una situazione simile e come l'ha affrontata con successo?

Ho chiesto come questi standard migliorano la produttività. Ho misurato il tempo che ho passato a rovinare con gli standard rispetto a "fare cose". Alla fine, i poteri che si decidono di rispettare gli standard. Succede. Mi sono lamentato per il fatto che erano più rumorosi del solito quando sono stati la causa della mia mancanza di lavoro, ma per il resto mi sono concentrato sul lavoro svolto. Lottare continuamente sulle cose non fa bene alla produttività ...

Se, come dici tu, le cose sono notevolmente peggiori a causa degli standard, aderire agli standard dovrebbe invalidare l'argomento del lead e lasciare il tuo. Se le persone non riescono a vedere quella (in gran parte) oggettiva correlazione tra l'implementazione dello standard e il calo della produttività, allora non c'è molto altro da fare. Impara a gestirlo e, se non ci riesci, cerca un posto meno burocratico.

Gli standard sono qualcosa che non dovrebbe essere messo in atto a fine progetto con una scadenza incombente. È qualcosa che avrebbe dovuto essere messo in atto all'inizio del progetto o quando c'è tempo messo da parte nel programma del progetto (preferibilmente dopo la spedizione iniziale) per (potenzialmente) un grande refactor del codice offensivo.

Se questo è stato effettivamente inserito in ritardo nel progetto, allora è un errore fatto dal tuo capo (IMHO).

Tuttavia , ciò non significa che se non sei d'accordo con il tuo vantaggio, dovresti semplicemente caricare in anticipo con l'ammutinamento. Questo è il tuo lavoro . Lavori in gruppo . Hai un vantaggio . Dovrebbe esserci sicuramente un certo livello di democrazia nella squadra, ma alla fine il vantaggio è il dittatore. Se dice di fare qualcosa, lo fai.

Alla fine, nel soddisfare le sue richieste e i suoi standard, non gli fornirai un capro espiatorio facile per le scadenze mancanti.

Inoltre, sono un grande sostenitore degli standard di codifica (specialmente con l'aumentare delle dimensioni di una squadra), ma dovrebbero essere implementati quando ha senso.

La tua domanda era "Ho sbagliato a mettere in dubbio la loro aderenza agli standard di codifica?". http://c0x.coding-guidelines.com/Introduction.pdf (per il linguaggio di programmazione C) ha alcuni studi di riferimento sul valore delle linee guida di codifica. Vedere la sezione 9 a partire da pagina 39.

Gli standard di codifica sono implementati per un motivo. Una cosa che sembra mancare alla domanda originale è la comprensione del motivo di questi standard specifici per quel particolare progetto (o nella particolare organizzazione). La decisione di implementarli sul codice esistente si basava su una logica. Senza conoscere la logica, è difficile commentare la "bontà" di quella decisione.

Riconoscerò ciò che qualcuno ha affermato che gli standard sono implementati per la "produttività a lungo termine", come la manutenibilità del codice. Forse si è verificato un evento che ha arretrato gravemente il progetto a causa della confusione e dell'errata interpretazione.

Sembra che ci sia molta emozione da entrambe le parti - cerca di arrivare a una discussione ragionata.

Come probabilmente hai visto dalle altre risposte e commenti, il tuo progetto ha grossi problemi, quindi quello che sto per suggerire non ha grandi possibilità di successo, ma è qualcosa che puoi provare senza grandi rischi per quanto riguarda la tua stessa pelle.

Richiedi un incontro tra quattro occhi con il tuo sviluppatore principale. Supponiamo che tu sia interessato a comprendere a fondo i vantaggi di essere così rigoroso con lo standard di codifica e perché la base di codice era in una forma così brutta prima di introdurli. È molto importante mantenere un atteggiamento molto aperto e "Sto cercando di imparare" durante questa discussione. Il tuo sviluppatore principale è probabilmente già più stressato di te o di chiunque altro nella tua squadra e probabilmente sarà molto difensivo non appena sentirà l'odore di qualche critica.

Cerca di spingere la discussione nella direzione di cercare di capire come raggiungere il tuo obiettivo comune; fornire prontamente software funzionante e gestibile.

Ad esempio, un po 'di frutta bassa è quella di non aggiungere altro alle linee guida sulla codifica. Ogni volta che succede, il codice che precedentemente aderiva alle linee guida non lo fa più, e ciò comporta che è necessario riscrivere grossi pezzi di codice. Spero che il tuo capo sviluppatore possa vedere che anche se la regola aggiunta aggiunge valore (dal suo punto di vista), potrebbe non fare tanto bene quanto motivare la riscrittura in questa fase del progetto già in ritardo.

Se funziona, puoi provare a fargli rimuovere le regole più arbitrarie che non possono essere formattate automaticamente con qualche strumento.

Gli standard di codifica sono buoni. Cambiare gli standard di codifica è costoso (beh, è ​​costoso se li rendi meno permissivi; se una modifica allo standard lascia tutto il codice esistente ancora conforme, non è un problema), quindi dovrebbe essere fatto solo quando assolutamente necessario.

Una cosa da fare, forse, è avere il lead che controlla tutto il codice prima di eseguire il commit / unire / qualunque cosa per assicurarsi che sia conforme allo standard, poiché a quanto pare la catena di strumenti esistente sembra non essere in grado di controllarlo automaticamente.

software che potrebbe aiutare a salvare vite umane in situazioni di emergenza accelerando la distribuzione del cibo

Credo in buoni standard di codifica, ma credo anche che salvare vite umane sia molto più importante.

La tua più grande priorità deve essere quella di salvare la vita delle persone . Immagina se questo software distribuisce cibo alla tua famiglia o al tuo team. Qualcos'altro può venire dopo.

La buona notizia: hai dei test. I test ti aiuteranno a rispettare i tuoi standard di codifica senza interrompere la funzionalità, ma ciò dovrebbe avvenire dopo la spedizione , non prima.