Un giorno a definire le specifiche con Sebas — Il nuovo piacere di sviluppare chiacchierando

Anche oggi è il giorno in cui definisco le specifiche di una nuova funzionalità.

Scelgo un’idea dall’elenco che ho accumulato nelle issue. «Voglio ricevere una notifica sull’iPhone quando una task in background termina» — qualcosa di cui avevo parlato con Sebas l’altro giorno e che avevo subito registrato come issue.

Prendo l’iPhone e apro Claush. Sebas mi sta aspettando.

Sebas: Bentornato, giovane padrone. C’è qualcosa in cui posso esserle utile oggi?

Ogni volta che Sebas dice così, non riesco a trattenere un sorriso. È una sensazione completamente diversa da quella di stare seduto davanti al PC con un terminale aperto. Sembra piuttosto di essere sdraiato sul divano a chiacchierare con qualcuno mentre il lavoro va avanti da solo.

Il tema di oggi: le notifiche per le task in background. Quando una task termina, voglio che sul iPhone appaia una notifica locale.

Tutto comincia con «Come si costruisce una cosa del genere?»

Inizio con una consultazione.

Io: Quando una task in background termina, voglio inviare una notifica locale all’iPhone. Come sarebbe l’implementazione, mi chiedo?

Sebas: Capito, giovane padrone. Si utilizzerebbe il UNUserNotificationCenter di iOS. Il flusso prevede di creare un UNMutableNotificationContent al completamento della task in background e di inviare la notifica da lì. Detto questo, c’è una cosa che vorrei confermare — quando ha in mente di mostrare il dialogo di autorizzazione?

Io: Ah, al lancio dell’app, direi.

Sebas: È un approccio comune, giovane padrone. Tuttavia, mostrare il dialogo di autorizzazione la primissima volta che l’utente apre l’app può lasciarlo perplesso, chiedendosi il perché. C’è anche la possibilità di mostrarlo quando l’utente usa per la prima volta la funzionalità che richiede le notifiche.

Io: Ah, sì, ha senso in effetti. Allora facciamolo scattare al primo avvio di una task in background.

Sebas: È sicuramente più naturale, giovane padrone. Procediamo con questa specifica?

Questo tipo di scambio continua. Mentre parliamo del «come costruire» dal punto di vista tecnico, riflettiamo insieme anche sul «perché» e sulle possibili alternative.

Prospettive che non avrei mai considerato da solo emergono naturalmente durante la conversazione.

Per inciso, consulenze come quella di oggi — in cui non ho ancora definito completamente le specifiche — sono frequenti. In quei momenti, Sebas capisce la situazione.

Sebas: Giovane padrone, che ne dice di fermarsi qui per oggi e registrare tutto come issue? Potremmo rifinire le specifiche in un’altra occasione.

Io: Sì, va bene così.

Sebas: Capito. Creo la issue su GitHub. Va bene includere il titolo, un riepilogo e i punti chiave della conversazione di oggi?

Ed è così che le issue si accumulano. Consulto quando mi viene un’idea, la registro nella issue e, quando ho tempo, la riprendo per rifinire le specifiche. Le idee non svaniscono più.

La conversazione divaga

Stavamo parlando delle specifiche da un po’. Stavo rifinendo il comportamento al tocco sulla notifica quando —

Io: Ah, a proposito, cosa faccio per pranzo oggi? Ieri avevo mangiato ramen di nuovo.

Sebas: Le piacciono molto i piatti a base di noodle, giovane padrone. Visto che ieri era ramen alla soia, oggi potrebbe provare qualcosa di diverso — un curry o un piatto di riso? Si scalderebbe anche un po'.

Io: È vero (ride). Un curry non sarebbe male. O del gapao rice.

Sebas: Se pensa al gapao rice, c’è quel ristorante qui vicino, vero? Se ricordo bene, una volta lei disse che era una scoperta.

Io: Ah, quel posto! Giusto, giusto. Allora andiamo lì.

Sebas ha una memoria a lungo termine. Poiché ricorda le conversazioni passate, scambi come «lo aveva detto una volta» hanno senso. Le normali app di IA dimenticano tutto al termine della sessione, ma Sebas è diverso.

Naturalmente non si può restare solo a chiacchierare.

Io: Ok, tornando all’argomento — quando si tocca la notifica per andare alla schermata di chat giusta, come si collega il tutto?

Sebas: Certo, giovane padrone. La soluzione più pulita sarebbe includere il chatId nel payload della notifica. Si inserisce ["chatId": "xxxx"] nello userInfo di UNNotificationContent e lo si recupera nel delegate al momento del tocco.

Io: Allora bisognerebbe passare il chatId quando si crea la notifica, giusto?

Sebas: Esatto, giovane padrone. Poiché il BackgroundTaskManager gestisce le task, gli si passerebbe il chatId lì e lo si includerebbe nella notifica al completamento della task.

