Bloccato per "sapere troppo" [chiuso]

Nota altre discussioni su http://news.ycombinator.com/item?id=4037794

Ho un compito di sviluppo relativamente semplice, ma ogni volta che provo ad attaccarlo finisco a spirale in pensieri profondi: come potrebbe estendere il futuro, quali sono i clienti di seconda generazione di cui avranno bisogno, in che modo influenza "non funzionale" aspetti (ad es. prestazioni, autorizzazioni ...), come sarebbe meglio progettare per consentire il cambiamento ...

Mi ricordo di me stesso qualche tempo fa, più giovane e, forse, più desideroso. Il "me" che ero allora non avrebbe pensato a tutto ciò: sarebbe andato avanti e avrebbe scritto qualcosa, poi riscritto, poi riscritto di nuovo (e ancora ...). L '"io" oggi è più titubante, più attento.

Trovo molto più facile oggi sedermi, pianificare e istruire altre persone su come fare le cose piuttosto che andare avanti e farle da soli - non perché non mi piace programmare - al contrario, mi piace! - ma perché ogni volta che mi siedo alla tastiera, finisco in quello stesso posto fastidioso.

È sbagliato? È un'evoluzione naturale o mi sono guidato in una carreggiata?

Discreta divulgazione: in passato ero uno sviluppatore, oggi il mio titolo professionale è un "architetto di sistema". Buona fortuna a capire cosa significa - ma questo è il titolo.

Wow. Onestamente non mi aspettavo che questa domanda generasse così tante risposte. Proverò a riassumere.

Motivi:

1. Paralisi dell'analisi / Ingegneria eccessiva / placcatura in oro / (qualsiasi altro "pensare troppo in anticipo può farti del male").
2. Troppa esperienza per l'attività assegnata.
3. Non concentrarsi su ciò che è importante.
4. Non abbastanza esperienza (e rendersene conto).

Soluzioni (non corrispondenti ai motivi):

