Progetta modifiche future o risolve il problema [chiuso]

Troppo spesso quando si tenta di progettare per il futuro, le previsioni sulle esigenze future si rivelano sbagliate. Di solito è meglio refactoring quando si sa come sono cambiate le esigenze rispetto a sovrascrivere il proprio sistema nel primo giorno. Allo stesso tempo, non spararti neanche ai piedi. C'è certamente una via di mezzo, e sapere dove si trova è più arte che scienza.

Per ridurlo a una regola empirica: less is more.

Hai familiarità con Agile? Uno dei grandi principi di Agile è YAGNI . Trovo che sia il modo migliore per affrontare le cose.

"You aren't gonna need it" ...is a principle of extreme programming (XP) that states a programmer should not add functionality until deemed necessary. Ron Jeffries writes, "Always implement things when you actually need them, never when you just foresee that you need them."

...YAGNI is a principle behind the XP practice of "do the simplest thing that could possibly work" (DTSTTCPW). It is meant to be used in combination with several other practices, such as continuous refactoring, continuous automated unit testing and continuous integration. Used without continuous refactoring, it could lead to messy code and massive rework. Continuous refactoring in turn relies on automated unit tests as a safety net (to detect unforeseen bugs) and continuous integration to prevent wider integration problems...

YAGNI is not universally accepted as a valid principle, even in combination with the supporting practices. The need for combining it with the supporting practices, rather than using it standalone, is part of the original definition of XP...

Questa è probabilmente una delle parti più difficili dello sviluppo del software perché è necessario percorrere la linea tra "YAGNI" e "PYIAC" (dipingersi in un angolo).

È piuttosto facile dire "non scrivere una funzione a meno che non ne abbia bisogno". La parte difficile è la progettazione del tuo codice in modo da poter aggiungere facilmente funzionalità in un secondo momento quando ne hai bisogno.

La chiave è di essere in grado di progettare un'architettura estensibile in cui non si scriva più codice di quello che si ha attualmente bisogno. La capacità di farlo bene deriva in realtà da un sacco di esperienza (e dolore).

Trascorro un po 'di tempo in anticipo pensando all'orientamento generale del progetto - non troppo, ma abbastanza per delineare una panoramica di alto livello. Seguo quindi una metodologia agile basata su una storia che utilizza TDD per sviluppare soluzioni per storie individuali. Mentre sto implementando tramite TDD tengo a mente la mia panoramica di alto livello e (a) dirigo le mie particolari implementazioni per seguire la panoramica di alto livello o (b) ridefinire (e migliorare) la mia comprensione / direzione ad alto livello sulla base di cosa imparo durante i test / l'implementazione.

Penso che sia un errore non pianificare in anticipo, ma è probabilmente uno più grande da fare troppo. Per quanto possibile, mi piace lasciarmi guidare guidandomi nella visione d'insieme e poi lasciare che il design cresca organicamente lungo le linee che ho esposto nella mia mente per come si svilupperà l'applicazione. Usando TDD, trovo che il design stesso è costretto a principi di progettazione migliori (disaccoppiati, responsabilità singola, ecc.) Ed è più malleabile rispetto ai cambiamenti che se provassi a pre-concepire il tutto e ad adattarlo allo sviluppo.

Ciò che stai cercando di affrontare ha a che fare con il riutilizzo (cioè la generalizzazione di un problema con cui ti stai occupando ora in modo da poter riutilizzare il lavoro (codice) in futuro). L'ho già detto e link di nuovo.

Penso di aver sentito altre persone dire qualcosa con l'effetto di:

I solve the problem the first time. When I repeat my solution the first time, I note it. When I repeat it again, I refactor.

Un buon design accoglie i cambiamenti futuri e vale sicuramente la pena andare. Si consideri il sistema operativo UNIX e il suo "tutto è una filosofia di file". Questa decisione progettuale è stata presa per non soddisfare alcune necessità immediate ma in vista di requisiti futuri. Un brivido per pensare a come sarebbe un sistema operativo basato su un design "agile".

Design per "ora + 1". Ciò significa, risolvere il problema immediato e costruire funzionalità sufficienti in modo che la prossima volta che chiedono un cambiamento, l'hai già fatto a metà (o più) e hai la possibilità di scegliere a) risolverlo immediatamente e refactoring in seguito, o b) risolvendo "now + 1" di nuovo (con il "now" fatto a metà)

Questo dipende dal progetto e, in breve, l'esperienza ti insegnerà cos'è il "+1".

La filosofia di YAGNI , non ne hai bisogno, può essere riassunto con (dall'articolo):

According to those who advocate the YAGNI approach, the temptation to write code that is not necessary at the moment, but might be in the future, has the following disadvantages:

• The time spent is taken from adding, testing or improving necessary functionality.
• The new features must be debugged, documented, and supported.
• Any new feature imposes constraints on what can be done in the future, so an unnecessary feature now may prevent implementing a necessary feature later.
• Until the feature is actually needed, it is difficult to fully define what it should do and to test it. If the new feature is not properly defined and tested, it may not work right, even if it eventually is needed.
• It leads to code bloat; the software becomes larger and more complicated.
• Unless there are specifications and some kind of revision control, the feature may not be known to programmers who could make use of it.
• Adding the new feature may suggest other new features. If these new features are implemented as well, this may result in a snowball effect towards creeping featurism.

Sono un grande sostenitore della progettazione del problema in questione e non soffiare il tuo progetto cercando di indovinare tutti i casi che devi soddisfare perché "un giorno potremmo averne bisogno".

Fondamentalmente, dato un elenco di requisiti specifici, design contro questo, tuttavia, questo non significa che non dovresti:

• rendere gli aspetti del tuo design configurabili anziché codificare in modo rigido quegli aspetti della soluzione. O tramite i parametri passati in runtime o tramite una lettura di configurazione esterna all'avvio (o dopo HUP'ing).
• allaccia il tuo codice con numeri magici,
• evitare di dare un'occhiata per vedere se c'è qualcosa già scritto che è possibile riutilizzare, magari dopo aver adattato la soluzione esistente per fornire un approccio adatto alla situazione esistente e ai nuovi requisiti.

Il problema principale con la progettazione di "possibili futuri" è che stai sempre solo indovinando. Forse facendo ipotesi plausibili, ma "quando arriva il momento critico" è solo una serie di ipotesi.

In questo modo hai anche la reale possibilità di spremere la tua soluzione per adattarla ai casi generali piuttosto che risolvere il problema specifico in questione come definito dai tuoi requisiti noti.

Che cosa sta dicendo? "Quando tutto ciò che hai è un martello, tutto inizia a sembrare un chiodo".

Vorrei avere una sterlina per ogni volta che ho sentito qualcuno dire "Ma è una soluzione più adattabile per quei casi generali che potremmo vedere in futuro."