Il mio progetto proposto è in genere peggiore di quello del mio collega: come posso migliorare? [chiuso]

Sto programmando da un paio d'anni e in genere sono bravo quando si tratta di risolvere problemi e creare script di dimensioni medio-piccole, tuttavia non sono generalmente bravo a progettare programmi su larga scala in modo orientato agli oggetti. Poche domande

1. Di recente, un collega che ha lo stesso numero di anni di esperienza e io stavamo lavorando su un problema. Stavo lavorando su un problema più lungo di lui, tuttavia, ha trovato una soluzione migliore e alla fine useremo il suo design. Questo mi ha davvero colpito. Ammetto che il suo design è migliore, ma volevo trovare un design buono come il suo. Sto anche pensando di lasciare il lavoro. Non sono sicuro del perché, ma all'improvviso mi sento sotto pressione, ad esempio cosa penserebbero i giovani di me e così via? È normale? O sto pensando un po 'troppo a questo?

2. Il mio lavoro prevede la programmazione in Python. Cerco di leggere il codice sorgente, ma come pensi di potermi migliorare le capacità di progettazione? Ci sono buoni libri o software che dovrei studiare?

Per favore, illuminami. Apprezzerò molto il tuo aiuto.

Penso che questo sia un segno molto positivo delle tue capacità. È molto più comune per le persone che hanno difficoltà a trovare il design "migliore" in un team di essere completamente incapaci di riconoscere perché un altro design è migliore.

Hai due punti di forza davvero straordinari (e sorprendentemente rari):

• Sei in grado di valutare obiettivamente i tuoi progetti contro gli altri
• Hai il desiderio e fai uno sforzo per rendere i tuoi progetti ottimali

Hai solo un paio d'anni e hai ancora molta strada da fare, ma con questo atteggiamento ci arriverai sicuramente, ma non arrenderti; ci occupiamo tutti di arretramenti mentali come questo. Ogni volta che ne ho la possibilità, mi piace collegare i Principi di progettazione (NON gli stessi dei modelli di progettazione) e penso che questo sia un esempio perfetto di dove sono utili. Studiali e fai pratica applicandoli nei tuoi progetti, prima di sapere che avrai fatto un altro passo avanti in questo senso.

Alla fine, ricorda, progettare è difficile. Ogni giorno abbiamo a che fare con astrazioni complesse di alto livello, per crearle dal nulla, farle funzionare bene e la facilità di utilizzo da parte dei colleghi è un compito estremamente difficile. Ci vuole pratica, per anni .

Quindi chin up e ricorda: ci sono un sacco di persone là fuori che non sono in grado di valutare due design e di riconoscerne uno come preferibile rispetto ad un altro, quanto pensi che stiano andando d'accordo nella creazione di buoni design?

Modifica:
'altro suggerimento, dopo aver approfondito i principi e aver praticato un po' la loro applicazione, penso che ci sia un'altra gemma da un'altra domanda qui che parla del valore di studiare una varietà di lingue che hanno scopi e regole diverse:

Idealmente, ogni programmatore dovrebbe conoscere una lingua di ogni classe. Cosa potresti imparare:

1. Un linguaggio mainstream OOP tipizzato statico: Java, C # (utilizzato principalmente nel software aziendale) e C ++ (programmazione di sistema e applicazioni desktop complesse)
2. Un linguaggio OOP basato su prototipo: Javascript (programmazione web lato client)
3. Un linguaggio procedurale: C (software integrato e programmazione del sistema)
4. Un linguaggio funzionale: Haskell, ML o Lisp (i linguaggi funzionali sono utili per software altamente parallelizzati).

Un linguaggio di programmazione logica (Prolog) probabilmente non è così utile nell'industria, essendo utilizzato principalmente nella ricerca nell'IA.

Ciò contribuirà ad ampliare la varietà di idee che vengono in mente quando si cerca di progettare una soluzione.

