Il mio design proposto è in genere peggiore di quello del mio collega - come faccio a migliorare? [chiuso]

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 una squadra per essere completamente incapaci di riconoscere perché un altro design è migliore.

Hai due punti di forza davvero eccezionali (e sorprendentemente rari) per te:

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

Sei solo un paio d'anni e hai una lunga strada da percorrere, ma con questo atteggiamento ti arriverà sicuramente, semplicemente non ti arrendere; ci occupiamo tutti di arretramenti mentali come questo. Ogni volta che ho la possibilità mi piace collegare Principi di progettazione (NON lo stesso dei modelli di progettazione ) e penso che questo sia un esempio perfetto di dove sono utili. Studili e praticali applicandoli nei tuoi progetti, prima di sapere che hai fatto un altro passo avanti in questo senso.

Alla fine della giornata ricorda, progettare è difficile. Abbiamo a che fare ogni giorno con complesse astrazioni di alto livello, per creare queste cose dal nulla, farle funzionare bene e il facile utilizzo da parte dei colleghi è un compito estremamente difficile. Ci vuole pratica, per anni .

Quindi rilassati e ricorda: c'è un gruppo di persone là fuori che non è in grado di valutare due progetti e in realtà lo riconoscono come preferibile rispetto a un altro, quanto pensi che stiano andando avanti nella creazione di buoni progetti?

Modifica
'nother tip, dopo aver analizzato i principi e 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 diversi scopi e regole:

Ideally, every programmer should know a language from each class. What could you learn:

1. A static typed OOP mainstream language: Java, C# (mostly used in enterprise software) and C++ (system programming and complex desktop applications)
2. A prototype-based OOP language: Javascript (client side web programming)
3. A procedural language: C (embedded software and system programming)
4. A functional language: Haskell, ML or Lisp (functional languages are good for highly parallelized software).

A logic programming language (Prolog) probably is not that useful in industry, being used mostly in research in AI.

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

1. Questo è assolutamente normale per più persone che escogitano disegni di qualità diversa. Sono stato invitato in passato a giudicare le competizioni nel design del software, quindi ne sono stato testimone in prima persona: anche i progetti più semplici hanno portato a soluzioni di qualità drasticamente diversa, tutte provenienti da persone intelligenti ed esperte.
2. Leggere il codice sorgente è troppo basso per aiutarti a migliorare le tue capacità di progettazione: la complessità degli indirizzi di codice al livello inferiore rispetto alla progettazione generale.

Il modo migliore per migliorare la progettazione del software è progettare il software ^* . Un modo per farlo è guardare le competizioni di design: TopCoder ha un archivio di oltre 100 progetti di componenti, completo di documentazione di progettazione UML e implementazioni in Java e / o C #. Raccogli un componente finito che ti piace, leggi le specifiche dei requisiti e prova a creare un design originale per soddisfare i requisiti. Passa un'ora o due a pensare al problema e ad abbozzare un diagramma di classe, quindi apri il disegno vincente e leggi cosa ha fatto l'autore. Confronta il suo design con il tuo, individua le differenze e verifica se il tuo design è migliore. Controlla la scheda punteggi della competizione per vedere come 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 ha competenze migliori di te, in modo che tu possa imparare da lui o da lei.

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

Per migliorare le capacità di progettazione, la cosa migliore da fare è creare disegni, poi essere brutali con te stesso nel valutarli e determinare come possono essere migliorati. Porsi domande come: Funzionerà e soddisfa i requisiti in tutti gli aspetti, è mantenibile, come potrò testarlo, causerà problemi di prestazioni, quanto è probabile che il requisito cambi e quanto bene sarà il design essere in grado di gestire il cambiamento. Leggi i modelli di design e poi prova ad applicarli ai tuoi progetti. Refactor senza pietà dopo aver inventato un progetto iniziale. Se state progettando un database insieme all'applicazione, leggete approfonditamente la normalizzazione e l'ottimizzazione delle prestazioni del db, imparerete molto sulla progettazione del database se imparerete come far funzionare un database in modo più efficace ed efficiente. Per le applicazioni, considera i principi DRY e SOLID nel tuo progetto. Leggi degli antipodi per sapere cosa evitare di fare.

Riconoscere un design migliore è un'abilità importante. Dovresti incoraggiarlo mentre segui alcuni dei suggerimenti precedenti relativi alla visualizzazione dei progetti.

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

• Cerca di assegnare un nome ai criteri, capiscali, espanderli e riutilizzarli mentre guardi altri progetti. Quando progetti le cose da solo, rendi parte del tuo processo per usare quei criteri e misuri consapevolmente i tuoi disegni contro di loro. Quindi, sii pronto a modificare completamente o a eliminare il tuo progetto se non soddisfa i tuoi criteri.

Riceverai idee su diversi principi per i progetti da alcune delle seguenti fonti: link Progettazione software su wikipedia "Principi di progettazione del software" di Google

• Comprendi 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 mentalità completamente diverse da cui affrontare un compito di progettazione e ciascuno di essi ha aree in cui eccellono. Impara come strumenti per la tua casella degli strumenti. link

