Combattimento (percepito) overengineering vs andare con il flusso [chiuso]

Il mantenimento di un quadro immaginario è una decisione architettonicamente significativa, quindi la domanda si riduce a "come facciamo a sviluppare l'architettura" nella squadra. Devi iniziare con regole decisionali ben definite che sono chiare e condivise da tutti i membri del team perché c'è nessun gioco senza le regole .

Quando ti unisci alla compagnia, una delle domande più importanti che potresti mai porre è:

How does the decision-making process work in the team and how does it evolve over time?

Nessun processo decisionale è peggio del processo decisionale cattivo . se non c'è processo, qualcuno deve definirne uno. Altrimenti, la quantità di sciocchezze aumenta insieme alla quantità di disaccordo con la squadra.

Penso che con questo stiamo chiudendo il ciclo - o hai un'autorità e potere di definire il processo decisionale quando è mancante OPPURE sei d'accordo con il processo corrente / e in che modo si evolve. Scegline uno.

Argomenti costanti e dinamiche di squadra interrotte non ti porteranno mai lontano.

Vorrei provare a capire perché esiste un framework in primo luogo.

Molto probabilmente il motivo è che dovrebbe essere usato successivamente in altri sistemi. Se è così, allora ha senso fare più del necessario in questo momento.

Il motivo è che se un'app è in produzione è in corso una nuova app che richiede aggiornamenti al framework, quindi ogni volta che qualcosa viene modificato nel framework, forse vengono aggiunte le astrazioni che non erano necessarie in precedenza, quindi l'app originale ha per essere aggiornato e testato pure.

È un sacco di refactoring e test per qualcosa in produzione.

Se hai scelto di non includere il framework aggiornato nella vecchia app, allora hai 2 framework per mantenere uno dei quali è già obsoleto.

Anche mantenere il codice obsoleto non è molto buono per il morale.

Se sei nuovo in una squadra, provare a non essere un disturbo nella forza dovrebbe essere la tua prima preoccupazione.

Suppongo che tu non sia nella posizione di capo / architetto e che le decisioni non dipendono da te.

La seconda preoccupazione è Apprendi . Imparare molto. Scopri perché hanno preso le decisioni che hanno preso, perché è stato creato il framework, qual è la ragione dietro a ciò. Quando hai tutte le informazioni, puoi prendere una decisione informata su come affrontare i possibili problemi, come la sovrastruttura e le cattive comunicazioni.

Fai domande, in modo educato . Mettiti nella posizione di uno studente e non di un maestro. Sarà più facile per le persone "insegnarti" perché hanno fatto le cose in questo modo.

In questo momento sei l'emarginato. Ti unisci a una squadra straniera e dovresti imparare i loro costumi e adattarti.

Se fai il tuo lavoro nel modo giusto, con un approccio educato alle persone, le persone ti ascolteranno naturalmente nel tempo. E poi, se hai assolutamente ragione che il tuo approccio è il migliore nel suo insieme, puoi influenzare le persone a cambiare.

Non conosco praticamente nessuno a cui piace lavorare con una persona che spesso critica, ma non crea valore. Sii un riferimento alla tua squadra, qualcuno con cui è orgoglioso di lavorare.

Inoltre, la lettura consigliata: link

Ci sono 2 cose fondamentali che penso stiano accadendo. Il primo è culturale. Sei nuovo nel team e non hai ancora capito come lavorare con questo team. Probabilmente hanno politiche e pratiche diverse che potrebbero effettivamente funzionare per loro. Anche uno o più di essi potrebbero aver richiesto la tua posizione e quindi potrebbero sabotare attivamente i tuoi sforzi o semplicemente non dirti ciò che devi sapere.

Il secondo è che probabilmente hai interpretato male il progetto. La parte che pensi sia un codice morto potrebbe in realtà essere una generalizzazione di altre parti del progetto o potrebbe funzionare per supportare qualcosa che l'azienda vuole eventualmente supportare. Potrebbe essere in realtà un codice morto. Smettila di ossessionarti e capisci perché è lì. In realtà potrebbero volerci mesi per capirlo.

Nelle industrie avverse al rischio (vale a dire, bancario, mediale ...) dove c'è la minima possibilità che un pezzo di codice possa essere usato, quel pezzo di codice rimarrà per decenni.

Per evidenziare questo, una delle strutture di database estranee che ho visto si concentrava attorno a 6 tabelle. 3 di loro stavano mappando tabelle che collegavano le altre tre. Non aveva alcun senso, dal momento che il codice indicava che solo uno era usato come rapporto molti-a-molti e gli altri due stavano implementando uno-a-molti. I progettisti originali di questo erano usciti e nessuno poteva spiegare esattamente come o perché funzionasse. Alla fine, mi sono imbattuto in un documento commerciale che spiegava il design, quindi la mia ipotesi era che l'azienda lo avesse richiesto e qualche DBA appena implementato in un modo che l'azienda potesse capire, nonostante i suoi ovvi limiti. 30 anni dopo è ancora lì, guadagnando i soldi dell'azienda - ma da un punto di vista dello sviluppo difficile da capire, mantenere e sviluppare con.

Vedo alcuni punti positivi su come avere un tale pezzo fuori dall'applicazione anche se nessun altro lo usa.

Ciò può imporre lo sviluppo di funzionalità tecniche nel framework con i loro test appropriati al di fuori del contesto funzionale dell'applicazione (e sulla propria tabella di marcia).

Inoltre, potrebbe essere possibile che tu non voglia che ogni sviluppatore tocchi quella struttura, ma solo quelli più anziani, quindi di nuovo portarla fuori dall'applicazione è un vantaggio.

Per i livelli di astrazione non necessari, beh se sono già lì, non modificare qualcosa che sta già funzionando.

Tuttavia potresti ricordare al tuo team per il futuro che l'obiettivo del framework è quello di alleggerire il tuo lavoro, senza appesantirlo.

Leggendo tra le righe, mi sto appoggiando ai membri del tuo co-team. Realizzare qualcosa "più complicato del necessario" non solo spiana la strada a possibili funzionalità future che potrebbero non essere mai necessarie, ma serve anche la comprensione da parte degli sviluppatori dell'applicazione, incorpora un modello nel software, documenta un'idea.

E così facendo limita il modo in cui gli sviluppi futuri potrebbero andare. Mantiene gli sviluppatori che non riescono a cogliere completamente il progetto / l'intento.

Un nuovo sviluppatore può inizialmente essere infastidito dal design "inutilmente complicato", ma lo guida anche nella giusta direzione, lo fa cadere nella fossa del successo e rende più difficile per lui "fare le cose a modo suo ", che sarebbe solo un altro modo per complicare davvero le cose perché porterebbe a diversi approcci nella stessa applicazione, il che rende ancora più difficile per il prossimo ragazzo riuscire a capirlo.

YAGNI non significa (o non dovrebbe) significa "puoi saltare il disegno" o "fallo veloce e sporco". Se la tua squadra ha il lusso di pensare le cose, direi che è qualcosa da amare piuttosto che combattere.