Come può un Brainer destro gestire il codice del Brainer sinistro massiccio? [chiuso]


11

Sono un artista, per lo più, anche se mi descrivo come un artista / fisico. Mentre posso fare matematica, occuparmi delle parole e delle cose "logiche" considerate cervello sinistro, è uno sforzo e faccio errori, mentre faccio bene e la maggior parte delle volte penso in termini di cose associate al cervello destro pensiero: relazioni spaziali, contesto olistico del quadro generale, ecc. Ovviamente tutto ciò è confuso, poiché la teoria del cervello destro-sinistro è semplificata e nessuna attività mentale è così semplice. Eppure ho la sensazione di adattarmi perfettamente ad artisti, registi video, chef e altri tipi di pensiero non verbale, tipi creativi, mentre la maggior parte delle persone in "IT" o ingegneri del software hardcore hanno menti che funzionano in modo diverso, con attenzione ai dettagli, tenendo molti dettagli in mente contemporaneamente e forti capacità razionali e verbali.

Quindi eccomi qui in un lavoro pagato per correggere bug pignoli e oscuri in un enorme sciame di software C ++, molto pesante su OO, e qualsiasi riga di codice non ha senso a meno che non tenga conto di una ventina di altri nomi di classi e metodi, relazioni tra loro, il flusso di esecuzione (molto simile a uno spaghetti) e altri dettagli.

Oltre a ciò, sono anche piuttosto contrario a molti degli stili contemporanei C ++ e OO. Coloro che hanno scritto questo codice hanno davvero bevuto il profondo OO e Modern C ++ kool-ade. Trovo che in realtà il codice sia molto più difficile da seguire, molto più difficile decidere dove correggere o modificare qualcosa. Non so se questo fa parte della differenza sinistra / destra (o come vuoi chiamarla) o no.

Ma devo lavorare sul C ++: le persone dipendono da me per il mio reddito. Quali sono i suggerimenti e le tecniche per affrontare questa situazione, per essere il più efficace possibile per il mio datore di lavoro?


9
Non è una differenza del cervello sinistro / del cervello destro - nessuno può comprendere o modificare quel tipo di codice C ++ senza uno sforzo enorme, a parte la persona che lo ha scritto (spesso, nemmeno loro). Assicurati solo che quando ti viene chiesto un preventivo su quanto tempo ci vorrà, lo riempirai di qualche centinaio per cento per affrontare il design "contemporaneo".
Carson63000,

8
Non essere così frustrato. Il C ++ è un linguaggio molto strano, in cui l'obiettivo del design non era l'usabilità (per l'uomo) né la compilabilità, la chiarezza, la correttezza (per i compilatori). L'unico obiettivo progettuale del C ++ era quello di rendere ogni possibile permutazione lessicale significante qualcosa, anche se era completamente poco pratico.

1
@Rocket: hai fatto saltare in aria :-) ma sono d'accordo a pezzi.
Geek,

@mojuba - sì, usiamo una forma extra-avanzata di C ++: D
DarenW,

2
Questo si chiama "Legacy Code" e il problema non è solo per te. Vedi en.wikipedia.org/wiki/Legacy_code per un link al libro di Michael Feathers su come domare una tale bestia.

Risposte:


2

Prova ad approfondire il lato progettuale di cose in cui sentirsi a proprio agio con la confusione è un punto di forza sarebbe il mio suggerimento in termini di avanzamento di carriera. Come qualcuno a cui piace essere creativo, lavorare sulla manutenzione potrebbe non essere perfetto, mentre lavorare su nuove cose potrebbe essere migliore, se possibile.

Mentre non c'è nulla di sbagliato nel volere un po 'di orgoglio nel proprio lavoro, il voler non impantanarsi nei dettagli può essere qualcosa che potresti dover trovare un nuovo approccio per migliorare. Invece di vederlo come se fosse diventato sporco e sporco, potrebbe esserci un'altra prospettiva che potrebbe renderlo divertente in qualche modo.


