Quando rimuovere la complessità?

Introdurre prematuramente la complessità implementando modelli di progettazione prima che siano necessari non è una buona pratica.

Ma se segui tutti (o anche la maggior parte) dei principi SOLID e usi modelli di progettazione comuni, introducerai una certa complessità man mano che le caratteristiche e i requisiti vengono aggiunti o modificati per mantenere il tuo design mantenibile e flessibile, se necessario.

Tuttavia, una volta che la complessità è stata introdotta e funziona come un campione, quando è stata rimossa?

Esempio. Ho una domanda scritta per un cliente. Quando originariamente creato lì dove diversi modi per dare rilanci ai dipendenti. Ho usato il modello strategico e la fabbrica per mantenere l'intero processo bello e pulito. Nel tempo alcuni metodi di aumento sono stati aggiunti o rimossi dal proprietario dell'applicazione.

Il tempo passa e il nuovo proprietario prende il sopravvento. Questo nuovo proprietario ha un naso duro, mantiene tutto semplice e ha un solo modo per rilanciare.

La complessità richiesta dal modello di strategia non è più necessaria. Se dovessi codificarlo dai requisiti così come sono ora, non introdurrei questa complessità aggiuntiva (ma assicurerei di poterlo introdurre con poco o nessun lavoro in caso di necessità).

Quindi rimuovo l'implementazione della strategia ora? Non credo che questo nuovo proprietario cambierà mai il modo in cui vengono dati i rilanci. Ma l'applicazione stessa ha dimostrato che ciò potrebbe accadere.

Naturalmente questo è solo un esempio in un'applicazione in cui un nuovo proprietario prende il controllo e ha semplificato molti processi. Potrei rimuovere decine di classi, interfacce e fabbriche e rendere l'intera applicazione molto più semplice. Si noti che l'implementazione attuale funziona perfettamente e il proprietario ne è contento (e sorpreso e ancora più felice di essere stato in grado di implementare le sue modifiche così rapidamente a causa della complessità discussa).

Ammetto che una piccola parte di questo dubbio è perché è molto probabile che il nuovo proprietario non mi userà più. Non mi interessa davvero che qualcun altro lo prenda in carico poiché non è stato un grande generatore di reddito.

Ma mi importa di 2 cose (correlate)

1. Mi preoccupo un po 'che il nuovo manutentore dovrà pensare un po' di più quando cerca di capire il codice. La complessità è complessità e non voglio far arrabbiare il maniaco psicopatico che mi insegue.

2. Ma ancora di più mi preoccupo per un concorrente che vede questa complessità e pensa di implementare modelli di progettazione per riempire le mie ore di lavoro. Quindi diffondere questa voce per ferire gli altri miei affari. (Ne ho sentito parlare.)

Così...

In generale, la complessità precedentemente necessaria dovrebbe essere rimossa anche se funziona e c'è stata una necessità storicamente dimostrata per la complessità, ma non hai alcuna indicazione che sarà necessaria in futuro?

Anche se alla domanda sopra viene generalmente risposto "no" è saggio rimuovere questa complessità "non necessaria" se si passa il progetto a un concorrente (o straniero)?

In un certo senso, penso che questa sia in gran parte una decisione aziendale e non necessariamente basata sul codice stesso. Alcune cose da considerare:

• Vieni pagato per apportare le modifiche?
• Il codice attualmente funziona come previsto?
• Ci sono problemi di sicurezza o prestazioni con il codice così com'è?
• L'ammontare del debito tecnico supera i costi di riparazione?
• Cosa è realisticamente probabile che accada se lasci il codice così com'è?
• Quali sono i problemi futuri che potrebbero sorgere con o senza refactoring?
• Quanto di una responsabilità è il codice per te e la tua azienda?

Sei nella posizione migliore per rispondere a queste domande. Tuttavia, in base alla tua descrizione, non so se mi preoccuperei di refactoring e semplificare le cose in quanto non sembra che varrà la pena. Se al momento funziona, il cliente è felice e non ti piace essere pagato per l'aggiornamento di tutto, quindi lascia che sia e lavori su un'attività che genera entrate.

In breve, fare un'analisi costi-benefici e una valutazione del rischio di entrambi i percorsi e adottare la linea d'azione più sicura, più efficiente e più redditizia.

Rimuovere questo codice e sostituirlo con qualcosa di semplice per la futura facilità di codifica di una funzione che il cliente deve considerare e pagare?

Potresti avere qualcosa di utile da cui un altro sviluppatore potrebbe imparare, ma è improbabile che ci sia la possibilità di trovare l'app di un altro client per collegarla.

Il pettegolezzo sul codice della concorrenza non è qualcosa che puoi prevenire. Sembreranno sciocchi cercando di reclutare negativamente i clienti.

Un detto comune è: "Se non è rotto, non aggiustarlo".

Ci sono molti razionali dietro questa regola. Alcuni di questi potrebbero essere che la "semplificazione" rischierà di introdurre nuovi, diversi e forse più grandi bug, potrebbe prendere una quantità crescente di tempo di sviluppo lontano da altri sforzi più preziosi e potrebbe essere completamente il cambiamento sbagliato per alcune opportunità commerciali future inaspettate che sorge.

Se esiste un valore aziendale sufficiente affinché questo codice sia portatile e più gestibile, allora decidi se quel valore è davvero sufficiente per considerare "rotto" il codice attuale. Potrebbe anche essere, se è pianificata un'importante espansione aziendale, o se si sospetta un bug latente nascosto nella complessità che potrebbe far fallire l'attività.

Prima di tutto, se l'app era già stata rilevata da un nuovo proprietario, potrebbe succedere di nuovo. E il prossimo proprietario potrebbe ricominciare a usare quella complessità che al momento non beneficia.

