Quali sono alcuni modi per confrontare e confrontare le strategie di architettura del software?

-1

Attualmente sto lavorando a un progetto Android che ho concluso che è necessario eseguire il refactoring per una parte fondamentale dell'esperienza dell'app. Chiamiamo questa parte dell'esperienza "Cerca".

Dall'analisi dei rapporti sui bug, degli strumenti di analisi statici e del codice stesso, la ricerca deve essere prioritaria nel refactoring.

Poiché la ricerca è un componente fondamentale, desidero proporre alla mia attività di ricondurre i principi TDD. Ciò richiederebbe riscrivere la parte di ricerca dell'app per sfruttare il TDD.

Alcuni membri del team hanno chiesto un confronto tra l'architettura del codice esistente e quella che vorrei proporre. In sostanza, vogliono che dimostri che il mio nuovo approccio andrà a beneficio del progetto.

Non ho dovuto approfondire i dettagli su un confronto come questo prima, e non sono sicuro di quale sia il modo migliore per farlo.

Oltre l'analisi statica e solo la modellazione UML, ci sono altri modi per mostrare i vantaggi o gli svantaggi dell'architettura software?

    
posta Ryan Simon 31.05.2017 - 01:51
fonte

1 risposta

2

La prova è troppo lontana. Non sei un ricercatore. Sei una scimmia del codice. Ciò di cui hai bisogno è la loro fiducia.

Puoi ottenerlo attraverso la politica. Una strategia che funziona a volte nonostante il mio odio personale. Puoi ottenerlo attraverso una minima dimostrazione di ciò che questo può ottenere. Puoi ottenerlo entrando di nascosto in qualche fine settimana e scrivendo un codice eroico che lo converte dappertutto prima che sappiano cosa sta succedendo.

Dei tre raccomando la dimostrazione minima. Questo è quello che fa acquistare la squadra. La maggior parte del tuo sforzo qui non riguarderà il codice. Si tratta di cambiare una cultura. Dimostra che sei pronto a difendere queste idee contro gli scettici brutali che odiano apprendere tutto ciò che può accadere tra loro e andare a casa in tempo.

Per quanto personalmente ami fare l'opzione tre, so che non funziona a lungo termine. Anche se hai licenziato tutti e hai portato una nuova troupe che aveva visto solo la base di codice in modalità TDD, avresti comunque incontrato dei problemi con le persone che non si preoccupavano e non capivano.

TDD in realtà non funziona quando è fatto a metà cuore. Devi dare alle persone una ragione per preoccuparsi e crederci. Perché può fallire in modo orribile quando non lo fanno. Dal momento che questa non è una religione significa una buona demo entusiasta.

Devi mostrare loro onestamente i problemi che il TDD può causare. Le insidie e i modi sbagliati di fingere di seguirlo. Fallo e saranno meno propensi a pensare a te come un venditore di olio di serpente.

Uno dei miti è che TDD ti libera di dover progettare. No. TDD impone modifiche architettoniche che possono solo migliorare un design, ma quelle modifiche non dovrebbero essere la fine del design. TDD ti dà dei test che ti lasciano dipingere in un angolo e ti fanno tornare indietro senza intaccare un buco nel muro. Un atteggiamento di progettazione flessibile significa che la base di codice rifletterà la migliore saggezza di oggi. Non ieri.

La triste verità non è tanto quella di allinearti personalmente ai tuoi obiettivi di business. Quello che dovresti mostrare è quanto è più facile reagire al cambio degli obiettivi quando hai dei buoni test.

Questo non è qualcosa che dovresti lasciare che ti vedano lottare. Pratica le trasformazioni e il refactoring che eseguirai. Tratta questo come un colloquio di lavoro. Hai davvero bisogno di essere in forma per questo.

Oppure puoi fare l'opzione quattro. Aggiungi test ogni volta che riesci a introdurli di nascosto e sperare che un giorno qualcuno si preoccupi di mantenerli a parte te. Ho visto questo provato molte volte. Non funziona e gli scettici finiscono per essere più convinti di avere sempre ragione.

    
risposta data 31.05.2017 - 05:46
fonte