1. Prima prova.
2. Inizia a scrivere codice (+ per divertimento)
3. Uno da buttare via (+ un API da buttare via).
4. Imposta vincoli temporali.
5. Spoglia via la lanugine, rimani con la roba.
6. Rendi il codice flessibile (un po 'contrario a "uno da buttare via", no?).

Grazie a tutti - penso che il vantaggio principale qui sia stato di rendermi conto di non essere solo in questa esperienza. In realtà, ho già iniziato a scrivere codice e alcune delle cose troppo grandi sono cadute, naturalmente.

Poiché questa domanda è chiusa, accetterò la risposta con la maggior parte dei voti a partire da oggi. Quando / se cambia - Proverò a seguirlo.

Pensare a queste cose è sicuramente positivo, ma non lasciare che fermi i tuoi progressi.

Un approccio che funziona davvero bene (in particolare con lo sviluppo iterativo) è quello di implementare una soluzione semplice e poi refactoring secondo necessità in seguito. Ciò mantiene il codice il più semplice possibile ed evita un eccesso di ingegneria. La maggior parte delle modifiche alle prestazioni o all'architettura che stai pensando probabilmente non saranno richieste comunque, quindi non preoccuparti di scriverle fino a quando non saranno diventate ufficialmente necessarie. Ad esempio, non preoccuparti delle prestazioni fino a quando un profiler non ti ha detto che è tempo di migliorare le prestazioni.

Una cosa che puoi fare per aiutarti ad adeguarti è impostare un limite di tempo difficile per quanto tempo pensi a qualcosa prima di scrivere il codice. Il più delle volte, il codice risulterà migliore se ci pensate un po ', lo scrivete, realizzate i vostri errori e poi li correggiamo refactoring.

C'è un equilibrio da raggiungere qui. Non dovresti solo saltare in testa e non pensare alle conseguenze, ma non dovresti nemmeno provare a progettare troppo il tuo codice.

Wikipedia lo chiama "Analisi paralisi" nel software. La ricetta è attenersi a metodologie agili. Ciò significa che qualsiasi attività o singola azione ha molto più valore del tentativo di stabilire pratiche o politiche. Ogni collaboratore del team è prezioso, non importa quanto bene o male le abilità della persona si adattino agli ideali architettonici. In agile, gli individui, gli ego sono i primi, le politiche sono le ultime.

La mia risposta preferita è "Architecture is verb". Smetti di pensare, inizia a recitare, non importa quanto tu e il team ti sentirai imperfettamente e inefficiente. Forse le prime azioni possono essere lo smantellamento di politiche inadeguate.

40 anni fa Fred Brooks ha scritto di questo "Scrivi uno da buttare via, lo farai comunque." Niente è cambiato........

È sbagliato? È un'evoluzione naturale o mi sono guidato in una carreggiata?

Dipende. Questo tende ad essere un passo comune lungo la strada di uno sviluppatore.

1. Inizia a buttare cazzate insieme, fatti mordere nel culo da esso
2. Inizia a progettare eccessivamente l'inferno vivente di tutto, renditi conto che YAGNI
3. Accomodati su una via di mezzo pragmatica in cui le cose facili vengono schiaffeggiate insieme e le cose difficili / probabili sono dotate di ingegneria sufficiente per rendere abbastanza facile lavorare / cambiare.

È solo una routine se rimani al numero 2.

Una delle cose che mi piace sempre tenere a mente è il detto "il futuro non è più quello di una volta".

Con una certa esperienza diventa allettante credere di poter prevedere il futuro, ma non è possibile. È facile immaginare funzionalità che i futuri clienti / utenti / qualunque cosa possano desiderare, ma ciò non significa che li vorranno subito. Inoltre, ciò non significa che li vorranno rispetto ad altre funzionalità contrastanti. Quindi devi davvero limitare il tempo che passi oggi a pianificare il futuro. Devi soprattutto limitare il tempo che impieghi oggi a costruire cose che saranno utili solo in futuro.

La domanda che mi pongo che mi tiene dritto e stretto è "quanto sarà più difficile costruire questa funzionalità più tardi di quanto non lo sia ora per creare supporto per quella funzionalità?" Di solito, la risposta è che lo sforzo futuro è più o meno lo stesso di quello che sarebbe fare adesso. In tal caso, poiché non riesco a prevedere il futuro, non ho problemi a non costruirlo ora. Se la risposta arriva fino a 10 volte o più, allora inizierò a chiedermi in che misura le persone pensano che avremo bisogno di questo nel prossimo anno o due. Anche allora, a meno che non ci sia un accordo diffuso, mi limiterei semplicemente ad assicurarmi che non fosse necessario annullare le cose che stiamo facendo oggi per raggiungere tale obiettivo in futuro.

Ad esempio, ho lavorato su alcuni progetti in cui abbiamo trascorso molto tempo a sottrarre il fatto che stavamo usando Hibernate come accesso ai dati in seguito. (Non ho mai visto il progetto costruito su Hibernate smettere di usarlo, quindi era una perdita di tempo per cominciare, ma mettiamolo da parte.) Anche se fosse stata una ragionevole possibilità che potremmo voler cambiare in seguito, perché stavamo anche usando un modello di oggetti di accesso ai dati, non sarebbe stato più difficile costruire la flessibilità per cambiare Hibernate e cambiarlo allo stesso tempo quando ne avevamo bisogno di quanto non fosse per costruire la flessibilità dall'inizio. Di fronte a una situazione del genere, rimanderei la flessibilità fino a quando non ne avessimo davvero bisogno.

A meno che tu non stia facendo una pianificazione strategica per una grande azienda, non vale nemmeno la pena pensare a problemi di architettura a più di due o tre anni di distanza, perché la tecnologia sta cambiando così rapidamente. La caratteristica che potresti pensare di costruire oggi potrebbe essere liberamente disponibile in open source tra due o tre anni. Quasi sicuramente l'analisi costi-benefici sarà cambiata.

Limitati a costruire un sistema che faccia ciò di cui hai bisogno oggi, di cui sei orgoglioso e che sarai felice di lavorare tra qualche mese qualunque sia il prossimo ciclo di cambiamenti. È davvero il massimo che puoi fare.

Ecco il mio processo personale di eliminazione per i disegni pazzeschi che (nella loro prima versione) possono diventare poco pratici e danneggiare un progetto dal punto di vista aziendale.

1. Identifica l' epicentro : pensa al tuo progetto come uno stand per hot dog, l'epicentro sarebbe l'hot dog. Puoi togliere ogni altra spezia / condimento / verdura dal tuo stand ed essere ancora in grado di vendere hot dog. Qual è lo scopo principale del tuo software? Isolare ogni altra aggiunta e / o valore aggiunto da essa e concentrarsi prima sull'epicentro.
2. Continua a ripetere a te stesso "farlo in seguito significa farlo meglio" : vedi dove ha senso e metti un po 'di nota "per dopo" su di esso. Se lo fai bene e pensi al suo utilizzo nel mondo reale, finirai con lo stesso design ma con priorità in una tabella di marcia.
3. Diminish-Decouple-Discard : qualunque sia il design del modulo che hai, rendilo il più semplice / essenziale / puro / universale possibile (a volte questo può essere realizzato senza nemmeno rimuovere le funzionalità). Quando non puoi semplificarlo ulteriormente, inizia a disaccoppiare elementi che potrebbero vivere da soli e avere uno scopo. Alla fine, se hai ancora del grasso, sarai in grado di tagliarlo via.
4. Separare il "codice libreria" dal "codice produzione" : ci sarà sempre un codice che non può essere riutilizzato, ma aggiunge sempre rumore al design. Questo codice è quello che contiene le regole aziendali. Scoprirai che a volte alcune regole aziendali sono più facili e veloci da modificare ( estremamente importanti ) rispetto a un design robusto. Troverai il codice su cui puoi fare affidamento e il codice che il cliente dovrà modificare o reimplementare in futuro. Vorrai che siano tenuti il ​​più separati possibile.

E a proposito, il passaggio 0 è: "impazzire con il design". Questo mi aiuta a uscire dal mio sistema e spesso a trovare nuove implicazioni, requisiti nascosti e persino funzionalità emergenti.

Ho preso 1 e 2 da rilavorazione .

Scrivi i test. Hai finito quando tutti i test passano: non prima, e certamente non molto tempo dopo, durante una fase epica di ingegneria eccessiva. Avere una serie di test per il codice che stai scrivendo ti darà un osservatore indipendente e imparziale che ti dirà quando puoi fermarti.

Quando sei giovane, non vedi rischi (forse il motivo per cui i politici junior fanno paura), ma quando invecchi, le tue brutte esperienze ti paralizzano in ogni occasione (forse il motivo per cui i politici senior sono stagnanti). Adotta l' approccio guidato da un rasoio di Occam : cerca la soluzione che ha il minor numero di bisogni e poi evolvi da lì.

Ci sono solo due cose che devi veramente tenere a mente quando scrivi e progetti il ​​software: manutenibilità e correttezza.

La correttezza è molto importante a breve termine e può essere facilmente dimostrata dai test.

La manutenibilità aiuterà più avanti nello sviluppo ma è più difficile da definire.

La mia attuale strategia è quella di ottenere prima una prova monolitica del concetto e quindi separare l'interfaccia utente dal modello (assicurando che il modello non sappia nulla sull'interfaccia utente) una volta che sono soddisfatto che sia fattibile. Se avessi aspettato troppo a lungo questo passo, avrei ottenuto qualcosa di irraggiungibile. Se comincio con i livelli separati, non riesco proprio a iniziare mentre mi incaglio su ciò che l'interfaccia utente deve sapere sul modello.

