Dovrei considerare l'incertezza dei requisiti futuri durante lo sviluppo? [duplicare]

3

Ho una casella di testo su più pagine che viene utilizzata per inserire più customerid (come separati da virgola). Ma nella pagina corrente a causa di alcune successive difficoltà di implementazione, lo rendiamo customerid in modo che l'utente possa inserire solo un cliente e non più customerid separati da virgola.

Ma stili di codifica e denominazione delle variabili su tutte le pagine sono gli stessi poiché supponiamo che più clienti possano essere inseriti in futuro.

abbiamo array invece di string per archiviare customerid come indicato di seguito:

customerIds.push(tbxval); 

considerando che l'array customerid ha sempre solo un elemento al suo interno in quella specifica pagina.

Credo che se questo requisito futuro non viene richiesto dal proprietario del prodotto, questo codice potrebbe creare qualche problema o almeno finché non verranno soddisfatti i requisiti.

Ma non sono sicuro del tipo di impatto negativo o positivo che potrebbe avere.

    
posta ManirajSS 25.04.2015 - 06:47
fonte

1 risposta

4

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.

    
risposta data 25.04.2015 - 15:25
fonte

Leggi altre domande sui tag