Simboli o parole chiave per gli operatori?

"Ho semplicemente copiato questa regola" Penso che questo lo riassuma.

Se non puoi giustificare una convenzione di codifica con un argomento piuttosto strong, non ne hai uno. Loro rallentano gli sviluppatori e causano argomenti.

"leggibilità" non è abbastanza buono. Come hai scoperto, è una cosa soggettiva e le persone hanno idee forti in un modo o nell'altro.

I motivi per cui sono d'accordo sono sensati

• Test automatici. In questo modo possiamo eseguire i controlli di regressione più velocemente e in modo più economico rispetto a manualmente.

• Funziona su un ramo di funzionalità. Quindi se un'altra funzione è terminata prima della tua, possiamo rilasciarla.

• Versione Api. Quindi possiamo eseguire l'aggiornamento con zero tempi di inattività

quel tipo di cosa

L'obiettivo è che il tuo team debba far funzionare questo progetto. Potrebbero esserci regole empiriche o standard esterni, ma se le cose sono sbagliate o non vengono fatte in tempo, chi è al di fuori del team non arriverà e lo aggiusterà per te. A chi importa cosa pensano.

Vorrei utilizzare i seguenti criteri e scegliere quale applicare.

1. Che cosa utilizza la base di codice esistente?
2. A cosa servono gli attuali sviluppatori?
3. Ci sono esperti di dominio o leader di progetto coinvolti nella creazione di formule (ingegneri, statistici, analisti, ecc.) che si affidano alla comunicazione in un modo o nell'altro?

Per quanto i programmatori amano avere il controllo di tutto, se posso abdicare qualsiasi logica di dominio a qualcun altro con esperienza, userò il codice che capiscono, quindi non devo tradurre.