Supporto e manutenzione probabilmente hanno i loro fan in quanto alcune persone preferiscono modificare i sistemi esistenti piuttosto che inserirli in un nuovo sistema. So che tendo a lavorare meglio con un sistema esistente che sto cambiando piuttosto che cercare di estrarre qualcosa dall'etere.

Quello che potresti provare a fare è notare quando le persone vogliono idee per affrontare vari punti problematici e soluzioni di brainstorming poiché questo fa parte di ciò che ti piace. Non si tratta di sapere quali righe di codice modificare, ma piuttosto se si può dire a qualcuno: "Hai guardato in quell'oggetto e hai visto se sta facendo più di quanto sostiene?" tipo di cosa.

Un altro punto è sapere cosa si desidera creare: grafica, applicazioni, siti Web, processi o sistemi? Queste sono tutte cose leggermente diverse che nel voler creare, ti potrebbe essere chiesto "Crea cosa?"


Questa idea è quasi uscita dall'incontro con il mio capo proprio ieri. Mi chiedo: creare le cose non è sempre più desiderabile da tutti e la manutenzione è sempre come pulire i bagni? Se qualcuno va in giro dicendo "Preferirei CREARE cose!" sarebbero presi sul serio?
DarenW,

4
Mi piace la manutenzione del codice. È più simile alla chirurgia che alla pulizia dei servizi igienici: devi riparare parte di un sistema funzionante, senza romperlo.
Frank Shearar,

"estrarre qualcosa dall'etere" - mi ricorda un sogno in cui stavo tirando fuori le ciambelle al limone per impressionare una ragazza: D Ma seriamente questo è un punto chiave per me - Ho sempre voglia, pensando, creare cose nuove.
DarenW,

