««« | »»»
Facile, come bere un bicchier d’acqua
L’ultimo post di Brent Simmons, Anatomy of a feature, è da leggere.
La richiesta
Il punto di partenza è la semplice aggiunta di una nuova feature in NetNewsWire: la possibilità di aggiungere il post che si sta leggendo a Instapaper. Ridotta all’osso, tutta la faccenda si traduce in una chiamata http; una cosa che sa fare anche mia mamma, giusto?
Come le ciliegie…
No, perché ragionando intorno a questa feature scaturiscono tutta una serie di considerazioni su elementi in qualche modo collegati che vanno valutati per il loro rapporto costi/benefici.
Fatto questo, tutte le feature di contorno sopravvissute al processo di selezione vanno implementate, richiedendo molto più tempo della feature principale, quella richiesta dall’utente.
La lista della spesa
Quelle considerate nell’articolo sono:
- supporto per account Instapaper multipli;
- possibilità di aggiornare i dati del proprio account;
- pulsante dedicato nella barra degli strumenti;
- funzionamento offline, sincronizzazione;
- inserimento delle credenziali per l’autenticazione;
- feedback delle azioni;
- supporto per la sottomissione di più pagine contemporaneamente;
I punti 1, 3 e 6 sono quelli che riguardano più da vicino gli aspetti funzionali, ma sono delle migliorie e sono stati scartati, tranne la possibilità di aggiornare il proprio account Instapaper. Il punto 4 è invece indispensabile ed è stato considerato come elemento a sé stante perché non era sufficiente riutilizzare altri pezzi di GUI già disponibili.
Al lavoro
Poi tocca all’implementazione. Trattandosi di codice che lavora in rete la gestione degli errori è più lunga da scrivere del codice vero e proprio; stessa cosa per la GUI delle credenziali; anche il feedback dell’azione si rivela meno semplice del previsto.
Cosa abbiamo imparato?
Certo, non sempre le cose vanno così: a volte la richiesta è veramente facile da soddisfare. Non è neanche possibile fare considerazioni generali sul rapporto fra la quantità di lavoro spesa nelle parti ausiliarie e quella nelle parti fondamentali. Ogni caso fa storia a sé.
Sicuramente, però, possiamo dire che l’interazione con l’utente fa la parte del leone e conferma quello che ho visto anch’io in svariate occasioni. Inoltre, la cosa che mi fa sempre specie è la disparità fra il codice di supporto e quello operativo.
Domande, domande, domande…
Infine, non dimentichiamo che la feature di partenza è molto circoscritta e molto chiara. Quante volte capita di sentirsi fare richieste molto più nebulose? Quanti sono i progetti in cui si può dire di aver visto fare analisi a questo livello di dettaglio lungo tutto il corso del progetto? È anche solo plausibile pensarlo? Quali sarebbero i costi? E quali sono i costi nel non farlo?
Per proseguire
Commenti e trackback sono disabilitati.