Not all of the developers on the project have the domain knowledge to make these decisions well
Se alcuni sviluppatori non hanno una profonda comprensione dello scopo del sistema o dei requisiti del cliente (conoscenza del dominio del cliente), impiegheranno più tempo per scrivere e il codice scritto richiederà più test e < strong> più rilavorazione . Questo è il tipico approccio sperimentale all'errore ed è sia un costo sia un investimento .
Se alcuni sviluppatori non progettano bene l'architettura , quindi delegano il lavoro di progettazione a un architetto migliore. Ad esempio, per progettare bene ci vuole molto di più della conoscenza del dominio, ad es. la saggezza dell'architettura, per la quale alcuni programmatori fanno meglio di altri e che non cresce linearmente con l'esperienza. Ci sono due modi in cui questo può funzionare:
- L'architetto può specificare CRC e i metodi di interfaccia e consentire ad altri sviluppatori di implementare i dettagli .
- L'architetto può entrare dopo il fatto e supervisionare il refactoring del progetto mentre il codice / specifiche / test era già stato stabilizzato.
Se vuoi che l'architettura del software si abbini bene con lo scopo, beh ... cambia team o cambia azienda. DDD di solito hanno una norma "i non esperti non devono applicare".
Typically, the person writing the
specification/test is not the
developer who will write the
implementation and make the
specification/test pass.
Se una specifica / test è troppo generica / vaga / enorme per gli sviluppatori da implementare ... suddividili in specifiche / test più piccoli.
Do I solve this problem (the
specification/test) with an existing
object(s), or do I create (for the
first time) the dependencies which
will allow the system to pass this
specification/test?
Nella tua situazione, suggerisco abbracciare la rilavorazione . A volte la risposta alla domanda di creazione / riutilizzo non è ovvia. Chiedi a un architetto quando disponibile. In caso contrario, lancia una moneta.
... we're colliding so far as disparate
designs and objects created in
relative isolation begin to conflict
and duplicate each other.
Ecco un approccio che ha funzionato per me in un progetto più piccolo . Probabilmente non è scalabile per progetti più grandi.
Ogni membro del team inizia una giornata di lavoro leggendo tutte di ogni modifiche al codice di altri membri del team.
(Questo è adatto per le impostazioni di "tutti in una grande stanza gigante condivisa con altre squadre" in quanto può essere fatto in assoluto silenzio. È adatto anche per i team dispersi geograficamente in quanto non occupa tempo di affrontare. che hanno uffici dedicati potrebbero trovare la programmazione di coppie più adatta.)
(Lo sforzo è gestibile fino a 10 sorgenti di commit al giorno o 500 linee di cambiamento.)