Come mantenere la coerenza nell'architettura dell'applicazione man mano che il team cresce?


49

Come unico sviluppatore in una startup, ho avuto il lusso di poter prendere molte decisioni nell'architettura e nei framework della nostra applicazione.

Avanti veloce di 4 anni e un'acquisizione dopo, ho una squadra di 5 e molte volte sembra il selvaggio west. Le persone che prendono qualsiasi decisione progettuale li piacciono: numero intero ed enum per tipi di DB in un posto e stringa un altro, questo framework per un problema e quindi un framework diverso per lo stesso problema altrove, ecc.

Come posso applicare la coerenza? Mi sembra importante, ma i membri del mio team sembrano sottoscrivere la metodologia "se funziona, funziona".

Immagino che gran parte della mia domanda sia: non è realistico da parte mia aspettarsi standard come questo? Faccio fatica con l'idea di imbattermi in un dittatore che soffoca la creatività ma fare ciò che vogliono sembra non essere scalabile.


8
Puoi dirci il più possibile sul tuo processo SDLC esistente? Sei a cascata, agile, ecc? Usi TFS o la gestione delle attività? Esegui revisioni del codice o usi FxCop o altre forme di convalida del codice? Produci documentazione di progettazione? Hai un ruolo di architetto designato?
John Wu,


1
@gnat: non è un ottimo duplicato, se le risposte sono indicative.
Robert Harvey,

2
Ad essere onesti, questi standard avrebbero dovuto essere stabiliti molto presto e basati su alcuni documenti di "buone pratiche" ampiamente accettati, in modo che nessuno possa lamentarsi di favoritismi o elitarismo. Se stai ricevendo un duro respingimento da un individuo, dovrai considerare se un cowboy vale l'ambiente salubre per il resto della squadra e sostituirlo, se ne andranno comunque a lungo, lo fanno sempre. Quindi penso che tutti i consigli indicati di seguito per utilizzare una rigorosa revisione del codice prima dei check-in e per aggiungere un componente di architettura funzioneranno a meraviglia.
Patrick Hughes,

1
Questo è il Santo Graal dell'ingegneria del software (a parte l'altro Santo Graal, che è l'esatta richiesta di requisiti).
pmf

Risposte:


55

Cosa ti rende così speciale?

La mia CPU dice che funziona e voglio andare a casa. Perché mi dai fastidio?

Puoi affrontare questo atteggiamento costringendo tutti a inviare richieste pull. Ma ora le scadenze sono imminenti. Il codice errato preme sulle porte del tuo castello incontaminato e alla fine cedi alla pressione. Oppure vinci solo per trovare le foglie di tutti e nessuno usa il tuo castello incontaminato.

Esistono molti strumenti che aiutano a risolvere questo problema. Controllo del codice sorgente, revisioni del codice, standard di codifica, ecc. Ma il cuore e l'anima del problema sono le tue opinioni soggettive su ciò che è meglio deve essere considerato rilevante. Per questo devi guadagnare e mantenere il loro rispetto. Fallo e questo è molto più semplice. Non farlo e nessuno strumento o pratica ti salverà.

Il modo migliore per farlo è comunicare in anticipo. Non dirmi "non usiamo le stringhe per i nostri tipi di DB in questo negozio" 6 mesi dopo che ho deciso l'idea. Dirmi che è stato sepolto nella documentazione per 2 anni non è una giustificazione per avermelo permesso.

Per qualunque motivo tu abbia cose a cui tieni. Se ti preoccupi di loro e hai un punto, comunica chiaramente queste cose prima, durante e immediatamente dopo la codifica di ogni modulo.

Lo stalking di codice è una pratica meravigliosa. Investi in tutti gli strumenti e le pratiche di cui hai bisogno in modo da poter rivedere il codice in pochi minuti dalla sua scrittura. Associare il programma e lo strumento è semplicemente una sedia per gli ospiti.

Perché? Ogni secondo che passa dopo che scrivo codice aumenta esponenzialmente il costo per cambiarlo. Questo perché la mia memoria del codice ha un'emivita. Comincio a dimenticarlo nel momento in cui la mia vescica richiede una pausa.

Riduci le cose che ti interessano ai loro principi di base. Invece di colpirmi con un elenco di 101 regole da seguire, dammi i 10 principi che violano in modo da poter capire quale regola 102 dovrebbe essere da sola.

Consentimi di imporre la mia visione aiutandomi a vedere la tua e andremo d'accordo.

non è realistico da parte mia aspettarsi standard come questo? Faccio fatica con l'idea di imbattermi in un dittatore che soffoca la creatività ma fare ciò che vogliono sembra non essere scalabile.

Quindi non dettare! Rendi questa esperienza positiva. Questa non è una sciocchezza hippy della nuova era. È psicologia di base. Stai cercando di modificare il comportamento umano. Casuale e positivo è il più rinforzante (basta chiedere a Las Vegas). Se diventi negativo devi essere coerente con il tuo rinforzo. È un dolore introvabile. Sii positivo mentre diffondi la saggezza e puoi essere casuale.

