Convincere un team di sviluppo a utilizzare un modello di progettazione migliore [chiuso]

Sai, questo:

Convincing a development team to use a better design pattern

È un po 'diverso da questo:

I recently joined a company where I was tasked with building a system for one of their clients. The work I've done is so far working well, but the most senior developer on the team who's been with the company for many years is having trouble understanding my code. He says it's hard to follow.

Nel tuo titolo sembra che tu sia uno di quei ragazzi pieni di apprendimento dei libri, ideali e poca esperienza che incolpa ogni difficoltà con la base di codice esistente sulle idee obsolete dei team.

Nel tuo paragrafo di apertura, tuttavia, stai lavorando a un progetto di campo verde e hai solo problemi con una revisione tra pari.

Queste sono situazioni molto diverse. Le vecchie basi di codice saranno sempre piene di vecchie idee. Quando apportiamo cambiamenti in essi tendiamo a cadere nel loro quadro e perpetuare le vecchie idee. È costoso non farlo. Lavoriamo per modernizzarli, ma in qualche modo qualcosa del passato si blocca sempre. Hanno effetto anche nel modo in cui pensiamo.

Tuttavia, stai lavorando a un nuovo progetto. Nessun vecchio codice per legarti al passato. Il tuo problema non è convincere una squadra a utilizzare un modello di progettazione migliore. Li sta convincendo che possono comprenderne uno che hai usato.

I tried conducting a training session for him and another developer where I explained the design patterns used in this program. The system is written in Ruby on Rails and I used a design pattern called the "Clean Architecture" to better modularize all the functionality. During my presentation, the senior developer scoffed at some of the concepts. He feels that the Clean Architecture introduces a lot of unnecessary complexity because it involves so many layers of abstraction and objects.

Se quello che stai scrivendo è un one-off ha ragione. L'architettura pulita non riduce al minimo la complessità, l'astrazione o il conteggio degli oggetti. Riduce al minimo l'impatto del cambiamento. Questo è prezioso solo quando passi da un pensiero unico a come questa cosa viene mantenuta nel tempo.

The developers on my team don't seem to unit test as thoroughly as I do, and don't see the need to learn a new conceptual framework. However, I've worked at other organizations running large applications that run into scalability problems when using the default problem solving approaches popular in Ruby on Rails. Seeing how those teams solved such problems and made their codebase more maintainable using SOLID and Clean Architecture is why I think it's a great way approach to the program I'm building at my current employer. None of my coworkers at this company had exposure to anything like that yet. Neither of them ever heard of SOLID.

Ciò significa che ciò che stai facendo è quasi pessimo come entrare e programmare in una lingua che nessuno di loro ha mai sentito nominare.

My concern is that the other developers on my team will eventually push back on the design patterns I'm using and try to micromanage my work. Maybe I'm not great at articulating the advantages of the way I code - I just go by what I know works from past experiences. It is especially troubling to me that one of my coworkers finds my code to be "hard". What do you think is the best way of handling this situation?

Sei concentrato su un ragazzo che trova il tuo codice "duro". E gli altri? Siate sempre disposti ad accettare l'idea che, nonostante il seguito di Clean Architecture, il vostro codice possa far schifo. Hai bisogno di qualcuno, oltre a te, per dirti quando è comprensibile. Non nascondersi dietro le differenze ideologiche. Solo dopo aver ottenuto qualcuno che ammette di poter capire il tuo codice, dovresti spingere i tuoi detrattori ideologici.

Il modo di spingerli è di evangelizzare. Non forzarli. Convinci. Se non sei lo zio Bob, non provare a essere zio. Dare presentazioni a senso unico a lungo termine non è come lo farei. Fare domande. Scopri in che cosa credono. Che preoccupazioni hanno. Quali problemi continuano a spuntare. Essere disposti ad ammettere che Clean Architecture non risolva ogni problema. Mostra loro cosa risolve. Mostra loro come reagire a cambiamenti imprevisti. Falli interessare. Quindi puoi spiegare perché non risolvi tutto con un oggetto.

