Bloccato a causa del "sapere troppo" [chiuso]

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

Un approccio che funziona molto bene (in particolare con lo sviluppo iterativo) è quello di implementare una soluzione semplice e quindi di effettuare il refact in base alle necessità in seguito. Ciò mantiene il codice il più semplice possibile ed evita la sovraingegnerizzazione. La maggior parte delle modifiche alle prestazioni o all'architettura che state contemplando probabilmente non saranno richieste in ogni caso, quindi non preoccupatevi di scriverle fino a quando non saranno ufficialmente necessarie. Ad esempio, non preoccuparti delle prestazioni finché un profiler non ti ha detto che è ora di migliorare le prestazioni.

Una cosa che puoi fare per aiutarti a regolare è impostare un limite di tempo difficile per quanto tempo pensi a qualcosa prima di scrivere il codice. Il più delle volte, il codice risulta migliore se si pensa per un po ', lo si scrive, si realizzano i propri errori e poi li si risolve mediante il refactoring.

C'è un equilibrio da colpire qui. Non dovresti semplicemente saltare a capofitto e non pensare alle conseguenze, ma non dovresti nemmeno provare a sovra-ingegnerizzare il tuo codice.

Wikipedia lo nomina "Paralisi dell'analisi" nel software. La ricetta è di attenersi a metodologie agili. Ciò significa che qualsiasi attività o azione individuale ha molto più valore del tentativo di stabilire pratiche o politiche. Ogni collaboratore della squadra è prezioso, non importa quanto bene o male le capacità 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 si sentano imperfettamente e inefficienti. Forse le prime azioni possono smantellare le politiche inappropriate.

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

Is this wrong? Is this a natural evolution, or did I drive myself into a rut?

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

1. Inizia a lanciare cazzate insieme, prendi un morso nel culo da esso
2. Comincia a ingegnerizzare l'inferno vivente con tutto, renditi conto che YAGNI
3. Stabilisci una via di mezzo pragmatica in cui le cose facili vengono prese a schiaffi e le cose difficili / mutevoli-probabili hanno abbastanza ingegneria da rendere abbastanza facile lavorare con / cambiare.

È solo un solco se rimani al numero 2.

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

Con una certa esperienza diventa allettante credere di poter predire il futuro, ma non puoi. È facile immaginare le caratteristiche che i futuri clienti / utenti / qualunque cosa possa desiderare, ma ciò non significa che le vorrà subito. Inoltre, non significa che li vorrà su qualche altra caratteristica in conflitto. Quindi hai davvero bisogno di limitare il tempo che passi oggi a pianificare il futuro. Devi soprattutto limitare il tempo che dedichi a costruire cose che saranno utili solo in futuro.

La domanda che chiedo mi mantiene dritta e stretta è "quanto sarà più difficile costruire questa funzionalità più tardi di quanto non lo sia ora di creare supporto per quella funzionalità?" Di solito, la risposta è che lo sforzo futuro è più o meno lo stesso o forse il doppio di quello che sarebbe farlo ora. In quel caso, poiché non posso prevedere il futuro, non ho alcun problema a non costruirlo ora. Se la risposta arriva fino a 10 volte o più, allora inizierò a chiedere in giro su quanto sia probabile che la gente pensi che avremo bisogno di questo nei prossimi anni o due. Anche allora, a meno che non vi sia un accordo diffuso, mi limiterò semplicemente a fare in modo che non sia necessario annullare le cose che stiamo facendo oggi per raggiungere questo obiettivo in futuro.

Ad esempio, ho lavorato su alcuni progetti in cui abbiamo trascorso molto tempo ad astrarre il fatto che stavamo usando Hibernate come accesso ai dati in un secondo momento. (Non ho mai visto il progetto costruito su Hibernate smettere di usarlo, quindi è stata una perdita di tempo per cominciare, ma mettiamola da parte.) Anche se fosse stata una ragionevole possibilità che avremmo potuto cambiare in seguito, perché stavamo anche usando un pattern di oggetti di accesso ai dati, non sarebbe stato difficile costruire la flessibilità per cambiare Hibernate e cambiarlo nello stesso momento in cui ne avevamo bisogno piuttosto che costruire la flessibilità dall'inizio. Di fronte a una situazione del genere ora, vorrei solo rimandare questa flessibilità fino a quando non ne avevamo davvero bisogno.

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

Limitati a costruire un sistema che fa ciò di cui hai bisogno oggi, di cui sei orgoglioso e che sarai felice di lavorare in pochi mesi qualunque sia il prossimo ciclo di cambiamenti. Questo è davvero il meglio che puoi fare.

Ecco il mio personale processo di eliminazione per fantastici disegni che (nella loro prima versione) possono finire per essere poco pratici e danneggiare un progetto dal punto di vista del business.