Quando mi sono bloccato in situazioni come queste, ho scoperto che aiuta a immaginare ostinatamente che sono un utente finale che utilizza l'ipotetico programma per fare qualcosa di ragionevolmente banale. Quindi provo a concentrarmi su quali sarebbero i punti di accesso programmatici necessari per supportare tali azioni, cercando il più possibile di ignorare altri aspetti del sistema. Da qui è spesso possibile costruire una (piccola!) "Lista dei desideri" di funzionalità del sistema finito e scrivere del codice non realistico che inizia a implementarlo. Dopo quell'esercizio, di solito sono iniziato e il resto del sistema inizia a diventare più chiaro. Riguarda il punto di ingresso - e il punto di ingresso della stragrande maggioranza di tutto il software sono le azioni iniziali degli utenti finali con un programma.

Penso che sia un sindaco che i compiti che stai svolgendo siano troppo facili per te.

Qualche anno fa la sfida per te era quella di scrivere un codice che eseguisse il compito assegnato. Questo è ciò che ha coinvolto pienamente la tua mente. Ora, la tua mente (la tua esperienza ecc.) Sta lavorando in modo più efficace e facendo lo stesso compito richiede solo una parte dell'energia che era precedentemente necessaria. Ecco perché stai finendo in quella spirale di pensieri profondi. La tua mente si sta difendendo dalla routine e sta lottando per la sfida.