• Assicurati di separare la progettazione dall'implementazione, prova a schematizzare le cose che vedi come buone progettazioni, per separare la lingua e le specifiche di implementazione dai principi di progettazione di livello superiore. E per sviluppare il tuo "occhio di progettazione" e le capacità di comunicazione.

• Ultimo, ma forse la cosa più importante, la lettura ampia è uno strumento molto buono - ci sono molte cose interessanti dai frattali all'analisi bayesiana a Fuzzy Logic all'elaborazione del linguaggio naturale, che può fornire il foraggio per le idee che emergeranno in seguito e inaspettatamente. Con il web puoi esaminare argomenti in lungo e in largo, solo per divertimento ed edificazione e ne trarrà beneficio. Non è necessario diventare esperti, ma solo familiarizzare con termini e idee.

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

Bene, hai già fatto il primo passo. Ammetti che hai 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 limitarti a dire che è meglio; capire perché è meglio. Cerca dettagli e punti specifici che ha fatto meglio.

Una volta capito questo, estrai i principi dietro di esso. Poni domande come queste:

• Che dire di questo design è migliore del mio design?
• Questo punto è qualcosa di specifico per questo disegno o è un principio generale che potrebbe essere applicato ad altri design 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 considerare un'idea utile come golden hammer , anche in casi inappropriati.)

Cerca di capire le cose da solo, perché meglio interiorizzi le idee se ti viene in mente la catena di ragionamenti che ti ha portato alla conclusione da solo, ma parli anche con il tuo collega di lavoro per essere sicuro che tu sia " sto facendo le cose per bene. (Non vuoi fare errori nel tuo ragionamento e interiorizzare un cattivo principio, dopotutto.) 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 colgono l'occasione per insegnare a qualcuno qualcosa di nuovo, il che è probabilmente una grande parte del perché StackOverflow è diventato così grande così veloce.

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

Scommetto che puoi fare qualcosa di meglio del tuo collega di lavoro. Non creare un incontro di pissing o altro (puoi fare Y meglio? Vaffanculo, 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 volte in cui i due principali "programmatori" possono creare cose che mi lasciano solo nella polvere. Mi fa girare la testa cercando di avvolgere la mia mente intorno alle loro creazioni.

Ma io sono molto più bravo in SQL e nello scripting da riga di comando di quello che sono, e posso automatizzare roba che lascia LORO nella polvere.

Sono meglio di me? In alcune zone è decisamente. Al diavolo, in un sacco di aree sono - Sono lo sviluppatore junior del mio negozio di gran lunga e individualmente hanno anni di esperienza su di me. Nonostante questi anni di esperienza, sono migliore in alcune aree rispetto a quello che sono.

Smetti di concentrarti sul fatto che qualcuno è meglio a X di te. Quella persona, senza provarci o anche solo pensarci, potrebbe essere in grado di out-design anche dopo aver praticato 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 punti deboli - di te e dei tuoi colleghi di lavoro.

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

Devi imparare da tutti.

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

Non lasciare che i professionisti si intromettano gelosamente tra te e un'opportunità per imparare.

1. Un paio di anni non è poi così tanto. E poi ci sono persone con viste di design 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 design e concetti di livello superiore come la coesione e le dipendenze. Tuttavia questo non è uno stato di fatto. Entrambi puoi migliorare con il design di livello superiore (leggi alcuni libri, prova qualche trucco a casa, ecc.) E potresti scoprire che in altre aree di programmazione il tuo collega programmatore è meno bravo. Inoltre, se pensi di essere all'incirca allo stesso livello sia per esperienza che per conoscenza tecnica, questo potrebbe aver avuto fagiolo in una situazione casuale. La prossima volta potresti avere idee di design migliori. Inoltre, invece di lasciare il tuo lavoro, cogli l'occasione e impara dal tuo collega. La prossima volta, fai un disegno insieme, cerca di cogliere i suoi segreti, i suoi pensieri. La programmazione è come un mestiere, è appresa facendo e guardando gli altri farlo.

2. Le capacità di progettazione derivano principalmente dall'esperienza e dalla lettura di alcuni libri importanti. Ti consiglierei quanto segue:

   • Robert C. Marting - Agile Principles, Patterns and Practices (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 due libri interessanti: Clean Code e The Clean Coder
   • Anche se Martin copre tutti i modelli di design moderni nel suo primo libro, vuoi cercare il libro originale dei disegni della Gang of Four.
   • Infine, ci sono altri libri che sono 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 da A. Cockburn e pochi altri che scoprirai su la via.

Nessuno di questi libri è una bacchetta magica, ma leggere i primi due consigli probabilmente cambierà per sempre la tua visione e la tua percezione della programmazione.

Non lasciarti prendere da te. Se hai anni di esperienza nella risoluzione di bug e nella realizzazione di piccoli programmi, questo è ciò su cui eccellerai. Il tuo collega di lavoro probabilmente ha anni di esperienza nella progettazione di progetti più grandi.

Avere familiarità con i bit sottostanti è incredibilmente utile, ma se vuoi migliorare con il design, dovrai progettare alcuni progetti. Ripeti fino a quando l'abilità non si affonda.

In breve, "anni di esperienza" non è sempre equivalente. Vai a rendere i tuoi anni che valgono qualcosa.

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