In che modo i programmatori gestiscono Project Lead / Managers? [chiuso]

Ottenere la formattazione / spaziatura e tali "cose banali", sono un prerequisito importante per discutere di elementi più importanti. Se il codice non segue i tuoi standard di codifica, sarà più difficile per gli altri seguirli per una revisione.

Per quanto riguarda la riscrittura, non penso che nulla dovrebbe essere riscritto solo perché esiste una nuova tecnologia. Tuttavia, se esiste una nuova tecnologia che è utile, è molto più semplice riscrivere il codice nella fase di revisione rispetto a quando il prodotto è in produzione.

Ti suggerisco di provare a ottenere il codice formattato il più bello possibile prima della revisione, in modo che non sia una distrazione. In secondo luogo, se il tuo lead desidera utilizzare un metodo / tecnologia specifico, prova ad imparare perché è stata presa questa decisione. Il tuo lead / manager dovrebbe avere più esperienza di te e quindi potrebbe sapere di alcuni grattacapi che la nuova tecnologia salverà più avanti lungo la strada.

La coerenza del codice è estremamente importante. Assicurati di seguire le linee guida stabilite dalla tua azienda per la T. Se tutti codificano con le stesse linee guida in mente, all'improvviso l'intero progetto sembra coesivo.

Prova a chiedere al tuo manager perché vuole usare la tecnologia più recente e più grande? È per compiacere il suo capo affamato di buzzword? Questa nuova tecnologia ti aiuterà a completare questo più veloce?

Prova anche a tenerlo a mente ogni volta che stai codificando:

Leave the campground cleaner than your found it.

Avere questo presente nella tua mente e improvvisamente la codifica diventa divertente e ti sentirti bravo durante la codifica perché sai che stai facendo un buon lavoro, professionalmente.

Direi praticamente in ogni situazione - prova a trovare il terreno comune. Idealmente, almeno, la guida tecnica vuole che il codice di qualità venga creato in modo tempestivo. Tutto ciò che rende il codice migliore, o il processo più veloce è una vittoria. A volte deve solo essere bollito fino a quel livello.

Le revisioni del codice rappresentano una sfida in più: possono essere costose sia in termini di tempo di preparazione e partecipazione dei partecipanti, sia in caso di interruzione del flusso (il punto in cui si sta veramente canticchiando nelle attività di sviluppo).

In questo particolare scenario, eviterei di dire al gestore che il lavoro di formattazione è "banale". Come altri hanno sottolineato - non è banale - un codice coerente e di facile lettura aiuta tutti a lungo termine. MA - la maggior parte del lavoro di formattazione non è discutibile. Di solito qualcuno ha trovato un problema con linee guida di codifica piuttosto chiare. Come dici tu - l'incontro potrebbe essere speso per gli articoli in cui è necessario il consenso e la discusione è richiesta.

Suggerirei quanto segue:

• Fai del tuo meglio per passare attraverso le linee guida di codifica e inviare il codice che è già formattato correttamente. A meno che le tue guide siano nebulose, dovresti essere in grado di inviare codice ben formattato senza una recensione.
• Chiedi ai revisori di contrassegnare il codice per il formato PRIMA della riunione e consegnarti i loro commenti nella riunione.
• Non invitare la discussione su piccole cose, accettare e andare avanti - basta dire che rivedrai i markup e creerai gli aggiornamenti e inizierai a fare domande su ciò che è difficile.

C'è un punto difficile di fiducia qui - devi assicurarti che i cambiamenti entrino in gioco. Se è troppo banale da giustificare una discussione, dovrebbe essere così facile da cambiare che puoi aggiornare il codice in un'ora o due. Se le persone arrivano a credere che i loro markup non vengono aggiornati nel codice, allora sentiranno il bisogno di doppiarli nella riunione e ci sei ... di nuovo sulla formattazione.

Quale parte del project manager / responsabile tecnico è il tuo capo e ha il diritto di determinare come sarà il software, indipendentemente dal fatto che tu sia d'accordo o no? Sembri un impiegato dei problemi per me e scommetto che anche il tuo capo pensa così.

