In che modo giocano insieme "Non ne avrai bisogno" e "Adesso è meglio che mai"?

Mi trovo spesso ad abbracciare "ora è meglio che mai" quando avanza nella DEUMIDITÀ di un disegno. In genere, trovo che ho bisogno di coltivare una comprensione della Posizione unica autorevole per un pezzo di conoscenza nel contesto di un sistema di altri pezzi di conoscenza. Pertanto, tendo a progettare il sistema "adesso".

Al contrario, questa pratica mi fa costruire abbastanza in anticipo, nonostante una ragionevole possibilità che non ne avrò bisogno.

Come si quadrano questi due schemi?

Quali pratiche usi per assicurarti che suonino bene?

Come li insegni insieme senza creare confusione?

Cerco di pensare anche molto avanti, ma di solito non nel codice. Ho un brainstorming e prendo appunti, spero di organizzare le cose abbastanza bene da poterle fare riferimento.

Mi rivolgo maggiormente a "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 ora, ma può anche sottrarre slancio e morale. Tendo a pensare al design complessivo e cerco di tracciare una linea diretta attraverso di esso - inventare un'architettura scheletrica end-to-end e costruirla prima, applicando solidi principi di design in modo da poterlo successivamente evolvere e rifattorizzare per portare in nuove funzionalità.

Costruisci la rappresentazione end-to-end più semplice del sistema che può funzionare; fallo prima e poi hai qualcosa su cui riflettere. Ciò tende ad aiutare a cristallizzare tutte quelle vaghe domande "what if" e ad aiutarti a inchiodare ciò che è necessario costruire successivamente.

YAGNI significa che le cose vengono fatte quando devono essere fatte e non prima. Ciò non significa che non vengano mai eseguiti, a meno che non siano mai necessari. Significa che fai solo ciò che dà al cliente un valore commerciale immediato . Ciò che significa valore commerciale immediato è soggettivo per ogni cliente e ogni progetto.

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

Nell'altro caso, perdi tempo a scrivere codice che non viene mai utilizzato, a scrivere test per codice che non viene mai utilizzato, a scrivere documentazione per codice che non viene mai utilizzato e manutenzione su codice che non viene mai utilizzato, le persone si chiedono cosa faccia questo codice e se mai viene usato, fino alla nausea.

Esempio

Se sto lavorando su un prototipo / proof of concept o versione 1.0 di un'applicazione, non ho bisogno di un design per scalare al livello di Facebook. L'inferno non ho bisogno di un disegno in scala al livello di Facebook, fino a quando comincio a vedere che io ho quel tipo di traffico.

Pensi che Zuckerberg abbia progettato la prima versione di Facebook per scalare a 500 milioni di utenti? No, lo ha progettato e costruito per fare solo ciò che doveva fare e non di più. Se avesse tentato di creare un progetto a cascata per 500 milioni di utenti dal primo giorno, probabilmente Facebook non sarebbe mai stato rilasciato.

Il modo pratico di fare le cose è come lo ha fatto. Ha iniziato con PHP e MySQL, e riprogettato e riscritto in base alle esigenze in base al valore aziendale , il ridimensionamento a milioni di utenti era di enorme valore aziendale, ma non al giorno 0. Al giorno 0, il semplice lancio di qualcosa era l'eccezionale valore commerciale.

Ha pianificato di ridisegnare e riscrivere. Che è una mentalità diversa rispetto alla pianificazione per il lavello della cucina e che in realtà non sviluppa o fornisce nulla di utile che sia completo.

Pianificare la fine della vita per una base di codice e riscrivere è Agile e prova del futuro. Cercare di trovare un obiettivo indefinito di "flessibile" finisce sempre per fallire. Stai progettando senza alcuna necessità e perdendo tempo potresti sviluppare ciò che è di valore aziendale invece di sognare con desiderio di funzionalità che non verranno mai utilizzate.

Il modo Zen di Python dice:

Adesso è meglio che mai. Anche se spesso non è mai meglio di adesso.

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

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

