Come si ottiene la coerenza nel codice sorgente / UI senza soffocare la creatività dello sviluppatore?

La cosa più importante per te e il tuo team dovrebbe essere comunicazione .

Potresti voler sviluppare una styleguide comune che definisce cose come "come deve essere chiamato un intervallo di date". Tuttavia è molto importante che questo styleguide sia apprezzato da tutti i membri del team. Se qualcuno ha la sensazione "oh mio dio, so come fare il mio lavoro e ora ho questo stupido documento che mi dice cosa fare", quindi lo sforzo è condannato sin dall'inizio. D'altra parte se tutti sono d'accordo "sì, è una buona idea, ora so dove controllare quando non so come nominare una cosa", allora sarai molto più produttivo.

Tuttavia tale credenza comune è stabilita al meglio, quando tutti sono parte del processo di sviluppo e si sente come "sì, ho contribuito a questo insieme di linee guida". Se il tuo team di programmazione è piccolo, come hai scritto, allora è la situazione ideale.

L'altro fatto ti darà la caccia per il resto della tua vita di sviluppo: non scriverai mai un codice perfetto. È stato detto già. Ma non scriverai mai mai un codice, che quando lo rivedi alcune settimane dopo ti sembrerà ancora buono. Anche se sei l'unico a aver toccato il codice. Io sempre mi trovo a pensare "mio dio, che diavolo hai pensato quando hai scritto quel pezzo di merda?". La cosa divertente è: io so , che ho avuto le mie ragioni per fare qualcosa esattamente nel modo in cui l'ho fatto - non riesco a crederci più.

Devi accettarlo e sì, diventa peggio quando lavori con qualcun altro perché - diciamocelo - scrivere software è come guidare una macchina: nessuno può farlo meglio da solo; -)

Quindi sempre deve refactoring il tuo software. Risolvi le cose che hai sbagliato in primo luogo. Questa è una cosa buona e assolutamente normale.

Bosses don't really ever seem to care about the quality of the code, just when we'll be able to release the next version

Potrebbe essere vero a prima vista. Fortunatamente i tutti capi pensano in questo modo, ma anche se lo fanno: la qualità del codice ha un effetto diretto sulla possibilità di spedire la versione successiva. Il codice errato porta a più bug, porta a più tempo necessario per correggere il prodotto e così via. L'elemento centrale qui è la comunicazione - ancora una volta. Devi abbracciare il pensiero che il refactoring e l'introduzione di un codice migliore siano parte integrante dello sviluppo. Il refactoring non è solo "Oh, questo sembra migliore, prendiamoci un po 'di tempo e implementiamo il cambiamento", ma rendendo il prodotto adatto e robusto per le generazioni future. Questo potrebbe richiedere un backbone che dice ad un'altra persona "No, non possiamo andare avanti, abbiamo bisogno di rifattorizzare la feature X" ma questo fa parte del lavoro.

• Utilizzare l'ereditarietà e gli oggetti comuni per memorizzare l'interfaccia utente comune e il codice in un'unica posizione in modo che possa essere utilizzato in tutta l'applicazione. In questo modo, se qualcosa deve essere risolto, viene risolto in un punto e le modifiche vengono applicate automaticamente ovunque.
• Utilizza l'analisi del codice per verificare lo stile di codifica e applicare determinati metodi di scrittura del codice. Non sarai in grado di coprire ogni possibilità, ma aiuta. Inoltre, dovresti concordare alcuni standard di codifica tra i membri del tuo team e iniziare a usarli.
• Non preoccuparti di sistemare le cose dappertutto subito. In ogni caso, non dovrebbe essere compito di uno sviluppatore. Tutti i membri del team dovrebbero essere consapevoli del "modo migliore" di fare qualcosa di specifico e sistemarlo mentre lo incontrano mentre si lavora su qualcos'altro. Inoltre, dovresti dedicare un po 'di tempo al refactoring del tuo codice durante il tuo ciclo di sviluppo, che potrebbe essere speso per risolvere le vecchie soluzioni per utilizzare quelle più recenti ("migliori").