Probabilmente è più adatto per le carriere, ma entrare a far parte di un'azienda e dirle immediatamente di cambiare il modo in cui fanno le cose sarà davvero difficile. È improbabile che qualcuno ti ascolterà fino a quando non ti sarai dimostrato. E questo è per una buona ragione. Cosa succede se non sai di cosa stai parlando? Sanno cosa hanno fatto i lavori. Non sanno di te e del tuo modo.

Quello che suggerirei è di smettere immediatamente di provare a insegnare loro. Mi sembra un po 'condiscendente e arrogante, o almeno è così che probabilmente viene percepito. È improbabile ottenere i risultati desiderati.

Invece, prova a chiedere loro cosa lo farebbero in modo diverso. Consiglio vivamente di andare avanti con quello che suggeriscono, almeno inizialmente. Potresti imparare qualcosa e costruisci un po 'di fiducia. Inizia in piccolo con le tue idee per migliorare le cose. Una volta che hai alcuni sistemi di lavoro sotto la cintura e stabilito un rapporto, avrai una migliore possibilità di prendere in considerazione le tue idee.

Le tue passate esperienze con altre società potrebbero effettivamente dirti cosa funziona per risolvere i problemi che hanno incontrato quelle aziende, ma la società che hai aderito subisce gli stessi problemi e, in caso affermativo, sono abbastanza severi da giustificare qualsiasi i cambiamenti?

Alcune delle pratiche che menzioni sono estremamente preziose per alcuni progetti che hanno molti requisiti complessi, in continua evoluzione, o soffrono molto "dolore" per qualcuno che mantiene il codice, ma questo non significa quelli le pratiche sono appropriate in tutti gli scenari.

Può essere spesso il caso che in progetti software che, forse anche a dispetto delle loro dimensioni, possano effettivamente avere requisiti e componenti che sono in genere semplici e stabili abbastanza da non essere sottoposti a cambiamenti significativi nella loro vita per poter essere un serio vantaggio tangibile nel mettere molto impegno nella manutenzione.

Ad esempio, potresti avere un componente in un sistema che, secondo il giudizio della maggior parte delle persone, potrebbe essere considerato completamente non-manutenibile, pieno di "odori di codice" disgraziati e brutti da leggere; ma se il componente è stato seduto nel suo ambiente di produzione funzionando allegramente senza problemi e nessuno ha cambiato un singolo requisito per il sistema in anni o sollevato qualcosa di più del rarissimo / occasionale difetto, allora a chi importa davvero quanto sia pessimo il codice ?

Senza trarre conclusioni su chi ha ragione o torto, mi sembra che tu non sia stato in compagnia abbastanza a lungo da sapere quali sono i loro veri problemi.

Se vuoi convincere qualcuno ad adottare la tua soluzione, allora deve essere predicata dopo aver identificato per prima cosa uno specifico problema reale (es. punti di dolore, cose ad alto rischio e spesso sbagliate, o sono insopportabilmente difficili / tempo -consuming); quindi puoi spiegare loro qual è il problema e cercare di coinvolgerli in una discussione sui modi per risolverlo - la discussione sul problema in realtà ha bisogno di accadere prima di saltare alla soluzione.

Ricorda che potrebbero esserci altre soluzioni che il tuo team preferirebbe al posto di quello che stai suggerendo, oppure potrebbero semplicemente decidere che il problema non esiste realmente o che esiste, ma è la gravità e l'impatto sul la squadra è bassa e non vale la pena aggiustarla.

Altrimenti (e senza saltare a conclusioni), considera questa posizione più "diabolica avvocato" se vuoi ...) se non riesci a identificare un vero problema tangibile che valga la pena, allora forse la soluzione 'suggerire non è necessario.