I casi in cui ciò è meno ovvio si trovano nei casi di refactoring. Devo applicare DRY 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, applicare DRY fino a quando non si hanno ragioni tecniche / prestazionali per non essere sempre buono.

Quindi, YAGNI fino a quando non lo fai, quindi fallo ora. Non aspettare!

Non credo che suonino insieme. Penso che ti inclini in un modo o nell'altro. E mi sposto verso YAGNI.

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

Solo i miei due centesimi.

Come si quadrano questi due schemi?

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

Quali pratiche usi per assicurarti che suonino bene?

Um. Fanno entrambi? Cos'altro può esserci?

Come li insegni insieme senza creare confusione?

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

Ora è meglio che mai descrivere 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.

Se "mai" è l'implicazione di "non ora", allora il tuo design è difettoso.

Le decisioni locali che prendi dovrebbero essere trasparenti al resto di un sistema.
Ad esempio, se si dispone di un componente CookieSource, che richiede CookieFactorydi trasformare quello CookieRecipesche sa Cookies, in base ad alcuni parametri di input, CookieSourcenon è necessario e quindi non dipende da come CookieFactoryviene implementato e come CookieRecipessono rappresentati.
Se CookieFactoryin realtà è un Bakery, ciò può tenerne conto Recipesecondo Pastry, non dovrebbe importare. E a meno che non sia necessaria tale funzionalità, non è necessario implementarla. E non vi è alcun motivo al mondo per cui non è possibile aggiungerlo in seguito, tranne se non esiste una chiara barriera di astrazione tra CookieSourcee i servizi che utilizza.

Durante la creazione di software, aggiungi la funzionalità necessaria e cerca di non bloccare te stesso nelle decisioni che prendi. Blocca invece la decisione in un'astrazione adatta .

La soluzione più semplice che ho trovato è quella di aspettarmi cambiamenti quando scrivo il codice in anticipo. Quando passo un bool a una funzione, di solito la cambio appena possibile in una bandiera / enum, quindi è a) più leggibile eb) facile da estendere. Allo stesso modo, se noto che sto passando un mucchio di parametri attorno ai quali puzza di averne bisogno, ne creo una struttura speciale. La speranza è che YAGNI lo faccia, ma se lo fai ad un certo punto, non interromperà orribilmente tutti gli utenti immediatamente e il "lavoro grugnito" è già fatto. Abbastanza spesso, puoi anche solo aggiungere un commento come / * aggiunte future andare qui * / o così quindi è chiaro che non è ancora implementato ma qui è il posto per aggiungerlo. Questo di solito aiuta di più, poiché in seguito ho scoperto che il refactoring delle interfacce richiedeva più tempo.

Progettare pensando alle future estensioni, ma non implementarle fino a quando non sono necessarie.

L'esempio che viene in mente è quando Netflix è stato avviato per la prima volta, potresti avere solo una coda associata a ciascun account. In seguito hanno hackerato il supporto per più code. Poiché non è stato progettato in questo modo dall'inizio, è diventato sempre più difficile da mantenere, quindi hanno deciso di interrompere quella funzionalità. Dopo un tumulto dei clienti, hanno morso il proiettile e hanno fatto una riprogettazione per integrare correttamente più code.

Se qualcuno all'inizio avesse concesso la possibilità che avrebbero potuto desiderare più code in seguito, avrebbero potuto risparmiarsi un sacco di dolore a lungo termine per uno sforzo aggiuntivo a breve termine aggiuntivo. Non dovevano implementare subito più code, assicurati solo che se lo avessero fatto non avrebbe richiesto una riscrittura massiccia o un hack non mantenibile.

In apparenza, sembra che richiederebbe una capacità simile a quella di un indovino per prevedere i requisiti futuri, ma in pratica cose del genere tendono a sporgere da un buon programmatore quando nota che sta codificando qualcosa o che una tabella di database sta raccogliendo molte sole colonne vagamente correlate.