Quando la complessità dovrebbe essere rimossa?

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:

• Ti viene pagato per apportare le modifiche?
• Il codice funziona attualmente come previsto?
• Ci sono problemi di sicurezza o di prestazioni con il codice così com'è?
• La quantità di debito tecnico supera il costo di fissarla?
• Che cosa è realisticamente probabile che accada se lasci il codice così com'è?
• Quali sono i problemi futuri che potrebbero emergere con o senza un refactoring?
• Quanto di una responsabilità è il codice per te e la tua attività commerciale?

Sei nella posizione migliore per rispondere a queste domande. Tuttavia, in base alla tua descrizione, non so se mi preoccuperei di refactoring e semplificando le cose in quanto non sembra che valga la pena il tuo tempo. Se funziona attualmente, il cliente è felice e non sei pagato per l'aggiornamento di tutto, quindi lascia che sia e lavori su un'attività che genera profitti.

In breve, fai un'analisi costi-benefici e una valutazione del rischio di entrambi i percorsi e prendi la linea di condotta più sicura, più efficiente e più redditizia.

Non rimuove questo codice e lo sostituisce 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 le probabilità di trovare l'app di un altro cliente per collegarlo, non è probabile.

Fare pettegolezzi sul codice della concorrenza non è qualcosa che puoi prevenire. Sembreranno sciocchi tentando 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à l'introduzione di nuovi, diversi e probabilmente più grandi bug, potrebbe richiedere una quantità di tempo di sviluppo in espansione rispetto ad altre attività più preziose e potrebbe essere completamente il cambiamento sbagliato per alcune inaspettate opportunità di business future che si pone.

Se c'è un valore aziendale sufficiente per rendere questo codice portatile e più gestibile, quindi decidere se quel valore è veramente sufficiente per considerare il codice corrente "danneggiato". Potrebbe essere, se è in programma un'importante espansione aziendale, o si sospetta un bug latente nascosto nella complessità che potrebbe far crollare il business.

Innanzitutto, se l'app è stata già rilevata da un nuovo proprietario, potrebbe accadere di nuovo. E il prossimo proprietario potrebbe ricominciare a utilizzare quella complessità di cui al momento non si beneficia.

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

I potenziali clienti che (non ti assumono) basandoti esclusivamente sulle voci dei concorrenti sono IMHO che non vale la pena avere, a meno che tu non abbia un disperato bisogno di reddito. Hai buone e logiche ragioni per cui hai implementato l'app come hai fatto tu, e qualsiasi cliente serio lo capirà. Qualcuno che non lo fa, o che non si preoccupa nemmeno di chiederti, potrebbe causarti più problemi lungo il percorso che il lavoro vale comunque.

In general should previously needed complexity be removed even though it works and there has been a historically demonstrated need for the complexity but you have no indication that it will be needed in the future?

No.

Even if the question above is generally answered "no" is it wise to remove this "un-needed" complexity if handing off the project to a competitor (or stranger)

No. Perché sprecare il tuo tempo per correggere le priorità basse funziona così? Nessun danno per il codice che rimane lì.

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

La mia opinione è, 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 delle dipendenze dal programma circostante al codice in questione, rimuovere la complessità non funzionerà
2. Purtroppo, se assomiglia alla complessità, è molto probabile che i pezzi non siano indipendenti e le dipendenze romperanno il tuo programma quando rimuovi il pezzo
3. Rimuovere tutte le dipendenze richiederà del tempo, quindi è necessario prendere in considerazione il tempo quando si stima se l'operazione vale lo sforzo
4. La maggior parte delle volte non ne vale la pena, ma decidi semplicemente di non utilizzare alcun nuovo codice per usare quello vecchio

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

Ciò di cui stai parlando si chiama Scalabilità . Indipendentemente dal fatto che il codice sia complesso, è importante che l'applicazione possa evolversi in base alle nuove regole aziendali o alle regole aziendali modificate. Cosa succede se il prossimo proprietario desidera qualcosa di completamente diverso.

Quindi, rispondo mantenendo il codice e documentandolo. È una funzionalità di come l'applicazione può essere utilizzata.

In general should previously needed complexity be removed even though it works and there has been a historically demonstrated need for the complexity but you have no indication that it will be needed in the future?

C'è uno sforzo e un rischio per rimuovere la complessità. Se questo è più alto dello sforzo e del rischio aggiunti di mantenere il codice troppo complesso, allora lo mantieni. Altrimenti, lo rimuovi. È difficile stimare tali rischi, tuttavia.

Aggiungo che puoi mitigare il rischio di una manutenzione più difficile documentando perché hai usato la strategia di progettazione, in primo luogo, nel codice. Personalmente ritengo che qualsiasi modello di design debba essere riconducibile ad un requisito esplicito (funzionale o non funzionale).

Even if the question above is generally answered "no" is it wise to remove this "un-needed" complexity if handing off the project to a competitor (or stranger)?

Il tuo scenario di essere dissentito dalla concorrenza per le ore di padding è proprio il motivo per cui dovresti documentare la complessità. Se si documenta e si giustifica (con uno specifico requisito del cliente) l'uso di qualsiasi modello, allora sei coperto. Se non riesci a giustificare un modello con le esigenze di un cliente, sembra un overdesign o una patternite.

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

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

Cioè, la tua esigenza di supportare algoritmi variabili per decidere i rilanci è una complessità essenziale (parte del problema da risolvere). La manutenzione del tuo codice è facilitata dal modello di strategia, ma l'alternativa if / then hard-coded alla strategia continuerà a funzionare. Ho svolto esercizi nei corsi del mio master in cui gli studenti trovano opportunità per applicare la strategia in progetti open source. La complessità non è necessariamente migliore / peggiore quando si applica la strategia (perché è la complessità essenziale ). A volte potrebbe essere ancora più difficile capire la strategia, perché il codice è suddiviso in più classi con il polimorfismo, piuttosto che un grande blocco if / then / else.

Idealmente, un modello funziona quando i benefici che esso fornisce superano il costo dei suoi svantaggi. Ancora una volta, quantificare queste cose è difficile. Spesso un pattern rende felice lo sviluppatore (non solo perché rende più semplice l'aggiunta di una nuova strategia di aumento, ma dà allo sviluppatore una sfumatura calda per sapere che è stato applicato un pattern). È difficile mostrare ai clienti come ne traggono beneficio.

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