So da dove vieni perché ci sono stato. Avevi il controllo e ora non c'è più. Lo rivuoi indietro. Bene, superalo. Adesso hai una squadra. Non hanno bisogno di essere controllati. Ciò di cui hanno bisogno è la leadership. Ciò di cui hai bisogno non è il controllo. È influenza. Funziona meglio ed è molto meno lavoro. Padroneggia e rilassati. Questo dovrebbe essere divertente.

Fallo bene e puoi andare in vacanza e funzionerà ancora. Come? Non solo essendo un leader, ma anche facendo diventare gli altri leader. Una volta che hai instillato la tua visione nel team, possono lavorare mentre te ne vai semplicemente imitando ciò che stai facendo. Guida i principianti e incoraggiali a intensificare e influenzare anche gli altri.

So che è difficile. Non abbiamo intrapreso questa professione perché siamo bravi a trattare con le persone. Comunichiamo meglio con il codice. Va bene. Fallo velocemente e spesso. Mostrami perché il tuo è migliore. Ascolta se dico che non lo è. Fallo mentre ci sto ancora pensando. Adoro programmare. Ci sono poche persone sul pianeta con cui posso parlarne. Sii uno di loro.


4
È abbastanza evidente cosa intendi per "stalking del codice" ... Ma Google non mi dà nient'altro che la legge sulla criminalità di tutto il mondo.
Jeremy

3
aggiungere "standard di codifica" all'elenco
BЈовић

5
Dal momento che mi sembra di introdurre il termine, darò l'etimologia di "stalking di codice". Avevo controllato un codice che utilizzava una fabbrica astratta per ottenere i suoi timestamp. Uno sviluppatore peer stava provando a unire (controlla il codice in) e stava scorrendo le modifiche al codice dal suo check out. Notò la mia fabbrica e pensò che fosse curioso. Non era sicura del perché lo stavo facendo. Quindi si avvicinò e mi chiese. Quando sono sembrato confuso, ha detto: "Oh, stavo solo scrivendo un codice per inseguirti". Facebook sta cambiando il nostro vocabolario.
candied_orange

1
Vero! " Consentimi di imporre la mia visione aiutandomi a vedere la tua e andremo d'accordo. " Adoro quando poesia, codice e filosofia si mescolano!
Pedro Lobito,

@candied_orange: Sono un po 'sconcertato dall'intera faccenda dello "stalking del codice". La stavi solo punendo? Nel contesto della tua risposta, sembra che lei ti stia codificando.
Robert Harvey,

23

Per prima cosa, fai in modo che le persone mantengano cose che non hanno scritto. È molto facile per uno sviluppatore abituarsi all'utilizzo di framework e tecniche a cui sono abituati. È stonante dover passare da quadri a metodologie. Se qualcuno è costretto a spostarsi al di fuori del proprio angolo del codice e sperimentare questo spesso, ciò richiederà un po 'di lamentele e, si spera, una discussione produttiva che può portare le persone che vogliono standardizzare qualcosa.

Successivamente, richiama le richieste e le recensioni del codice. Non consentire mai che il codice venga unito ai rami principali senza una prima revisione del codice. Chiunque può farlo. Ancora una volta, quando qualcuno vede qualcosa di diverso da quello che avrebbe fatto, può spingere la discussione e il lavoro di squadra a trovare una soluzione migliore. Inoltre rende tutti un custode della base di codice, che (si spera) fa sì che le persone si preoccupino di ciò e dello stato del codice che lo contiene.

Infine, fai discussioni di progettazione. Possono essere formali o informali, ma li hanno. Lascia che quelli che vogliono partecipare lo facciano. Discutete quali framework volete usare, i pro ei contro di enum vs ints, ecc. Quindi prendete una decisione e documentatela da qualche parte (come un documento standard). Quindi hai qualcosa da indicare quando sorgono problemi. Inoltre, non aver paura di rivisitare una decisione sugli standard. La tecnologia cambia (rapidamente) e così anche le tue esigenze come squadra e come azienda.

Aiuta le persone a vedere cosa vedi e senti come se fossero interessate alla qualità del codice. Quindi stimola delicatamente le discussioni verso la ricerca di uno standard quando emergono differenze di opinione.


La cosa bella di questo metodo è che il manager non sta solo imponendo le sue preferenze, sta dando alla squadra la possibilità di decidere e dando loro il potere di farla rispettare.
Robin Bennett,

6

Esegui revisioni del codice ogni volta che qualcuno desidera unire il codice nel ramo / trunk principale e mantieni le persone a tali standard durante la revisione del codice.

