Come trattare il feedback negativo sullo stile del codice da uno sviluppatore senior? [chiuso]

Question

Come trattare il feedback negativo sullo stile del codice da uno sviluppatore senior? [chiuso]

#1 da (2 voti)
#2 da (1 voti)
#3 da (1 voti)
#4 da (0 voti)

0

Sfondo

Ho programmato principalmente in Python negli ultimi anni e principalmente nei miei progetti. Ho sviluppato alcune mie piccole convenzioni stilistiche come lasciare 4 numeri di linee vuote tra le classi e 1-2 linee tra i metodi, ecc.

Attualmente mi sono trasferito in un'azienda con 8 sviluppatori che sviluppano principalmente in Ruby e Rails. C'è una certa mancanza generale di buone pratiche popolari in tutto ciò che riguarda il codice; design di codice errato, alto accoppiamento, nessuna astrazione, codifica vecchio stile, nessuna documentazione centrale, mix di elementi di basso livello nelle viste in un framework MVC ecc.

Che cosa è successo

Nel tentativo di creare codice riutilizzabile, ho eseguito una piccola libreria di 20 righe come di seguito (ho modificato alcune cose ma ho cercato di mantenere i punti principali il più vicino possibile).

Codice:

module CarNaming

  def build_car_name_table()
    # .. stuff here ..
  end

  CAR_NAMES = build_car_name_table()



  # ------------------------------- API --------------------------------

  def car_model_to_name(car_model)
    # .. stuff here ..
  end

end

Alcuni giorni dopo ho ricevuto un'email da uno dei principali sviluppatori di conduttori CC: l'altro sviluppatore principale e l'architetto. L'email ha letto qualcosa di simile qui sotto:

Dear x,

Regarding your latest code on file y, I would suggest to make .. (some technical stuff)..

Also, should I need to remind you to run rubocop against the code before commiting?- it's a mess.

Kind regards, z

Ho provato a vederlo a occhi aperti, quindi sono andato l'altro giorno a chiedere qualche chiarimento. Mi ha spiegato i cambiamenti tecnici e il motivo per cui erano necessari. Li ho accettati nel modo più umile che potevo e ho solo sollevato la mancanza di documentazione che avrebbe potuto prevenirlo (qualcosa su cui non ha commentato).

Tuttavia, quando si è trattato dello stile di codifica, ha menzionato alcune cose. Il punto principale era che cercavano di seguire le convenzioni di Rubocop (un codice di analisi statica).

Gli avvisi automatici erano simili al seguente:

Warning: extra blank line at line x
Warning: extra blank line at line y
Warning: extra blank line at line z
Warning: parenthesis not necessary when calling a method
..

Va bene - abbiamo deciso di sistemarlo sul posto. Ciò che mi ha infastidito è stato quando ha rimosso la linea con i trattini ha esclamato ".. e questo è un disastro" (per la seconda volta).

Domanda

Ho provato a non prendere nulla personalmente ma non posso negare che ho trovato i commenti "confusione" piuttosto fastidiosi. Principalmente da me, avere spazi bianchi e alcune intestazioni per me aggiunge leggibilità rispetto al contrario. Ma come puoi discuterne con qualcuno? Soprattutto se sei il nuovo ragazzo e l'altra persona è in una posizione superiore a te? Vale la pena parlare di questo?

teamwork coding-style python ruby-on-rails

posta Pithikos 04.08.2016 - 21:11

fonte

4 risposte

Leggi altre domande sui tag teamwork coding-style python ruby-on-rails