1. Questo è assolutamente normale per più persone che escogitano progetti di diversa qualità. In passato sono stato invitato a giudicare le competizioni nella progettazione di software, quindi ne ho assistito in prima persona: anche i progetti più semplici hanno portato a soluzioni di qualità drasticamente diversa, tutte provenienti da persone intelligenti ed esperte.
2. La lettura del codice sorgente è di livello troppo basso per aiutarti a migliorare le tue capacità di progettazione: il codice affronta la complessità a un livello inferiore rispetto alla progettazione generale.

Il modo migliore per migliorare la progettazione del software è progettare il software ^* . Un modo per farlo è guardare i concorsi di progettazione: TopCoder ha un archivio di oltre 100 progetti di componenti, completo di documentazione di progettazione UML e implementazioni in Java e / o C #. Prendi un componente finito che ti piace, leggi le specifiche dei requisiti e prova a trovare un design originale per soddisfare i requisiti. Trascorri un'ora o due pensando al problema e disegnando un diagramma di classe, quindi apri il disegno vincitore e leggi cosa ha fatto l'autore. Confronta il suo design con il tuo, trova le differenze e vedi se il tuo design è migliore. Controlla la scheda punteggi della competizione per vedere come i giudici hanno valutato il design. Questo ti darà il feedback di cui hai bisogno per decidere come migliorare le tue capacità di progettazione.

Beh, non lasciare il tuo lavoro. È meglio lavorare con qualcuno che abbia capacità migliori di te, in modo da poter imparare da lui o lei.

Guarda il design migliore e determina perché è meglio. Guadagna dal design accettato e pensa ai modi in cui potresti applicare un design simliar in altre situazioni. Una volta che sai perché è meglio del tuo design, allora sai cosa mistatke non fare la prossima volta che fai un design. Parla con l'altro sviluppatore e chiedi come è arrivato al design.

Per migliorare le capacità di progettazione, la cosa migliore da fare è creare progetti, quindi essere brutale con te stesso nel valutarli e determinare come possono essere migliorati. Ponetevi domande come: Funzionerà e soddisferà i requisiti in tutti gli aspetti, è mantenibile, come sarò in grado di testarlo, causerà problemi di prestazioni, quanto è probabile che il requisito cambi e quanto bene il design essere in grado di gestire il cambiamento. Leggi i modelli di progettazione e poi prova ad applicarli ai tuoi progetti. Refactor senza pietà dopo aver escogitato un design iniziale. Se stai progettando un database insieme all'applicazione, leggi ampiamente sulla normalizzazione e l'ottimizzazione delle prestazioni del db, imparerai molto sulla progettazione del database se impari come far funzionare un database in modo più efficace ed efficiente. Per le applicazioni, pensa ai principi DRY e SOLID nel progettare. Leggi gli antipasti per sapere quali cose evitare di fare.

Riconoscere un design migliore è un'abilità importante. Dovresti incoraggiarlo mentre segui alcuni dei suggerimenti precedenti riguardanti lo sguardo ai disegni.

Su quali criteri hai giudicato meglio l'altro design? È stato più semplice e più facile da capire? Ha fornito un vantaggio in termini di prestazioni? Era più estensibile? Esistono molti principi di progettazione come decomposizione, astrazione, occultamento delle informazioni e modularità dei componenti che è possibile utilizzare per giudicare i progetti e che si potrebbero già riconoscere.

• Cerca di nominare i tuoi criteri, comprenderli, espanderli e riutilizzarli mentre guardi altri progetti. Quando progetti le cose da te, rendi parte del tuo processo utilizzare questi criteri e misurare consapevolmente i tuoi progetti rispetto a loro. Quindi, preparati a modificare o eliminare completamente il tuo progetto se non soddisfa i tuoi criteri.

Otterrai idee su diversi principi per i progetti da alcune delle seguenti fonti: http://www.cs.wustl.edu/~schmidt/PDF/design-principles4.pdf Progettazione del software su wikipedia Google "Principi di progettazione del software"