A parte questo, modifiche non banali al codice di lavoro comportano sempre un rischio, quindi (come altri hanno notato) il cliente dovrebbe essere d'accordo (e pagare per). Se l'attuale complessità "extra" non causa alcun inconveniente evidente e misurabile (come problemi di prestazioni), non vi è alcun motivo valido per rimuoverlo.

I clienti (potenziali) che (non) ti assumono esclusivamente sulla base delle indiscrezioni dei concorrenti non valgono comunque la pena IMHO, a meno che tu non abbia un disperato bisogno di entrate. Hai buone e logiche ragioni per cui hai implementato l'app nel modo in cui l'hai fatto e ogni cliente serio è in grado di capirlo. Qualcuno che non si preoccupa - o non si preoccupa nemmeno di chiederti - probabilmente ti causerà più problemi lungo il percorso di quanto valga la pena del lavoro comunque.

In generale, la complessità precedentemente necessaria dovrebbe essere rimossa anche se funziona e c'è stata una necessità storicamente dimostrata per la complessità, ma non hai alcuna indicazione che sarà necessaria in futuro?

No.

Anche se alla domanda sopra viene generalmente risposto "no" è saggio rimuovere questa complessità "non necessaria" se si passa il progetto a un concorrente (o straniero)

No. Perché perdere tempo a sistemare le priorità basse funziona in questo modo? Nessun danno per il codice che rimane lì.

Per quanto riguarda la tua domanda: quando rimuovere la complessità?

La mia opinione è che, se non è rotto, non aggiustarlo .

Per poter rimuovere la complessità, deve essere vero quanto segue:

1. Il pezzo rimosso deve essere indipendente dal programma. Se ci sono dipendenze dal programma circostante al codice in questione, la semplice rimozione della complessità non funzionerà
2. Sfortunatamente, se sembra complessità, è molto probabile che i pezzi non siano indipendenti e che le dipendenze interrompano il programma quando si rimuove il pezzo
3. La rimozione di tutte le dipendenze richiederà tempo, quindi è necessario considerare il tempo quando si valuta se l'operazione vale lo sforzo
4. Il più delle volte non vale la pena, ma deciderai semplicemente di non fare in modo che un nuovo codice usi quello vecchio

Penso che ci sia qualcosa di più grande al lavoro qui ... Scalabilità

Quello di cui stai parlando si chiama scalabilità . Non importa se il codice è complesso, importa se l'applicazione può evolversi in base a nuove regole aziendali o regole aziendali modificate. Cosa succede se il prossimo proprietario desidera qualcosa di completamente diverso.

Quindi, dico mantenere il codice e documentarlo. È una caratteristica di come l'applicazione può essere utilizzata.

In generale, la complessità precedentemente necessaria dovrebbe essere rimossa anche se funziona e c'è stata una necessità storicamente dimostrata per la complessità, ma non hai alcuna indicazione che sarà necessaria in futuro?

C'è uno sforzo e un rischio per rimuovere la complessità. Se questo è superiore allo sforzo e al rischio aggiuntivi di mantenere il codice eccessivamente complesso, lo mantieni. Altrimenti, lo rimuovi. È difficile stimare questi rischi, tuttavia.

Vorrei aggiungere che è possibile mitigare il rischio di una manutenzione più difficile documentando perché, in primo luogo, nel modello è stato utilizzato il modello di progettazione Strategia. Personalmente credo che qualsiasi modello di progettazione dovrebbe essere riconducibile a un requisito esplicito (funzionale o non funzionale).

Anche se alla domanda sopra viene generalmente risposto "no" è saggio rimuovere questa complessità "non necessaria" se si passa il progetto a un concorrente (o straniero)?

Il tuo scenario di essere dissecato dalla concorrenza per ore di imbottitura è precisamente il motivo per cui dovresti documentare la complessità. Se documentate e giustificate (con un requisito specifico del cliente) l'uso di qualsiasi modello, allora siete coperti. Se non riesci a giustificare un modello con il requisito di un cliente, allora sembra sovrastampa o patternite.

Se i requisiti cambiano, allora puoi giustificare di lasciarlo a causa del rischio che potresti rompere il codice (o la quantità di lavoro per rimuovere chirurgicamente il modello).

Penso che sia bello distinguere tra complessità accidentale e complessità essenziale , poiché i modelli spesso coinvolgono entrambi.

Cioè, il tuo requisito di supportare vari algoritmi per decidere i rilanci è una complessità essenziale (parte del problema da risolvere). Il mantenimento del codice è reso più semplice dal modello di strategia, ma l'alternativa se / allora codificata alla strategia continuerà a funzionare. Ho svolto esercizi nei miei master in cui gli studenti trovano opportunità di applicare la strategia in progetti open source. La complessità non è necessariamente migliore / peggiore quando si applica la strategia (perché è una complessità essenziale ). A volte potrebbe essere ancora più difficile capire la Strategia, perché il codice è suddiviso in più classi con polimorfismo, piuttosto che un grosso blocco if / then / else.

Idealmente, un modello funziona quando i vantaggi che fornisce superano il costo dei suoi svantaggi. Ancora una volta, quantificare queste cose è difficile. Spesso uno schema rende felice lo sviluppatore (non solo perché semplifica l'aggiunta di una nuova strategia di rilancio, ma gli dà anche confusione allo sviluppatore per sapere che è stato applicato uno schema). È difficile mostrare ai clienti come li sta beneficiando.

Al cliente non importa né capisce nemmeno i dettagli. Nel caso del nuovo proprietario che applica KISS nei suoi processi, è la sua riduzione della complessità essenziale , che dovrebbe avere un impatto anche sulla soluzione software.