Chiedi a sviluppatori e designer di collaborare per creare una guida di stile per il tuo prodotto e chiedi agli sviluppatori di seguirla. Avere check-in frequenti mentre il codice è implementato per assicurarsi che corrisponda alle specifiche (in generale, i dettagli ovviamente cambieranno un po 'quando si raggiungono i vincoli di implementazione). Aggiorna le specifiche con il passare del tempo per incorporare le modifiche desiderate.

Per quanto possibile, separa la logica e la presentazione, in modo che se decidi su un nuovo elemento UX (ad esempio, "tra $ start e $ end" invece di "da $ start a $ end"), devi solo cambia una stringa in un unico posto.

Infine, se la "creatività" è davvero un modo educato per dire "non è possibile seguire le specifiche", parla invece di ciò. Ci sono luoghi in cui esprimere la creatività e luoghi in cui lavorare all'interno del design; inventare nuovi elementi di interfaccia al volo porta a un prodotto incoerente e confuso. D'altra parte, la coerenza è solo un obiettivo uno , non l'unico obiettivo: a volte va bene avere qualche incongruenza.

Devi sederti con tutti e inventare uno stile & Guida agli standard. Idealmente, si desidera un documento contenente determinate convenzioni comuni a tutte le parti delle applicazioni. Può contenere standard di denominazione, standard di layout dell'interfaccia utente, ecc ...

Sei preoccupato di soffocare la creatività, quindi assicurati che la guida sia una guida e non una bibbia da seguire religiosamente. Alcuni tipi di piccole deviazioni dalla guida dovrebbero essere OK se sono necessari e il team leader dovrebbe accettarlo con buona giustificazione (la decisione non dovrebbe essere lasciata allo sviluppatore da solo - è necessaria qualche revisione e accettazione da parte dei superiori). A seconda di quanto è grande la deviazione, potresti voler parlare con il management / QA prima di permetterlo, poiché potrebbe indicare un'area per le modifiche nella guida allo stile stesso (se si tratta di una deviazione tentata grande o ricorrente).

È anche importante che ci sia un processo per cambiare / aggiornare la guida per stare al passo con nuove tecniche, nuove idee di design, nuovi marchi aziendali, ecc. Basta essere consapevoli che cambiare la guida può invalidare le vecchie parti del sistema quindi tornare indietro e aggiornare il programma potrebbe essere necessario a volte.

Innovazione == Disorganizzazione.

Ecco come si presenta l'innovazione ("creatività"). Sembra un nuovo codice dirompente, non standard, non conforme.

Ecco la citazione obbligatoria:

A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines.

Ecco perché è importante.

Focus su valore

La coerenza semplice potrebbe non avere alcun valore.

we have lots of places where we have a date range, and we use all kinds of wording to indicate this range is it Start/End or From/To or "Between _ and _".

In che modo agitarsi su questo crea valore? Chi è aiutato? Quanto vale?

Quanto costa costare a lasciarlo da solo?

La coerenza non è un attributo di qualità diretto. Al meglio, un codice coerente potrebbe facilitare la manutenzione o l'adattamento. Ma per la maggior parte, ha pochissimo valore.

Questo non è davvero molto innovativo, quindi non ha molta importanza.

one of the developers might come up with a better way of doing something ... And then we'll have all of the "old" stuff written in the old/poor way, and new stuff written in a better method.

Qual è il valore nel modificare retroattivamente un sacco di codice?

Il costo della ricerca e della sostituzione è davvero appropriato per il valore creato?

Cosa c'è di sbagliato nel cambiarlo alla fine ?

Il codice viene e viene. Il codice viene rielaborato tutto il tempo. Alcuni codici potrebbero essere cancellati (perché non vengono più utilizzati) invece di essere modificati per essere coerenti.

L'innovazione significa che hai un codice legacy che si sta lentamente evolvendo nel nuovo modulo.

Se apprezzi l'innovazione, devi valutare i cambiamenti e le interruzioni associate all'innovazione.