Se interpretiamo questa domanda nel suo senso più generale, la domanda duplicata proposta è forse la migliore risposta che potresti mai ottenere:
Too often when you try to design for the future, your predictions
about future needs turn out to be wrong. It's usually better to
refactor when you actually know how the needs have changed than to
overdesign your system on day one. At the same time, don't shoot
yourself in the foot, either. There's certainly a middle ground, and
knowing where that is is more art than science.
To boil it down to one rule of thumb: less is more.
Ma possiamo espanderci un po '. C'è una grande differenza tra il tentativo di predire il futuro e la conoscenza del futuro.
È importante che gli sviluppatori siano consapevoli della visione a lungo termine del prodotto, perché una volta ogni tanto sai davvero per certo che dovrai fare X ad un certo punto in il futuro. Ad esempio, so che la nostra applicazione dovrà supportare i temi dei colori un giorno, quindi cerco di evitare il più possibile il riferimento ai valori cromatici predefiniti correnti. Ma non ho scritto alcun codice per cambiare i colori di default, perché non ne avremo bisogno per un tempo molto lungo, e non ho idea di come esattamente vorremmo che funzionasse. Sapevamo fin dall'inizio che la nostra applicazione necessitava di internazionalizzazione, quindi (per lo più) tenevamo le stringhe rivolte all'utente e le stringhe "code-only" chiaramente separate dal primo giorno, anche quando non avevamo un sistema per tradurre l'utente- di fronte a quelli ancora.
Nel tuo esempio, non è chiaro se avere a che fare con un array invece di un singolo numero comporti la scrittura di un codice aggiuntivo non ancora necessario, o solo leggermente diversi codice. Inoltre, non è chiaro se conosci ti servirà in futuro o se stai solo indovinando. Solo tu e il tuo product manager puoi rispondere. Se le probabilità sono alte, avrai bisogno di array e utilizzare gli array non renderà il codice molto più complicato in questo momento, quindi è probabilmente una buona idea iniziare a utilizzare gli array in anticipo.
L'unica volta che potrebbe valere la pena di cercare di prevedere il futuro e di essere più generici del necessario è quando si progetta un'API, uno schema o un formato di file che deve essere retrocompatibile . Ad esempio, se si dispone di un'API del servizio Web con un metodo getPublicUserStats (), l'accettazione di un singolo ID utente invece di una matrice è inutilmente restrittiva, anche se al momento è necessaria solo una alla volta. Ma non dovresti fare di tutto per ottimizzare le richieste con migliaia di ID utente finché non si verifica effettivamente un problema di prestazioni.