Come gestisci gli scenari sopra riportati? Risolvi ciò che vogliono aggiustato.

Supponendo che gli standard di codifica non siano troppo onerosi / rigorosi, allora dovrebbero certamente essere seguiti, anche se non ci si abitua. Dai loro una possibilità, non sai mai cosa può accadere. (Preferivo lo stile K & R per parentesi, fino a quando non ho dovuto usare lo stile Allman nel mio ultimo lavoro. Ora preferisco lo stile Allman, come credo sia più leggibile.)

Se c'è un problema con gli standard di codifica (per esempio troppo complicato, rigoroso, che cosa è), allora questo deve essere portato con i lead e i manager. Probabilmente avrai bisogno di prove per supportare questa posizione.

Allo stesso modo, puoi cortesemente chiedere loro di supportare le loro posizioni, specialmente nel caso di una riscrittura richiesta che non usa la loro nuova tecnologia, pattern o qualsiasi altra nuova tecnologia hot preferita. Tuttavia, non dovresti venire a questo come antagonista con una mente chiusa. Per te potrebbe sembrare solo una parola d'ordine, ma forse c'è una buona ragione per cui non stai vedendo o capendo.

Potrebbe anche essere utile sollevare la questione dei costi. Il tempo necessario per la riscrittura è giustificabile di fronte alle carenze (percepite o effettive) della versione esistente?

Non riesco a sottolineare troppo la necessità di mantenere una mente aperta. (E, come afferma Htbaa nel suo commento, la coerenza è importante.)

Stai riscontrando il dolore dello noleggio delle biciclette . Il modo per risolvere questo problema è aiutare gli allevatori di biciclette a rompere l'abitudine trovando i modi in cui possono contribuire in modo costruttivo: l'idea non è di infiammarli o incitarli.

Per cose che sono facilmente trasferibili (formattazione, spaziatura, ecc.) fai in modo che tutti siano d'accordo sullo stile del team e utilizzino uno strumento di formattazione per sistemarlo prima fai una revisione del codice. Non ha senso perdere tempo a rivedere il codice che può essere risolto con strumenti automatici. Se dai la precedenza su questo fronte, guadagnerai un po 'di credibilità che ti servirà per il prossimo passo, che è ...

Crea una checklist per la revisione del codice. Automatizza, con strumenti di analisi statici, il controllo dei tipi di bug che gli strumenti di analisi statici sono in grado di identificare. Quindi, identifica le classi comuni di bug che rimangono e rendili una checklist per la revisione del codice. Questo darà agli aspiranti bikers un modo costruttivo per contribuire a una revisione del codice e saranno meno inclini a generare richieste di permutazione casuali. Win-win!

Non dimenticare di rivedere periodicamente la tua lista di controllo. Nel corso del tempo, il tuo team diventerà acutamente consapevole di alcune classi di bug e migliorerà nel non scrivere quei tipi. A quel punto, è meglio sostituire quella classe nella tua lista di controllo con una classe che stai ancora scrivendo.

Ho trovato una soluzione semplice che ha funzionato per me da anni. Comincio ogni revisione con un elemento di azione chiamato FIX REDLINES. Si salta rapidamente la punteggiatura, la grammatica, la formattazione, i commenti degli standard di codifica negli incontri con appena menzione, se non addirittura una menzione. Accetti semplicemente di incorporare i commenti di tutti offline (non importa quanto stupidi pensi che possano essere) perché di solito ci vuole più tempo per discuterne piuttosto che andare avanti e farlo. Quando si va a incorporare i commenti offline e si scopre che in realtà non è banale o è semplicemente sbagliato allora ne vale la pena. Se è solo una questione di voi pensate che sia meglio andare avanti e incorporare comunque perché la vostra discussione su questo è solo sprecare il tempo di tutti e alla fine probabilmente non importa comunque se non quello di massaggiare il vostro ego.