Penso che dovresti considerare di cambiare il tuo lavoro. Forse dovresti imparare un nuovo linguaggio di programmazione.

Ho avuto lo stesso problema 15 anni fa. Volevo scrivere un codice perfetto, riutilizzabile, universale, .... che rendesse la soluzione molto più complicata del necessario. Oggi vedo questo come placcatura in oro . Ciò che mi ha aiutato molto è stato il consiglio di un collega:

• se hai un'idea di ciò che potrebbe migliorare la funzionalità, rendila più universale, ... scrivi questa idea in un file di testo separato "ideas.txt", ma non implementarlo ora .
• continuare ad attuare i compiti urgenti.
• dopo sei mesi, rivedi il tuo "ideas.txt" e analizza quale di questi cambiamenti avrebbe davvero giovato al progetto.

Questa è semplicemente una paralisi mediante analisi. Succede a molte persone in molti campi. Puoi sfondarlo.

La risposta è: basta andare avanti con esso ;-)

Pubblico su un forum di fitness e molte volte le persone postano su diverse routine, cercando di trovare quello perfetto per loro. Quindi diciamo loro di iniziare l'allenamento e lavorarci mentre procedi. Vuoi diventare più forte, fare alcuni esercizi di forza e poi modificare le cose mentre procedi.

Quando hai un programma di grandi dimensioni e il tuo cervello fa gli straordinari, basta programmare prima i casi semplici. Inizialmente il programma deve essere eseguito, quindi deve contenere input, ecc. La
tua sfida è quella di lasciare le cose facili da aggiornare e refactor in seguito, ma il codice DEVE essere non più complicato di quanto debba essere per svolgere l'attività a portata di mano.

Ricorda che in futuro va bene il refactoring del codice per soddisfare nuove priorità. Non è possibile prevederli tutti in anticipo, quindi non provare.

Codice per l'attività successiva - SOLO. Il codice è semplice e bene, quindi è facile eseguire il refactoring se necessario. Assicurarsi che il programma funzioni. Ripetere.

Dato che ti stai "bloccando", pensando troppo a possibili scenari di casi d'uso per l'utente finale, c'è qualcosa da considerare qui se pubblicherai un'API e ti aspetti che le persone a te sconosciute utilizzino quell'API. Una volta pubblicata un'API, o devi continuare a supportarla, anche se in seguito ti rendi conto di quanto sia brutta la tua prima versione, o devi rompere il codice di tutti, forse sconosciuto a te, che ha scritto contro di essa rischiando di alienarsi loro per tutto il tempo futuro.

La soluzione standard è pubblicare con la clausola che l'API potrebbe cambiare in qualsiasi modo in qualsiasi momento fino a quando non si ha un'idea di ciò di cui i propri utenti hanno bisogno e che i consumatori delle API stanno facendo.