Qual è la parola ( Problemi di gestione dei vincoli per l'input di un metodo

score 2 · Answer 1

In sostanza, tutto ciò a cui non sei abituato, lo percepirai come un pasticcio illeggibile. Questo è il motivo per cui avere qualche utilità di polizia automatica è una buona cosa, quindi almeno ci si abituerà allo stesso casino e presto non ci saranno più trigger per discussioni infruttuose (l'utilità della polizia del codice è giusta, punto). p>

Quindi, anche se non necessariamente un comportamento priplomatico, non dovresti prenderlo sul personale. Sei quel nuovo topo che ha un odore un po 'diverso. Dagli un paio di settimane e ti piacerà lo stesso codice perché non conosci nessuno (o almeno ti sarà difficile ricordare come lo facevi).

Detto questo, penso ancora che lo stile di Allman sia di gran lunga superiore alla formattazione di K & R / Stroustrup che devo usare al lavoro. Ma i miei colleghi hanno visto troppe righe di codice mal formattato, che hanno incasinato le loro menti oltre ogni possibilità di riparazione. Quindi la nostra utility di polizia di formattazione è uno stronzo. Ma è ancora meglio che non averne uno con alcuni programmatori con idee diverse sull'argomento.

score 1 · Answer 2

Stai scrivendo Ruby ora, non Python.

Diverse lingue tendono ad avere convenzioni di stile diverse. Ruby non fa eccezione, qui. Questo non è un problema di preferenza personale. Il team è d'accordo su uno stile ed è tua responsabilità come membro del team seguirlo.

Detto questo, ci sono guide di comunità per questo genere di cose.

Ecco uno: link

Anche lo stile dei commenti non è una questione di opinione personale. Ecco una guida: link

Inoltre, a proposito, il codice che hai postato non è valido Ruby.

score 1 · Answer 3

L'esperienza mi ha insegnato che ogni squadra ha i propri capricci e la maggior parte di loro è meglio lasciare così com'è. Sembra che questo manager abbia pochi problemi reali da masticare, quindi questa sarà la loro soapbox; quindi lasciali tenerlo; è importante per loro.

L'obiettivo finale di qualsiasi standard di codifica è facilitare il riutilizzo del codice. O un collega o te in futuro dovrà rivisitare e capire cosa sta facendo il codice e farlo fare altre cose.

Il tuo modo di guardare sembra buono; Non vedo un disastro, ma se ognuno costruisce cose a modo suo, ci vuole del tempo per andare su e giù per lo stile di ogni persona. È come se diversi autori scrivessero un libro. Sono stato in codice che è stato difficile da seguire proprio per questo motivo.

Ho scoperto che, a lungo termine, i problemi che erano difficili da risolvere erano generalmente causati da persone che non facevano le cose giuste, come i valori di hard coding, l'uso improprio delle risorse o la creazione di una soluzione eccessivamente complessa. La sintassi semplice è molto raramente un problema reale. Non me ne preoccuperei a meno che non sia tutto ciò di cui l'architetto sembra preoccuparsi. Ci sono problemi più grandi di cui preoccuparsi.

TLTR: non lo suderei a meno che non sia tutto ciò di cui si preoccupano.

score 0 · Answer 4

Questa è solo una questione di scarsa comunicazione. Dopo il fatto ti è stato detto di eseguire un'analisi del codice statico. Non è colpa tua.

Molti luoghi hanno quella che io chiamo "Documentazione per sviluppatori Day 1". Semplicemente aiuta gli sviluppatori a diventare subito operativi.

Scarica l'origine qui ...
Scarica Rubocop ...
Scarica qui la nostra guida alle convenzioni di stile ..
Scarica queste utilità ...
Accedi al nostro software di tracciamento dei bug qui ....

Prima di effettuare il check-in del codice:

Esegui l'unità con un set completo di test unitari, assicurati che tutti i test superino
Esegui analizzatore di codice statico (Rubocop), correggi tutti gli errori di avviso.
Commit

Se questi documenti non esistono, aiuta il prossimo programmatore / programmatore creando questi documenti.

Inoltre, l'applicazione dello stile dovrebbe essere automatizzata. Usiamo Re-sharper (.Net) e inseriamo i nostri standard di codifica / stile nei file di configurazione di Resharper. Gli sviluppatori vengono avvisati in tempo reale quando si stanno scostando per le convenzioni di denominazione / stile. Potrebbe esserci qualcosa di simile per Ruby, o forse quando uno fa una build localmente, Rubocop viene eseguito automaticamente e i problemi vengono segnalati / sollevati prima del check-in. Forse è possibile automatizzarlo così come parte del processo di compilazione.

Il punto è migliorarlo per la persona successiva.