Come "Non hai bisogno di farlo" e "Adesso è meglio che mai" giocare insieme?

Cerco anche di pensare molto in anticipo, ma di solito non in codice. Io faccio brainstorming e prendo appunti, sperando di organizzare le cose abbastanza bene in modo che possa riferirmi a loro.

Mi chino più verso "non ne avrai bisogno" rispetto al codice, ma "ora è meglio che mai" con il design.

Quando si inizia a costruire un nuovo sistema, si è tentati di voler costruire tutto adesso, ma può anche indebolire il tuo slancio e il tuo morale. Tendo a pensare al design generale e cerco di tracciare una linea diretta attraverso di esso - creare un'architettura scheletrica end-to-end e costruirla per prima, applicando i principi del sound design in modo che io possa in seguito evolvere e refactoring per portare in nuove funzionalità.

Costruisci la più semplice rappresentazione end-to-end del sistema che può funzionare; fallo prima e poi hai qualcosa su cui riflettere. Ciò tende a contribuire a cristallizzare tutte quelle vaghe domande "che cosa succederebbe se" e ti aiuta a individuare ciò che devi costruire successivamente.

YAGNI significa che le cose vengono fatte quando hanno bisogno di essere fatte e non prima. Ciò non significa che mai venga eseguito, a meno che non siano mai necessari. Significa che fai solo ciò che dà al cliente valore commerciale immediato . Quale valore commerciale immediato significa è soggettivo per ogni cliente e ogni progetto.

In entrambi i casi, non puoi perdere nulla con YAGNI.

Nell'altro caso, perdi tempo scrivendo codice che non viene mai usato, e scrivendo test per codice che non viene mai utilizzato, e scrivendo documentazione per codice che non viene mai usato, e manutenzione su codice che non viene mai usato, la gente si chiede cosa questo codice funziona e, se mai viene usato, fino alla nausea.

Esempio

Se sto lavorando su un prototipo / proof of concept o su una 1.0 versione di un'applicazione, non ho bisogno di un design per scalare fino al livello di Facebook. Inferno Non ho bisogno di un design per adattarsi al livello di Facebook, finché non comincio a vedere che ho quel tipo di traffico.

Pensi che Zuckerberg abbia progettato la primissima versione di Facebook per scalare fino a 500 milioni di utenti? No, l'ha progettato e costruito per fare solo ciò che voleva e non più. Se avesse tentato di far cadere il progetto per 500 milioni di utenti dal primo giorno, probabilmente Facebook non sarebbe mai stato rilasciato.

Il modo pratico di fare le cose è come l'ha fatto. Ha iniziato con PHP e MySQL e, ridisegnato e riscritto in base alle esigenze, in base al valore aziendale , il ridimensionamento a milioni di utenti era un enorme valore aziendale, ma non al giorno 0. Al giorno 0 si lanciava qualcosa era il valore aziendale tremendo.

Ha pianificato su riprogettazione e riscrittura. Che è una mentalità diversa dalla pianificazione per il lavello della cucina e mai in realtà lo sviluppo o la consegna di qualcosa di utile che è completo.

Pianificare alla fine della vita per una base di codice, e riscrive è Agile e prova futura. Cercare di raggiungere un obiettivo indefinito di "flessibile" finisce sempre con il fallimento. Stai progettando senza alcuna necessità e perdendo tempo potresti sviluppare ciò che è valore aziendale invece di sognare sognando funzionalità che non saranno mai utilizzate.

Il modo Zen of Python dice:

Now is better than never. Although never is often better than right now.

L'idea è che non è perché puoi definire qualcosa ora che dovresti. Ne hai bisogno ora?

• Sì: fallo ora!
• No: non farlo! Aspetta il bisogno! YAGNI!

I casi in cui questo è meno ovvio è nei casi di refactoring. Dovrei applicare ASCIUGAMANO ogni volta che posso? La risposta non è chiara perché ci sono momenti in cui l'applicazione di DRY costa di più (nel tempo speso) rispetto alla duplicazione. Tuttavia, a lungo termine, l'applicazione di DRY fino a quando non ci sono motivi tecnici / prestazionali per non è sempre buona.

Quindi, YAGNI finché non lo fai, quindi FALLA ORA. Non aspettare!

Non penso che giochino insieme. Penso che tu ti appoggi in un modo o nell'altro. E mi chino verso YAGNI.

Ma per quello che vale, non sono d'accordo con la seconda proposta, che "Ora è meglio che mai". Se un requisito è importante, allora dovrà essere fatto. Quindi "mai" non è una possibilità. Se non è importante, allora "adesso" non è migliore - "mai" è meglio.

Solo i miei due centesimi.

How do these two patterns square up?

Sono ortogonali e non hanno nulla a che fare l'uno con l'altro.

What practices do you use to ensure that they play nice?

Um. Li fai entrambi? Cos'altro ci può essere?

How do you teach them together without creating confusion?

YAGNI descrive le funzionalità viste dagli utenti. Non hai bisogno di fantasia.

Ora è meglio che mai descrive il processo. Scrivi i test ora. Scrivi il codice ora. Non passare le ore a contemplare alternative di design. Costruisci qualcosa piuttosto che parlare di costruire qualcosa.

La soluzione più semplice che ho trovato è quella di aspettarsi dei cambiamenti quando si scrive codice in anticipo. Quando passo il bool ad una funzione, di solito lo cambio appena possibile a una flag / enumerazione quindi è a) più leggibile eb) facile da estendere. Simile, se noto che sto passando un sacco di parametri intorno a dove odora come se avessi bisogno di uno di più, in genere creo una struttura speciale. La speranza è che YAGNI lo sia, ma se lo farai a un certo punto, non romperà tutti gli utenti orribilmente subito e il "lavoro da grugnito" è già stato fatto. Spesso, puoi anche aggiungere alcuni commenti come / * le aggiunte future vanno qui * / o così è chiaro che non è ancora implementato, ma qui è il posto dove aggiungerlo. Questo di solito aiuta di più, poiché ho trovato che il refactoring dell'interfaccia in seguito richiede molto tempo.

Pensa alle future estensioni, ma non implementare quelle estensioni finché non ne hai bisogno.

L'esempio che ti viene in mente è quando Netflix è partito per la prima volta, puoi avere solo una coda associata a ciascun account. In seguito hanno hackerato il supporto per più code. Poiché non è stato progettato in questo modo fin dall'inizio, è diventato sempre più difficile da mantenere, quindi hanno deciso di interrompere tale funzione. Dopo un crollo del cliente, hanno morso il proiettile e hanno fatto una riprogettazione per integrare correttamente più code.

Se qualcuno all'inizio avesse ammesso la possibilità che volessero più code in un secondo momento, avrebbe potuto risparmiarsi un sacco di dolore a lungo termine per pochissimi sforzi aggiuntivi a breve termine. Non dovevano effettivamente implementare più code subito, ma assicurati che se lo facessero non richiederebbero una riscrittura massiccia o un hack non gestibile.

In apparenza, sembra che richiederebbe una capacità simile a quella di un chiromante per prevedere le esigenze future, ma in pratica cose del genere tendono ad attirare un buon programmatore quando nota che sta codificando qualcosa, o che una tabella di database raccoglie un sacco di sole colonne vagamente correlate.