1. Identifica l'epicentro . Pensa al tuo progetto come a un hot dog, l'epicentro sarebbe l'hot dog. Puoi prendere 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". Se lo fai bene e pensi al suo utilizzo nel mondo reale, finirai con lo stesso design ma con priorità in una roadmap.
3. Diminish-Decouple-Discard : qualunque sia il design del modulo, puoi renderlo il più semplice / essenziale / puro / universale possibile (a volte ciò può essere realizzato senza nemmeno rimuovere le funzionalità). Quando non puoi semplificare ulteriormente, inizia a separare gli elementi che potrebbero vivere da soli e avere uno scopo. Alla fine, se hai ancora del grasso lì dentro, sarai in grado di tagliarlo.
4. Separa "codice libreria" da "codice di produzione" : ci sarà sempre un codice che non può essere riutilizzato, ma aggiunge sempre rumore alla progettazione. Questo codice è quello che contiene le regole aziendali. Scoprirai che a volte alcune regole aziendali sono solo più facili e veloci da modificare ( estremamente importante ) rispetto a un design robusto. Troverai il codice su cui puoi fare affidamento e codifichi le esigenze del cliente di cambiare o reimplementare in futuro. Vorrai che vengano mantenuti il più distinti possibile.

E BTW, il passo 0 è: "impazzire con il design". Questo mi aiuta a tirarlo fuori dal mio sistema e spesso a trovare nuove implicazioni, requisiti nascosti e anche caratteristiche emergenti.

Ho preso 1 & 2 da Rilavorazione .

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

Quando sei giovane, non vedi il rischio (forse la ragione per cui i politici junior fanno paura), ma con l'invecchiamento, le tue brutte esperienze ti paralizzano in ogni occasione (forse la ragione per cui i politici anziani sono stagnanti). Adotta un il rasoio di Occam approccio guidato - scegli la soluzione che ha il minor numero di bisogni e poi evolvi da lì.

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

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

La manutenibilità aiuterà in seguito nello sviluppo, ma è più difficile da definire.

La mia strategia attuale è di ottenere innanzitutto una dimostrazione monolitica del concetto e quindi separare l'interfaccia utente dal modello (assicurandomi che il modello non sappia nulla sull'interfaccia utente) una volta che sono soddisfatto che sia fattibile. Se aspetterei troppo tempo per questo passaggio, otterrei qualcosa di non gestibile. Se comincio con i livelli separati, non riesco a iniziare a funzionare, perché rimango bloccato su ciò che l'interfaccia utente deve conoscere del modello.

Quando mi sono bloccato in situazioni come queste, ho scoperto che aiuta a pensare ostinatamente di essere un utente finale che usa l'ipotetico programma per ottenere qualcosa di ragionevolmente banale. Quindi cerco di 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 delle caratteristiche del sistema finito e scrivere un codice non realistico che inizia per implementarlo. Dopo quell'esercizio, di solito inizio, e il resto del sistema inizia a diventare più chiaro. Riguarda il punto di ingresso - e il punto di ingresso della maggior parte di tutto il software sono le azioni iniziali dell'utente finale con un programma.

Penso che sia una sindrome che i compiti che stai facendo siano troppo facili per te.

Alcuni anni fa la sfida per te era scrivere un codice che realizzasse il compito assegnato. Questo è ciò che ti ha pienamente impegnato. Ora, la tua mente (la tua esperienza, ecc.) Sta lavorando in modo più efficace e fare lo stesso compito richiede solo una parte dell'energia che prima era necessaria. Questo è il motivo per cui stai finendo in quella spirale di pensieri profondi. La tua mente si sta difendendo dalla routine e sta combattendo 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 lo vedo come Placcatura in oro . Ciò che mi ha aiutato molto è stato un consiglio di un collega:

• se hai un'idea di cosa potrebbe migliorare la funzionalità, renderla più universale, ... scrivere questa idea in un file di testo separato "ideas.txt" ma non implementarlo ora .
• continua ad implementare le attività urgenti.
• dopo sei mesi, rivedi il tuo "ideas.txt" e analizza quali di questi cambiamenti avrebbero davvero avvantaggiato il progetto.

Questa è semplicemente paralisi per analisi. Succede a molte persone in molti campi. Puoi sfondare.

La risposta è: JUST GET ON WITH IT ;-))

Post in un forum di fitness e molte volte le persone postano su routine diverse, cercando di trovare l'esatto perfetto per loro. Quindi diciamo loro che iniziano ad allenarsi e funzionano mentre procedete. Vuoi diventare più strong, fare alcuni esercizi di forza e poi modificare le cose mentre vai.

Quando hai un programma di grandi dimensioni e il tuo cervello lavora fuori orario - per prima cosa codifica solo per i casi semplici. Inizialmente il programma deve essere eseguito, quindi deve ricevere input, ecc La tua sfida è quella di lasciare le cose facili da aggiornare e refactoring in seguito, ma il codice DEVE non essere più complicato di quanto non debba essere necessario per eseguire l'operazione in corso.

Ricorda che in futuro va bene il codice refactoring per soddisfare nuove priorità. Non puoi prevederli tutti in anticipo quindi non provarci.

Codice per la prossima attività: SOLO. Il codice è semplice e buono, quindi è facile da refactoring, se necessario. Assicurati che il programma funzioni. Ripeti.