E non intendo dire che solo tu dovresti eseguire le revisioni del codice. Tutti dovrebbero rivedere il codice di tutti gli altri. Questo diffonde la conoscenza del sistema in tutto il team, ma crea anche una situazione in cui Carol rivede il codice di Bob e dice: "Vedo che hai usato un numero intero lì. Uso sempre un enum". Scoprono le discrepanze che hai visto e, supponendo che si preoccupino, si renderanno conto che tutti devono entrare nella stessa pagina.

Gli standard accettati e concordati emergeranno, a quel punto li documenterai e ti assicurerai che le persone li seguano. Ciò include elementi come "enum nel DB per ...", ecc. È inoltre possibile includere la documentazione dei framework da utilizzare, ecc.


Immagino che gran parte della mia domanda sia se non è realistico da parte mia aspettarsi standard come questo. Faccio fatica con l'idea di imbattermi in un dittatore che soffoca la creatività ma fare ciò che vogliono non sembra scalabile
Deekor

3
@Matthew, anche se generalmente sono d'accordo con te, lo farei in ordine inverso. Prima le revisioni del design e le linee guida emergono da / durante le revisioni del design. Se si mette l'onere di scrivere tutto in anticipo sull'architetto / lead, questo sta spostando l'onere sull'interveniente .
Nick Alexeev,

@Deekor: devi scegliere le tue battaglie. Scopri cosa devi appoggiare e documentalo. Non devi dettare tutto.
Robert Harvey,

2
@Deekor, puoi applicare standard e pratiche di codifica comuni senza "soffocare la creatività". Questa è comunque una discussione spuria. Standard di codifica comuni portano a software di facile manutenzione. La codifica gratuita per tutti porta a incubi.
Matteo

1
@ Nick Alexeev, sono d'accordo; modificherà.
Matteo

1

Ove possibile, è possibile scrivere strumenti / script per analizzare automaticamente i progetti e determinare quali standard, strumenti e approcci utilizza il progetto. È possibile farlo eseguendo uno strumento personalizzato come parte di una build CI.

Far scrivere l'output dagli strumenti in un documento 'scorecard', ad esempio un foglio di google con una riga per unità (ad esempio per 'applicazione' o progetto o api o altro), con le colonne per le varie metriche / standard seguite. Ciò darà alla gente visibilità su quali standard ci siano, su quanto bene siano adottati ecc. E fornirà un certo ordine al caos.

Puoi anche aggiornare manualmente le colonne, ma buona fortuna per mantenerle aggiornate: D


0

Oltre alle risposte fornite, dico che dovresti educare il tuo team su ciò che ti aspetti da loro come professionisti dello sviluppo software, a partire dal momento in cui intervistano per entrare a far parte dell'azienda.

1 - Creare e seguire le convenzioni di codebase

Questa è una delle misure più basilari ma utili che puoi adottare per migliorare la qualità del codice. Come risultato delle seguenti convenzioni, il codice sorgente sarà uniforme in tutta la base di codice, riducendo lo sforzo cognitivo per la ricerca e la lettura dei file di codice.

2 - Implementare architetture software chiare

La base di codice di un progetto software che non segue un chiaro stile architettonico, qualunque esso sia, si deteriora gradualmente man mano che viene aggiunto un nuovo codice non strutturato, diventando più difficile da modificare. Da qui l'importanza di mettere le ore per la progettazione e la conservazione di un'architettura software adeguata.

3 - Meno è meglio: lingue, cornici e strumenti

Con ogni lingua, quadro e strumento aggiuntivi che introducete nel vostro sistema, si ottiene un ulteriore costo di sviluppo e operativo. Dovresti sempre valutare i costi a lungo termine di una decisione tecnologica prima di farla risolvere un problema a breve termine. Evita le tecnologie ridondanti e sfrutta al massimo lo stack corrente.

4 - Coinvolgi il tuo team nelle decisioni di progettazione del sistema

Il modo più efficace per creare un ambiente di conoscenza condiviso è coinvolgere il team in tutte le decisioni di progettazione del sistema. I vantaggi sono molti:

  • Le persone si sentono apprezzate e fanno parte della squadra
  • Le decisioni importanti sono sfidate da tutto il team prima di essere prese
  • I punti di forza e di debolezza della progettazione del sistema sono compresi in modo più chiaro da tutti
  • Crea un senso di responsabilità collettiva e fiducia

5 - La regola All-in

Ritengo che gli sforzi per riformattare la progettazione di un sistema dovrebbero essere condotti al completamento (all-in), piuttosto che essere parzialmente conclusi. Esiste un grande rischio di erodere la progettazione del sistema se gli sviluppatori si sentono liberi di applicare stili di codifica e modelli architettonici diversi ogni volta che lo ritengono opportuno.

A questo punto, se hai implementato con successo i suggerimenti precedenti, il tuo team molto probabilmente valuterà questo comportamento da sviluppatore canaglia come non professionale e irresponsabile.


Di recente ho scritto un post sul blog su questo argomento, è possibile trovare informazioni dettagliate su questi argomenti qui: https://thomasvilhena.com/2019/11/system-design-coherence

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.