3
@FrankShearar A volte è come un intervento chirurgico fatto in bagno; (
mlvljr

16

Non suona (almeno per me) come se il tuo codice fosse particolarmente orientato agli oggetti, o particolarmente simile a "Modern C ++". Anzi, al contrario, uno degli elementi chiave del buon orientamento agli oggetti è l'incapsulamento, il cui intento principale è quello di ridurre il numero di cose che è necessario tenere traccia in qualsiasi momento. Allo stesso modo, "flusso di esecuzione molto simile a quello degli spaghetti" non suona né orientato agli oggetti né moderno (niente).

Ora, suppongo che se guardassi il codice che stai mantenendo, potrei vederlo in modo diverso e / o potresti vedere il mio codice come simile a quello che stai mantenendo in questo momento - è un po 'difficile da indovinare. È vero che se provassi a rintracciare ogni dettaglio di come funziona il mio codice, suppongo che potresti vederlo come un flusso di controllo piuttosto simile a uno spaghetti.

Ad esempio, sono molto più affezionato (o almeno tollerante) a un bel po 'di conversioni implicite rispetto a molti programmatori: uso un po' cose come le classi proxy. Ciò significa che potrebbero esserci facilmente tre o quattro oggetti temporanei di diversi tipi creati nel corso della chiamata di una singola funzione (e nota che non sto parlando di eseguire effettivamente la funzione, ma semplicemente chiamarla ). Naturalmente, tutti quegli oggetti temporanei verranno nuovamente distrutti alla fine dell'espressione contenente la chiamata di funzione. Se lo conti, potresti avere facilmente mezza dozzina o più funzioni separate invocate nella chiamata / ritorno da una funzione che è "visibilmente" chiamata nel codice.

Il punto di fare le cose in questo modo, tuttavia, è rendere facile ignorare la maggior parte delle curiosità coinvolte (ad esempio) nel trattare dettagli come il modo in cui un particolare oggetto è rappresentato e concentrarsi esclusivamente su ciò che è realmente invece. Avresti sempre bisogno di occuparti della maggior parte di quel codice se vedessi un bug in quella particolare parte. Cerco di evitare gran parte di ciò, tuttavia, creando classi così piccole e semplici, che fanno così poco, che basta poco più di uno sguardo per rendersi conto che è ovviamente corretto, quindi è facile ignorarlo da quel momento in poi.


Ugh! Questo genere di cose mi fa rabbrividire! Forse il mio stile di pensiero è troppo basso, vale a dire "programmazione orientata al codice operativo", per sentirsi a mio agio con questo.
DarenW,

2
Per quanto riguarda "rendere facile ignorare la maggior parte delle curiosità" - lo stile del codice sembra essere un glorificatore di curiosità. Cercando di risolvere una piccola cosa questa settimana, c'erano incredibili quantità di dettagli che non fanno davvero nulla.
DarenW,

"... creando classi così piccole e semplici, che fanno così poco, che basta poco più di uno sguardo ..." Ci sono dei buoni esempi open source di questo?
DarenW,

2
@darrenw sicuro, smalltalk 80
Tim Williscroft il

10

Attenzione : questa risposta è molto lunga e ha molte psico-parole (che cerco di spiegare, ma comunque). Cosa posso dire? La psicologia è una delle mie materie preferite al di fuori della programmazione.

Sono un artista, per lo più, anche se mi descrivo come un artista / fisico. Mentre posso fare matematica, occuparmi delle parole e delle cose "logiche" considerate cervello sinistro, è uno sforzo e faccio errori, mentre faccio bene e la maggior parte delle volte penso in termini di cose associate al cervello destro pensiero: relazioni spaziali, contesto olistico del quadro generale, ecc. Ovviamente tutto ciò è confuso, poiché la teoria del cervello destro-sinistro è semplificata e nessuna attività mentale è così semplice. Eppure ho la sensazione di adattarmi perfettamente ad artisti, registi video, chef e altri tipi di pensiero non verbale, tipi creativi, mentre la maggior parte delle persone in "IT" o ingegneri del software hardcore hanno menti che funzionano in modo diverso, con attenzione ai dettagli, tenendo molti dettagli in mente contemporaneamente e forti capacità razionali e verbali.

Questo in realtà si basa su una visione un po 'datata della neuroscienza. A un certo punto, gli scienziati credevano che il cervello sinistro fosse responsabile solo della logica e dei dati sensoriali grezzi mentre il cervello destro era il solo responsabile dell'intuizione e dei sentimenti. A quanto pare, il cervello sinistro è davvero capace di tutto ciò che è il cervello destro e viceversa. Come qualcuno che è estremamente razionale ma logico, terribile con le direzioni e l'orientamento spaziale e completamente privo di qualsiasi creatività artistica che è tradizionalmente associata al cervello destro, posso attestarlo.

Il modo migliore per pensare alla differenza tra il cervello sinistro e quello destro è quello di pensarli come immagini speculari l'uno dell'altro. Per capirlo, hai bisogno di alcuni dati di background. Uno psicologo di nome Carl Jung inventò una teoria della personalità negli anni '20 che divideva la personalità in un paio di dimensioni. Probabilmente ne hai sentito parlare: introversione vs estroversione. Ho scritto un paio di blogposts su questo argomento, ma sostanzialmente si riduce a questo: l'introversione si differenzia dagli altri mentre l'estroversione si concentra su come può connettersi agli altri. Questo è indicato come un "atteggiamento".

Quindi hai quattro diverse funzioni cognitive: pensiero, sentimento, sensazione e intuizione. Per semplicità, diciamo solo che due di queste funzioni sono considerate funzioni di "giudizio" (pensiero e sentimento) mentre le altre due sono funzioni di "percezione". Le funzioni di giudizio prendono decisioni. Quando sei in una mentalità giudicante, stai cercando di evitare sorprese. Vuoi aver preso tutte le giuste decisioni in anticipo in modo da non doverti adattare quando arrivano le sorprese. Poiché hai pianificato in anticipo così tante cose, potresti avere la tendenza a diventare rigida e non flessibile una volta presa una decisione. D'altra parte, una mentalità percepente tende a preferire volare vicino al sedile dei pantaloni e rotolare con i pugni.

Generalmente, si combinano la funzione e un atteggiamento per creare un atteggiamento (nome creativo) (pensiero introverso, sentimento estroverso, ecc.). Le personalità coscienti delle persone sono definite principalmente da un atteggiamento di funzione dominante e da un atteggiamento di funzione ausiliaria. Alla fine, gli psicologi hanno raggiunto un consenso sul fatto che ci sono sostanzialmente due tipi di persone: persone le cui due principali funzioni consistono in una funzione di giudizio introversa e una funzione di percezione estroversa, o persone le cui due principali funzioni consistono in una funzione di giudizio estroversa e una funzione di percezione introversa . Se hai mai preso l'MBTI o un test di personalità simile, l'ultima lettera ti dice in quale categoria rientri. Se sei una P, significa che sei un giudice introverso / percepitore estroverso e J è il contrario.

Ancora con me finora? Ecco dove capisco cosa intendevo con le due parti come immagini speculari l'una dell'altra. Nessuno se ne rendeva conto in quel momento, ma stavano essenzialmente costruendo uno schizzo di dove la funzionalità si trova nel cervello. In effetti, ciascuno degli atteggiamenti di funzione di Jung è stato mappato in una posizione approssimativa nel cervello. A quanto pare, tutte le funzioni P (giudizio introverso e percezione estroversa) si trovano sul lato destro del cervello e le funzioni J si trovano sul lato sinistro del cervello.

Ogni volta che dici che le persone con il cervello sinistro sono brave nei dettagli e le persone con il cervello destro sono brave nel "quadro generale" (anche se direi che "il quadro completo" sarebbe più preciso), ti stai concentrando sul lato estroverso delle cose . Se una persona dal cervello sinistro gestisce una persona dal cervello destro, il mancino vorrà conoscere tutti i dettagli su come il legittimo farà il proprio lavoro in anticipo e in anticipo. Vogliono che i requisiti stabiliti nella pietra e le scadenze rigide siano decisi in anticipo. Il giusto vuole solo un'idea molto ampia di ciò che deve fare in modo da poter compilare i dettagli in seguito.

Tuttavia, nota che questo non sembra non essere ciò che stai vivendo. Sembra che il codice dei mancini probabilmente non sia stato terribilmente ben studiato in anticipo e abbia alcuni problemi che avrebbero potuto essere prevenuti da alcuni pensati. Questo perché quando costruisci modelli astratti di cose come il codice nella tua testa, stai usando la tua funzione introversa , che funziona al contrario. Il righty vuole costruire quel modello in anticipo e fare così in modo che si riempie in tutti i dettagli necessari o facilmente in grado di compilare tutti i dettagli. Inoltre, potrebbero diventare rigidi in termini del miglior approccio da adottare (nota che stai prendendo una linea dura su come ti senti riguardo alle funzionalità più avanzate di C ++). Il modello dei mancini sarà più ad hoc e compilato man mano che procedono.

La mia esperienza è che, a causa di ciò, i mancini accuseranno i giusti di progettare eccessivamente tutto mentre i giusti accuseranno i mancini di essere troppo rapidi e sporchi. Entrambe le parti hanno un granello di verità per loro, ma solo quando questo approccio è portato all'estremo. Ecco cosa c'è di divertente però: stanno adottando approcci opposti per raggiungere lo stesso obiettivo (cioè ottenere risultati). I giusti vogliono che il loro modello sia deciso in anticipo in modo da poter dedicare meno tempo all'implementazione della cosa e quindi completare l'intero progetto prima. I mancini vogliono passare meno tempo a progettare in modo da poter fare le cose prima.

Per inciso, questi due atteggiamenti sono invertiti quando si tratta di cose di tipo di gestione del progetto (determinazione delle scadenze, elaborazione di requisiti, ecc.). Questo può portare a una situazione davvero confusa in cui una parte sta accusando l'altra di essere troppo rigida mentre l'altra afferma che l'altra parte non sta pianificando abbastanza in anticipo, e quindi l'argomento successivo ha entrambe le parti che assumono esattamente la posizione opposta.

Cosa puoi fare per tutto questo? Nient'altro che essere consapevoli di queste differenze e cercare di soddisfare il più possibile l'opinione dell'altra parte. Il problema però è che questo va in entrambe le direzioni. Puoi capire e accogliere i mancini il più possibile, ma questo non farà molta differenza a meno che non stiano cercando di restituire il favore. Questa è sempre la sfida. Non perché i mancini sono degli stronzi e vogliono rendere miserabili le vite dei diritti, ma perché i mancini sono abituati a dominare nel campo della programmazione. Se il tuo modo di pensare fosse echeggiato praticamente da tutti gli altri, saresti abbastanza convinto di aver ragione anche tu.


Ben profondo e abbastanza lungo da leggere per rimandare facendo un vero lavoro per un po '!
DarenW,

6
Roba molto interessante. Hai qualche fonte?
Mason Wheeler,

4

Fidati del tuo intuito. Se sei un buon professionista, significa indipendentemente dalla tua "intelligenza" - sinistra o destra - le cose che i cervelli di sinistra fanno consapevolmente che puoi fare intuitivamente. Alla fine è la stessa cosa. Purtroppo non controlliamo il nostro subconscio, ma fa il lavoro più velocemente della nostra coscienza, se lo fa affatto. Queste intuizioni intuitive che escono dal nulla sono esattamente il risultato di calcoli subconsci.

Oh, e potresti fallire, è troppo inaffidabile. Ma dal momento che hai chiesto ...;)