• Comprendere diversi modelli per la progettazione di software, come la progettazione orientata agli oggetti o la progettazione funzionale o la progettazione di analisi strutturata. Questi possono essere modi di pensare completamente diversi da cui affrontare un compito progettuale e ognuno di essi ha aree in cui eccellono. Impara questi come strumenti per la tua cassetta degli attrezzi. http://userpages.umbc.edu/~khoo/survey2.html

• Assicurati di separare la progettazione dall'implementazione, prova a tracciare le cose che vedi come buone progettazioni, per separare il linguaggio e le specifiche dell'implementazione dai principi di progettazione di livello superiore. E per sviluppare il tuo "occhio progettuale" e le tue capacità comunicative.

• Infine, ma forse soprattutto, leggere ampiamente è un ottimo strumento: ci sono molte cose interessanti, dai frattali all'analisi bayesiana, dalla logica fuzzy all'elaborazione del linguaggio naturale, che possono fornire foraggio per idee che emergeranno in seguito e inaspettatamente. Con il web puoi esaminare gli argomenti in lungo e in largo, solo per tuo divertimento ed edificazione e ne trarranno beneficio. Non è necessario diventare esperti, basta avere familiarità con i termini e le idee.

Divertiti - non farlo se non ti piace almeno un po '!

Bene, hai già fatto il primo passo. Ammetti di avere qualcosa da imparare, che il lavoro del tuo collega è migliore del tuo e che vuoi imparare e migliorare.

Il secondo passo è analizzare. Guarda il suo lavoro e non solo dire che è meglio; capire perché è meglio. Cerca dettagli specifici e punti che ha fatto meglio.

Una volta capito, estrai i principi che stanno dietro. Poni domande come queste:

• Che dire di questo design è meglio del mio design?
• Questo punto è qualcosa di specifico per questo disegno o è un principio generale che potrebbe essere applicato ad altri disegni in futuro?
• Se è un principio generale, quali sono i suoi limiti? Quando è una buona idea non fare le cose in questo modo? (Questo è molto importante. Ti impedisce di trattare qualche idea utile come un martello d'oro , anche in casi inappropriati.)

Prova a capire le cose da solo, perché interiorizzerai meglio le idee se ti inventassi la catena di ragionamento che ti ha portato alla conclusione tu stesso, ma parli anche con il tuo collega per assicurarti di ottenere le cose giusto. (Dopo tutto non vuoi fare errori nel tuo ragionamento e interiorizzare un cattivo principio.) E sentiti libero di chiedere aiuto al tuo collega se non riesci a capire le cose. La programmazione è una disciplina in cui l'umiltà tende a essere rispettata e molti programmatori coglieranno l'occasione per insegnare a qualcuno qualcosa di nuovo, il che è probabilmente una grande parte del motivo per cui StackOverflow è diventato così grande così in fretta.

Vorrei anche aggiungere (oltre alle ottime risposte) che c'è di più oltre a "Può creare un design migliore di me". Le altre risposte si concentrano su come migliorare in Design, che è tutto e buono ... ma ...

Scommetto che TU puoi fare qualcosa di meglio del tuo collega. Non per creare una partita pissing o altro (puoi fare Y meglio? Fottiti, posso fare X meglio!), Ma per sottolineare la verità che tutti hanno punti di forza e di debolezza.

Nel mio lavoro ci sono 4 sviluppatori. Ci sono momenti in cui i due "programmatori" principali possono creare cose che mi lasciano solo nella polvere. Mi fa girare la testa cercando di avvolgere la mia testa attorno alle loro creazioni.

Ma io sono molto più bravo in SQL e negli script da riga di comando di loro, e sono in grado di automatizzare le cose che LASCIO li lascia in polvere.

Sono meglio di me? In alcune zone è sicuramente. Diavolo, in molte aree lo sono: sono lo sviluppatore junior nel mio negozio di gran lunga e individualmente hanno anni di esperienza su di me. Nonostante quegli anni di esperienza, in alcune aree sto meglio di quanto non lo siano nemmeno loro.

Smetti di concentrarti sul fatto che qualcuno è migliore in X di te. Quella persona, senza provarci o nemmeno pensarci, potrebbe essere in grado di progettarti anche dopo che ti sarai allenato per i prossimi 10 anni. Non che non dovresti lavorare per correggere le tue debolezze, ma ricorda che per ogni forza c'è una debolezza.

Concentrati su entrambi - punti di forza e di debolezza - di te e dei tuoi collaboratori.

In ogni aspetto della vita troverai persone che non sono buone come te, così come persone che sono migliori di te, specialmente dopo solo "un paio d'anni" di esperienza.

Devi imparare da tutti.

Non stare male. Forse il tuo collega è naturale. Dovresti congratularti con lui sinceramente e imparare il più possibile da lui.

Non lasciare che il professionista gelosamente si intrometta tra te e l'opportunità di imparare.

1. Un paio d'anni non è poi così tanto. E poi ci sono persone con viste progettuali di alto livello migliori o peggiori. Ad esempio, ho conosciuto persone in grado di scrivere algoritmi complessi per programmi di basso livello in un batter d'occhio ma incapaci di comprendere il design di livello superiore e concetti come coesione e dipendenze. Tuttavia questo non è uno stato di fatto. Entrambi puoi migliorare il design di livello superiore (leggi alcuni libri, prova qualche trucco a casa, ecc.) E potresti anche scoprire che in altre aree della programmazione il tuo compagno programmatore è meno bravo. Inoltre, se pensi di avere lo stesso livello sia in termini di esperienza che di conoscenze tecniche, ciò potrebbe aver comportato una situazione casuale. La prossima volta forse avrai idee di design migliori. Inoltre, invece di lasciare il tuo lavoro, cogli questa opportunità e impara dal tuo collega. La prossima volta, fai un disegno insieme, cerca di catturare i suoi segreti, i suoi pensieri. La programmazione è come un mestiere, si impara facendo e guardando gli altri farlo.

2. Le capacità di progettazione arrivano principalmente con esperienza e dopo aver letto alcuni libri importanti. Ti consiglierei i seguenti:

   • Robert C. Marting - Principi, modelli e pratiche agili (ci sono 2 versioni, una in Java e una in C #. Non importa quale scegli, le idee e i principi possono essere applicati a qualsiasi oggetto orientato - e non solo - codice sorgente)
   • Than, Robert C. Marting ha altri 2 libri interessanti: Clean Code e The Clean Coder
   • Anche se Martin copre tutti i modelli di design moderno nel suo primo libro, vuoi cercare il libro dei modelli di design originale della Gang of Four.
   • Infine, ci sono altri libri molto apprezzati oggi: software orientato agli oggetti in crescita guidato da test, o refactoring di M. Feathers (credo) o scrittura di casi d'uso efficaci di A. Cockburn e pochi altri che scoprirai lungo la strada.

Nessuno di questi libri è un proiettile magico, ma leggere i primi 2 consigli probabilmente cambierà la tua visione e percezione sulla programmazione per sempre.

Non lasciare che ti arrivi. Se hai anni di esperienza nella correzione di bug e nella realizzazione di piccoli programmi, è questo che eccellerai. Il tuo collega probabilmente ha anni di esperienza nella progettazione di progetti più grandi.

Avere familiarità con i bit sottostanti è incredibilmente utile, ma se vuoi migliorare la progettazione, dovrai progettare alcuni progetti. Ripeti finché l'abilità non affonda.

In breve, "anni di esperienza" non è sempre equivalente. Fai in modo che i tuoi anni valgano qualcosa.

"Migliorare" implica spesso misurare i tuoi progetti o il tuo codice rispetto a qualcosa / qualcuno di meglio, confrontando attentamente ciò che è diverso, imparando da quelle differenze e cercando continuamente di migliorare i tuoi progetti futuri basati su quello. Sentirsi troppo male nello scoprire che è necessario saperne di più rallenterà questo processo benefico. Se ti sposti in un posto dove non ci sono persone (o altre risorse) che a volte o sempre possono offrirti un confronto migliore, potresti perdere questa opportunità di apprendere e rallentare meglio il tuo processo di scommesse.