In quella soluzione penso sia la tua soluzione. Scrivi solo una piccola cosa che fa una o due cose, forse le fa semplicemente bene, mantenendo la consapevolezza che tutto ciò che fai potrebbe cambiare in futuro.

Non è possibile ottenere tutto bene, o in alcuni casi anche QUALSIASI, quando inizi perché il design è davvero un viaggio alla scoperta; è l'ultimo ad emergere, non la prima cosa da fare.

Non puoi progettare subito un'API e non devi mai romperla per i tuoi consumatori. Capisci perché è così. Allo stesso modo non è possibile scrivere software e non è necessario buttarlo via e ricominciare da capo con un nuovo approccio.

Non penso che tu abbia un problema nel senso che ti sei evoluto accidentalmente in qualcosa di meno creativo, produttivo o desiderabile. Penso che tu abbia standard elevati che accidentalmente applichi erroneamente alla tua situazione, un errore comune nel pensare che tutti commettano.

L'esperienza non conta mai contro di te a meno che tu non diventi un cinico sapere, tutto fatto, e suona davvero come il contrario della tua posizione.

Ho un paio di immagini che mi vengono in mente quando vado alla grande. Uno è giocare con Lego. Lo metto insieme e lo smontaggio a piacimento. Quello che inizio a fare potrebbe non essere quello che finisco per fare. Sto navigando e avvantaggiandomi delle possibilità che mi vengono in mente mentre procedo, ricreando spesso i miei obiettivi sul posto in un lampo di ispirazione ... ecco cos'è la creatività.

L'altra immagine è un'analogia che ho sentito che descrive la scienza vera. Stai tentando in una stanza buia per un gatto nero che potrebbe non essere lì. È snervante solo se ti consideri un fallimento per non aver trovato quel gatto. Non c'è altro modo per trovare i gatti neri. Questa è l'unica attività che mai li individua. Qualsiasi altra cosa è già una forma di avere ciò che presumibilmente stai cercando.

Non sai troppo; non sai abbastanza! E te ne sei accorto solo di recente.

Non pensare alle tue scelte di design come a qualcosa che devi ottenere "giusto", perché non c'è "giusto" - ci sono molti "errori", ma ci sono anche dei compromessi (in termini di velocità di esecuzione, tempo per completare la codifica compito, estensibilità, ecc.). Il codice che scrivi se ben concepito avrà ancora vari punti di forza e di debolezza.

L'obiettivo dovrebbe essere arrivare al punto in cui comprendere questi punti di forza e di debolezza nel contesto dell'uso e della manutenzione attuali e futuri non è drammaticamente più difficile che scrivere il codice in primo luogo.

Quindi non evitare pensieri profondi, ma ricorda che hai bisogno di esperienza, non solo di pensiero, per diventare un maestro in questo tipo di design. Pensa fino a quando non raggiungi un punto in cui non sei sicuro di una scelta particolare, quindi implementa quello che speri sia il migliore, provalo e impara da come è andata.

Pratica codifica. Trova degli esercizi o trovali online e cerca di completarli correttamente il più rapidamente possibile. Quando aumenti la velocità, aggiungi considerazioni come manutenibilità e prestazioni. Ti renderai conto che è rinfrescante programmare cose che non andranno in produzione e potrebbero aiutarti a uscire dalla tua paura di scrivere codice.

Fai la programmazione nel tuo tempo libero, come hai fatto 10 anni fa, con meno preoccupazioni e solo divertimento.

Diventa un team manager e dirigere più giovani sviluppatori - che ora sono nello stesso stato mentale come lo siete stati 10 anni fa.

No, non sai ancora abbastanza.

Arricchisci le tue conoscenze, ad esempio con queste semplici regole:

• BACIO: mantienilo piccolo e semplice.
• YAGNI: Non ne avrai bisogno.
• Peggio ancora è meglio: alcune soluzioni peggiori sono effettivamente migliori in termini di manutenibilità.

