Principio YAGNI messo in pratica

Codice hard e refactor quando ne hai bisogno. Il tempo è denaro, yadda-yadda, vale la pena / tempo per avere la funzione inutilizzata?

Inoltre, non è difficile farlo in seguito tanto quanto è noioso. Assegna questo incarico a uno sviluppatore junior quando se ne presenta la necessità.

Infine, quando sarà il momento, alcuni strumenti automatici potrebbero farti arrivare quasi tutto lì. Come l'estensimetro a stringa di Eclipse.

Rendere le applicazioni multi-lingua richiede un ulteriore sforzo di sviluppo. Puoi investire questo sforzo sin dall'inizio, ogni giorno un po '. Oppure puoi investire questo sforzo in seguito, quando hai scritto > 100K linee di codice. Fatto è, la somma degli sforzi necessari in entrambi i casi non è molto diversa come si potrebbe pensare.

Il primo approccio nasconde effettivamente lo sforzo necessario che fa credere a qualcuno che il secondo approccio sia più costoso, ma IMHO è un equivoco. Il secondo approccio mostra in realtà i costi reali e li rende molto più trasparenti. E questo è il principio del YAGNI: salvare quei costi nascosti nel momento in cui non sei pronto per investirlo.

Detto questo, fornire le applicazioni per il supporto multi-lingua fin dall'inizio potrebbe essere la decisione giusta strategica per molti prodotti software, specialmente quando ci sono buone possibilità di vendere quelle applicazioni a un più ampio pubblico. Ma non bisogna credere che una tale decisione venga totalmente gratis.

YAGNI è spesso in contrasto con altri principi e / o migliori pratiche stabiliti. Altri esempi includono molti dei principi SOLID, che sono in gran parte sulla strutturazione del codice per rendere più facile certi tipi di cambiamento in futuro. Ma cosa succede se non hai mai bisogno di apportare tali modifiche? Quindi il lavoro extra coinvolto, per esempio, invertendo le dipendenze tra due diverse parti della tua applicazione, e la complessità extra introdotta dalle astrazioni non necessarie che tale inversione richiede, è sprecato.

YAGNI non significa che non dovremmo mai fare cose del genere. Significa che dovremmo smettere di pensare prima di farlo e fare una valutazione seria di quanto impegno stiamo per mettere in atto, di quanto sia probabile che si ripaghi e quanto sia più facile ora che dopo.

Nel tuo esempio di esternalizzazione delle stringhe, la quantità di sforzo è piccola, ma non è nemmeno più difficile farlo in seguito, come suggerito da Doc Brown. E tu sei l'unico che sa quanto è probabile che avrai bisogno del supporto per i18n in futuro.

Personalmente, sono propenso a lasciare questo particolare compito fino a quando non è necessario, ma la mia esperienza è in gran parte nella creazione di app interne per le PMI che raramente necessitano della funzione, e lavoro con strumenti che supportano il refactoring automatico ad un esterno risorsa stringa. Il tuo mercato e i tuoi strumenti potrebbero essere diversi, il che potrebbe portare a una decisione diversa.

Con poche eccezioni, il codice, i dati e la configurazione dovrebbero essere separati. L'hard-coding è generalmente considerato una cattiva pratica. Dovresti mettere il testo dell'interfaccia utente in un file separato solo per sapere dove trovarlo, non perché potresti aver bisogno di i18n. Ciò non richiederà molto più tempo rispetto alla codifica hard, ma la manutenibilità sarà migliore.

Anche con file di risorse esterne potrai modificare il testo senza ricostruire / ridistribuire un'app. Questo potrebbe essere il caso delle app Web, ad esempio.

Quindi, questo non sta violando YAGNI, ma solo seguendo altri principi / pratiche.