Come si codifica senza offendere?

Ciò che intendo con ciò è: come si sviluppa su una base di codice condivisa con gli sviluppatori che ci lavorano da anni e ne hanno molta familiarità?

Non voglio calpestare nessuno, ma non ricevo lamentele così sottili sul modo in cui faccio le cose, sia che si tratti di come spazio bianco il mio codice, o con che frequenza accedo a SVN (troppo spesso). Quindi, mentre posso cambiare facilmente queste cose, voglio essere uno sviluppatore di team migliore in generale.

Non sono sicuro di cosa fare, oltre a chiedere, ma forse avete dei pensieri che potrei mettere in pratica.

AGGIORNARE

Non c'è nessuna guida di stile di cui parlare - è solo che le persone non sono abituate a condividere la base di codice. Ognuno ha il proprio piccolo mondo-codice insilato.

Questo è un negozio Perl, ma sono sicuro che si applicano a qualsiasi lingua

AGGIORNAMENTO 2

Il CTO che in seguito divenne CEO era un megalomane completo ed era la fonte principale di queste lamentele. Se non hai fatto le cose esattamente come gli piaceva, che si trattasse di utilizzare un Mac o Emacs o 4 spazi tab invece di 2 o vestirti in un certo modo, eri inferiore. È stata una situazione orribile che ho cercato di correggere, ma l'unica risposta corretta per me è stata partire.

Sono convinto che si sia trattato di un episodio di bullismo in un ambiente di lavoro e, successivamente, sono più consapevole di ciò che potrebbe essere un sottile bullismo e un comportamento inappropriato in un ambiente di lavoro.

Per qualsiasi sviluppatore in cerca di risposte a una situazione come questa, parti immediatamente. Non puoi lavorare in gruppo per uscire da una brutta situazione di squadra.

Chiedere. Cioè, chiedi alle persone con cui lavori. Fai del tuo meglio per attenersi allo stile stabilito del codice esistente. Chiedi soprattutto se esiste un elenco di documenti di standard di codifica e seguilo. Se non ce n'è uno, scrivi una prima bozza in base a ciò che osservi nel codice e poi chiedi agli altri membri del team di criticarlo. Farai alla società (e ai nuovi sviluppatori che ti seguono) un servizio iniziando a documentare le pratiche di codifica accettate. L'unico rischio è forse quello di rimanere intrappolati nel mezzo se si scopre che i vecchi non sono d'accordo tra loro su ciò che è o non è accettabile.

Inoltre, non aver paura di essere te stesso . Potresti essere il nuovo ragazzo, ma sei un membro del team e le tue opinioni sono valide. Se riesci a pensare a modi migliori per fare qualcosa, suggeriscilo. Rispetta gli altri membri del team e il modo stabilito di fare le cose, ma non lasciare che ti spingano in giro. La società non ti avrebbe assunto se non avesse valutato il tuo contributo.

Aiuterà molto se riesci a trovare qualcuno nella squadra che sembra amichevole e particolarmente disposto a rispondere alle domande. (Se è una buona squadra, dovrebbero essere tutti, ma le squadre non sono sempre così.) Il tuo capo potrebbe aver assegnato qualcuno per aiutarti a iniziare. Usa quella persona come risorsa. Scrivi le domande man mano che ti vengono poste e poi chiedi a quella persona utile di rispondere di tanto in tanto.

Per quanto riguarda il check-in del codice "troppo spesso", perché non creare il proprio ramo per i tuoi commit periodici, e poi tornare al trunk quando il tuo codice è pronto? Non ci sono danni a nessuno nel farlo, e quando i tuoi colleghi ti vedono trarre benefici da SVN che vorrebbero, potrebbero seguire il tuo esempio.

Per quanto riguarda gli spazi bianchi: fallo ma il codice lo fa già. Seguire la corrente.

Per quanto riguarda i check-in SVN: documentali in modo molto chiaro. Questo aiuta le persone a capire cosa sta succedendo nel codice. (Seguito: quali sono le loro obiezioni ai frequenti check-in?)

In generale: iniziare a creare un documento standard di codifica. Non provare a riempirlo con 100 regole. Aggiungi le regole appena vengono visualizzate.