Non ingegnere eccessivamente. Preparati al cambiamento avendo abilità di refactoring, ma non codificare ogni possibile cambiamento nel codice. Se vedi che nel tempo, una classe o una funzione diventa troppo grande, modificala. Dividere e conquistare. Usa le interfacce, usa più funzioni. Se ritieni di aver diviso troppo (ovvero è diventato in qualche modo più elaborato, ma meno leggibile), annulla l'ultima modifica.

In sintesi: rendi il tuo codice abbastanza flessibile, ma non di più. Invece, renditi flessibile, acquista un libro sul refactoring.

Due cose:

1. Non è abbastanza sapere molto. Devi avere opinioni su ciò che vale la pena implementare. Personalmente vedo TDD come una stampella che consente una cattiva architettura. Data la grande quantità di opinione popolare che mi contrappone, probabilmente mi sbaglio, ma se implementare TDD in JavaScript non è un problema a cui ho pensato, perché il debug non è mai stato un grosso mal di testa per me e hey, non sarebbe la prima volta che l'opinione popolare nella comunità di sviluppo è stata in seguito vista come difettosa anni dopo. Quindi impara ad essere un arrogante. Almeno all'interno. Potresti avere torto, ma almeno ti impegni a cose che funzionano per te piuttosto che a pensare troppo a cose che potrebbero non esserlo.

2. Sembra che tu stia iniziando con il micro. Inizia con la macro. Innanzitutto gli strumenti di cui hai bisogno per fare ciò che la tua app deve fare. Quella parte dovrebbe venire abbastanza facilmente. Quindi iniziare con problemi di architettura / interfaccia. Il modo in cui l'impianto idraulico si collega e ciò a cui si connette dovrebbe davvero essere solo i frammenti in cima a tutto ciò che puoi semplicemente scorrere da parte e sostituire per un capriccio. Allo stesso modo con i dettagli di come vengono fatte le cose. Avvolti correttamente, possono essere facilmente sostituiti / modificati.

ma ogni volta che provo ad attaccarlo, finisco per spiraleggiare in pensieri profondi

Non c'è niente di sbagliato. Hai notato solo che è tempo di migliorare il tuo processo: in questo caso, il tuo processo di pensiero.

Molte persone si perdono nell'analisi o vengono distratte in altri modi e non se ne accorgono nemmeno. Hai notato che puoi cambiare il tuo modo di pensare per rimanere in pista.

Ci sono molte soluzioni a questo, e la migliore che ho visto sopra è fissare un limite di tempo. Prima di iniziare, decidi per quanto tempo (1 ora?) Dedicherai all'analisi e al pensiero. Imposta un timer.

Quindi, quando il timer si spegne, avviare la codifica. Se ti ritrovi a pensare alle cose per troppo tempo, prendi una decisione immediata. Qualunque cosa tu decida in quel momento è la decisione corretta. Puoi sempre apportare modifiche e miglioramenti in un secondo momento.

Inoltre, il nostro ambiente è in continua evoluzione. Spesso abbiamo bisogno di aggiornare il nostro codice per gestire nuovi requisiti, nuove tecnologie, nuovo hardware, aggiornamenti di lingua e sistema, ecc.

Sì, questo horror di programmazione accade anche per me. Rimanere colpiti con Stack Overflow. Codifica in dettaglio per una piccola applicazione. Ma quando è un progetto in outsourcing, non consuma molto tempo a causa dei vincoli temporali. E anche lavorare con un gruppo di nuove persone può superare questo, credo.

Non sei abbastanza spietato

http://playswithfire.com/blog/2012/02/19/you-are-not-ruthless-enough/

Modifica: Il punto di questo articolo sta prestando attenzione ai piccoli dettagli durante lo sviluppo, ma ho scoperto che aiuta ad affrontare qualsiasi compito semplice o complesso con un atteggiamento spietato al fine di trovare la soluzione più efficiente possibile e fare semplicemente il lavoro.