2

Penso anche visivamente e i dettagli della tipografia mi tormentano.

Termini di Google: sito della dislessia britannica Stili di apprendimento: pensiero spaziale visivo, apprendimento integrale.

Concetti prima, consigli dopo

  1. Le persone con il cervello giusto immaginano tutto nei loro "occhi della mente".
  2. Quando la visualizzazione corrisponde bene alla realtà, il lavoro è facile
  3. I pensatori con cervello destro che non fanno bene il pensiero con cervello sinistro devono fare affidamento sulla visualizzazione
  4. Gli studenti retti che imparano tutto imparano subito "aha!" quindi adattare i dettagli al costrutto mentale. Hanno bisogno della panoramica PRIMA, quindi dei dettagli.
  5. Senza una visione d'insieme del contesto, i dettagli fluttuano nel vuoto, non collegati negli occhi della mente, quindi è necessario utilizzare la memorizzazione della forza bruta. Molto difficile per il giusto.

CONSIGLI che mi hanno aiutato:

  • 1 Utilizzare Colore per distinguere le parti della sintassi
    1. scrivi lo pseudocodice del codice di cui stai eseguendo il debug: lo fa, quindi vai qui ed etichetta le sezioni di codice corrispondenti
    2. se gli oggetti fossero, diciamo, animali reali, avrebbero abitudini e comportamenti previsti. Questo è un modo più facile di visualizzare il modo di pensare al codice.
    3. Immagino il codice come una storia con pseudicode come le mie note e quindi seguo il processo.

  • Quale sezione risolvere successivamente?

  • Il mio flusso di lavoro

  • Chi vive lì? (processo, connessioni, dati, ecc.)

  • cosa devono fare? (funzione) OK

    ok

  • codificalo da qualche parte può essere sintassi / controllo ortografico OK copia e incolla

  • Test

    Risultato -> funziona? Sì, continua

    No? I personaggi devono recitare Amleto dove tutti muoiono.

  • Ritorna all'ambiente

  • lasciato fuori qualcosa ?, errori sysntax
  • ha bisogno di una connessione
  • necessita di dati
  • il codice di errore ha significato?
  • funziona in un'altra parte del codice?
  • Problemi con la versione?
  • dovrebbe funzionare
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.