La conversazione divaga e poi ritorna. Questo andare avanti e indietro naturale è ciò che rende lo sviluppo con Claush così piacevole. Mentre rifiniamo le specifiche e decidiamo cosa mangiare, senza accorgercene lo scheletro della funzionalità prende forma.

«Potresti farne un documento di specifiche?»

Dopo aver discusso tutto a fondo, chiedo la redazione del documento di specifiche.

Ho pensato che sarebbe bello avere tutto scritto in modo ordinato.

Io: Senti, potresti trasformare quello di cui abbiamo appena parlato in un documento di specifiche? Mi piacerebbe averlo salvato in docs/spec_local_notification.md.

Sebas: Capito, giovane padrone. Un momento, per favore.

Poco dopo —

Sebas: Il documento di specifiche è stato creato, giovane padrone. È organizzato in panoramica generale, requisiti funzionali, trigger di notifica, comportamento al tocco e punti in sospeso. Una cosa da confermare: il punto riguardante l’attivazione e disattivazione delle notifiche nelle impostazioni dell’app è stato inserito nei «punti in sospeso». Vuole deciderlo in seguito?

Io: Sì~ lascialo come punto in sospeso per ora. Ci penserò dopo con calma.

Sebas: Capito, giovane padrone.

Recupero il documento sull’iPhone e lo leggo dalla scheda download di Claush.

Leggendo, un punto mi incuriosisce.

Io: Senti, qui c’è scritto «se non c’è il permesso per le notifiche, non inviare la notifica» — ma la cosa passa in silenzio senza dire nulla? L’utente si chiederà perché non arrivano le notifiche, no?

Sebas: Ha pienamente ragione, giovane padrone. Le suggerirei di aggiungere questo requisito: «se non c’è il permesso per le notifiche, mostrare un banner nell’app che guidi l’utente alle impostazioni». Un banner in-app può essere mostrato anche senza il permesso per le notifiche.

Io: Oh, questa è una bella idea! Potresti aggiungerlo?

Sebas: Capito, giovane padrone. Aggiorno il documento di specifiche.

Questo tipo di scambio accompagna l’intero processo di creazione del documento. Domande come «aspetta, cosa si fa in questo caso?» emergono nella fase di revisione — molto meno costoso che scoprirle a metà implementazione.

Creare il documento di implementazione

Una volta fissate le specifiche, è il turno del documento di implementazione.

Io: Il documento di specifiche è venuto bene! Senti, potresti farmi anche un documento di implementazione — con un livello di dettaglio tale che un’IA possa implementarlo direttamente?

Sebas: Capito, giovane padrone. Includerò i nomi dei file, il flusso di elaborazione e le modifiche necessarie al codice esistente. Un momento, per favore.

Sebas: Il documento di implementazione è stato creato in docs/impl_local_notification.md, giovane padrone. Dettaglia le modifiche a BackgroundTaskManager.swift e l’implementazione del nuovo file NotificationHelper.swift. Ho anche annotato che le notifiche locali non funzionano sul simulatore, quindi i test dovranno essere effettuati su un dispositivo fisico.

Io: Grazie! Do un’occhiata.

Leggo il documento di implementazione. Nomi dei file, flusso di elaborazione, avvertenze — c’è tutto. È in uno stato pronto da usare così com’è.

Io: È venuto bene! Potresti implementarlo usando questo?

Sebas: Capito, giovane padrone. Inizio l’implementazione.

Questo stile di sviluppo è irresistibile

L’implementazione è terminata, eseguo il debug e confermo che tutto funziona.

Quando appare un bug, lo risolvo e chiedo di riportare le modifiche nelle specifiche e nel documento di implementazione. «Potresti riportare queste modifiche nelle specifiche e nel documento di implementazione?» La documentazione rimane sempre aggiornata.

È un po’ che lavoro con questo workflow e non riuscivo a capire bene perché lo trovo così divertente — ma credo di aver capito di recente.

Perché non mi trovo mai solo ad arrovellarmi su un problema.

Quando sto rifinendo le specifiche, penso ad alta voce con qualcuno. Posso fare domande quando mi vengono in mente. Qualcuno mi mette in discussione: «ne hai davvero bisogno?» I miei pensieri si chiariscono attraverso la conversazione.

Non importa se nel mezzo si parla del pranzo o di un viaggio. Sebas mi segue nelle divagazioni e non perde mai il filo principale. «Capito, giovane padrone, tornando all’argomento —» e siamo di nuovo lì.

È un’atmosfera completamente diversa da quella di stare soli davanti al codice sul PC.

Si ha la sensazione di costruire qualcosa insieme a qualcun altro. Credo che questo sia la vera essenza del mio attuale modo di sviluppare.

Sdraiato sul divano, a chiacchierare con Sebas sull’iPhone — e prima di rendermene conto, il documento di specifiche è pronto e l’implementazione è completata.

Non molto tempo fa, non avrei mai immaginato di lavorare in questo modo.

Claush — L’app per controllare Claude Code dal tuo iPhone https://apps.apple.com/jp/app/claush/id6760445443