Inoltre: fai domande ai tuoi colleghi sviluppatori. Ciò dà loro l'opportunità di ponderare prima di fare qualcosa che non gli piacerà. Inoltre, crea relazioni. Inoltre, scopri di più su come funziona il negozio.

Per quanto riguarda lo stile di formattazione del codice (spazi bianchi, tab, dove vanno le parentesi graffe, ecc.) Dovresti seguire lo standard prevalente nel codice. Se non ce n'è uno, non credo che abbiano molto di cui lamentarsi. Quando si tratta di esso, che si tratti di parentesi graffe sulla propria riga o meno, che gli spazi attorno agli elenchi dei parametri del metodo, ecc. Siano preferenze personali, e si dovrebbe cedere allo stile prevalente perché a lungo termine, in realtà non lo fa importa . Ciò che conta è essere coerenti.

Quando si tratta di controllare il codice in SVN, proverei a evangelizzare quello che ritengo sia il modo giusto di fare le cose, piuttosto che lasciarmi andare a vapore. Non controllo il mio codice a meno che non compili e superi i test e, se sto apportando diverse modifiche non correlate, suddivido il mio lavoro in più commit. Se qualcosa si romperà per un po ', creo un ramo e faccio il mio lavoro lì. I commit ottengono commenti descrittivi. Questo funziona meglio della mia esperienza rispetto al metodo "controlla una pila di modifiche venerdì alle 5:00" e sembra essere la "best practice" prevalente secondo la maggior parte di ciò che ho letto qui e altrove.

Prima leggi il loro documento sulle convenzioni di codifica (se non ne hanno uno, chiedi loro di scriverne uno in modo da poterlo seguire)

Quindi prendi nota e fai uno sforzo consapevole per seguire quello e quello che dicono. Potrebbe sembrare che siano duri, ma gli standard di codifica sono importanti, è meglio sottolineare ora cosa c'è che non va piuttosto che lasciarlo diventare un problema in seguito quando si stanno apportando cambiamenti più grandi.

Sono sicuro che farai lo stesso tra un anno o due quando un novizio ti farà un passo avanti :)

Richiedi gli standard del codice azienda. Presta maggiore attenzione ai dettagli. Se vedi che gli altri seguono una forma molto specifica di spazio bianco e schemi di controventi, seguili. Come suor potresti sostenere che questo è pignolo, ma come Jr. o nuovo ragazzo in un progetto devi dimostrare che puoi seguire prima di poter guidare.

Inoltre, comprendi che qualsiasi nuovo sviluppatore di un progetto avrà effettivamente un tempo necessario per "accelerare". Quindi non preoccuparti per quello.

La cosa migliore che puoi fare è seguire i consigli che ti danno. Non c'è modo di dire in anticipo cosa vogliono. A meno che tu non sia un sensitivo.

Tuttavia, suggerirei che mentre le persone ti danno consigli, lo documenti. Hai un wiki? Se è così, usalo. In caso contrario, un file di testo archiviato con il codice sorgente potrebbe essere una buona idea. Costruire una guida di programmazione ben organizzata. Ti aiuterà a ricordare come fare le cose, e se qualcuno contraddice un consiglio precedente che ti è stato dato, ti darà un punto di riferimento per discutere l'incoerenza. Inoltre, quando la prossima persona si unisce alla squadra, non dovrà passare attraverso quello che stai passando.

Suggerirei di non attribuire il consiglio nel documento alle persone (quindi "i blocchi di codice dovrebbero essere rientrati di tre spazi", non "Bill mi ha detto che i blocchi di codice dovrebbero essere rientrati di tre spazi"). Tuttavia, se è possibile registrare tali informazioni in modo discreto (ad es. Nel commento di commit, scrivere "aggiunta regola sul rientro in base al consiglio di Bill"), potrebbe essere utile per risolvere le contraddizioni, poiché è possibile ottenere immediatamente due punti di vista Su qualcosa. Quello a cui sto pensando, qui, è che se ti viene dato un consiglio contraddittorio, devi evitare di diventare un pallone da calcio calciato da due colleghi che non sono d'accordo su qualcosa. È un po 'un approccio da copertina, ma potrebbe essere prudente.

Una facile è trovare la guida di stile e seguirla. Molti non hanno nulla di troppo offensivo in essi e ti impediranno di offendere gli altri.