Dal momento che stai diventando "bloccato" da possibili scenari di utilizzo degli utenti finali, c'è qualcosa da considerare qui se pubblichi un'API e ti aspetti che le persone a te sconosciute utilizzeranno quell'API . Una volta pubblicata un'API, devi continuare a supportarla, anche se in seguito ti rendi conto di quanto sia pessima la tua prima versione, o devi rompere il codice di tutti, forse a te sconosciuto, chi ha scritto contro di essa rischiando così di alienarsi li per tutto il tempo futuro.

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

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

Non è possibile andare tutto bene, o in alcuni casi nemmeno 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 ai tuoi consumatori. Hai capito perché è così. Allo stesso modo non puoi scrivere software e non devi buttarlo via tutto e ricominciare da capo con un nuovo approccio.

Non penso che tu abbia un problema nel senso che ti sei involontariamente evoluto in qualcosa di meno creativo, produttivo o desiderabile. Penso che tu abbia degli standard elevati che stai casualmente applicando erroneamente alla tua situazione: un errore comune nel pensare che tutti fanno.

L'esperienza non conta mai contro di te, a meno che tu non diventi un cinico conoscitore di tutti, fatto tutto e questo suona davvero come il tuo contrario.

Ho un paio di immagini che tengo nella mia mente quando vado alla grande. Uno è giocare con Lego. Lo metto insieme e lo smonta a piacere. 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 cammino, ricreando spesso i miei obiettivi sul momento in un lampo di ispirazione ... ecco cos'è la creatività.

L'altra immagine è un'analogia che ho sentito descrivendo come fare scienza vera. Stai brancolando in una stanza buia per un gatto nero che potrebbe non esserci. È snervante solo se ti consideri un fallimento per non aver trovato quel gatto. Non c'è altro modo per trovare gatti neri. Questa è l'unica attività che li localizzi. Qualsiasi altra cosa è una forma di avere già quello che stai presumibilmente cercando.

Non ne sai troppo; non ne sai abbastanza! E l'hai capito solo di recente.

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

L'obiettivo dovrebbe essere quello di arrivare al punto in cui la comprensione di questi punti di forza e di debolezza nel contesto dell'uso e della manutenzione attuali e futuri non è drammaticamente più difficile della scrittura di codice, in primo luogo.

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

Codifica pratica. Trova esercizi o trovali online e prova a finirli correttamente il più velocemente possibile. Quando aumenti la velocità, aggiungi considerazioni come manutenibilità e prestazioni. Ti renderai conto che è un modo rinfrescante per codificare cose che non entreranno in produzione e potrebbe aiutarti a uscire dalla paura del codice.

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

Diventa un team manager e diretto giovani sviluppatori - che si trovano ora nello stesso stato mentale di 10 anni fa.

No, non ne sai abbastanza ancora.

Arricchisci le tue conoscenze, ad es. con queste semplici regole:

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

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

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

Due cose:

1. Non basta 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 mera quantità di opinione popolare che lavora contro di me su questo, probabilmente ho torto, ma se implementare TDD in JavaScript non è un problema a cui ho pensato, perché il debug non è mai stato un enorme mal di testa per me ed hey, non sarebbe la prima volta che l'opinione popolare nella comunità di sviluppo è stata in seguito considerata imperfetta anni dopo. Quindi impara ad essere una puntura arrogante. Almeno dentro. Potresti sbagliarti, ma almeno ti impegni a fare cose che funzionano per te piuttosto che a pensare troppo a cose che potrebbero non farlo.

2. Sembra che tu stia iniziando con micro. Inizia con la macro. Innanzitutto gli strumenti necessari per fare ciò che la tua app deve fare. Quella parte dovrebbe venire abbastanza facilmente. Quindi inizia con problemi di architettura / interfaccia. Il modo in cui l'impianto idraulico si connette e quello a cui si connette dovrebbero essere solo i frammenti sottili sopra tutto ciò che puoi semplicemente sfiorare e sostituire per un capriccio. Allo stesso modo con i dettagli di come sono fatte le cose. Avvolti correttamente questi possono essere sostituiti / modificati con facilità.

but every time I try to attack it, I end up spiraling in deep thoughts

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

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

Ci sono molte soluzioni a questo, e il migliore che ho visto sopra sta impostando un vincolo temporale. Prima di iniziare, decidi per quanto tempo (1 ora?) Dedichi all'analisi e al pensiero. Imposta un timer.

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

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

Sì, questo orrore del codice accade anche per me. Essere colpiti da Stack Overflow. Codifica in dettaglio per una piccola applicazione. Ma quando si tratta di un progetto in outsourcing, non mangia molto tempo a causa di vincoli di tempo. E anche lavorare con un gruppo di nuove persone può superare questo, mi sento.

You Are Not Ruthless Enough

link

Modifica: il punto di questo articolo è prestare attenzione ai piccoli dettagli durante lo sviluppo, ma ho trovato che aiuta ad affrontare qualsiasi compito semplice o complesso con un atteggiamento spietato al fine di trovare il singolo soluzione efficiente possibile e solo portare a termine il lavoro.