Quali sono gli elenchi di Pattern e Principi che un programmatore deve/dovrebbe sapere?

Question

Ho fatto il codice per alcuni anni e sento ancora che la mia conoscenza non è abbastanza ampia da diventare un professionista. Ho studiato alcuni libri relativi a modelli di design, ma so che ce ne sono molti altri.

Quindi qualcuno potrebbe elencare i modelli ei principi che ritieni siano utili per imparare a diventare un programmatore migliore e più professionale?

Lingue di programmazione Lavoro su: C#, Ruby, Javascript.

Answer 1

Penso che il modo migliore sia imparare un sacco di linguaggio. LISP, Scheme, Python, Smalltalk, Erlang, Prolog, Eiffel e molti altri

E costruire cose con loro.

Answer 2

La conoscenza enciclopedica dei modelli di progettazione non ti porterà da nessuna parte. Un sacco di esperienza li applicherà. Questo ti insegnerà quando usarli e quando no.

Detto questo, il libro originale Design Patterns è ancora uno dei miei preferiti. Prendi altri modelli mentre vai avanti.

Answer 3

Alcune delle competenze più indipendenti dalla lingua che sto attualmente apprendimento/lavoro verso per migliorare il mio codice nel suo complesso.

• scrittura pulita, leggibile e mantenibile codice
• Rifattorizzare
• progettazione oggetto proprio per le lingue OOP
• usare correttamente un sistema di controllo del codice sorgente corretta. Sourcesafe non conta: D
• Test unitario & sviluppo basato su test
• Applicazione di modelli di progettazione in modo corretto. Imparare loro è una cosa, imparare quando e dove applicarli è molto più complicato.

Alcuni link per prenotare domande recommnendation @ SO:

• What are the best design patterns books you have read?
• Help me pick a book on design patterns, refactoring, and/or testing
• Books that will cover TDD, DDD and Design Patterns in .NET
• Best books about TDD
• Best design patterns book for a beginer?
• C# Design Patterns Book
• Good C# Unit testing book

E, naturalmente, il Pragmatic Programmer books come detto nel precedente commento.

Answer 4

Martin Fowler's Patterns of Enterprise Application Architecture per creare un vocabolario condiviso con altri sviluppatori (ad es. Repository, Active Record, Domain Model, Unit of Work).

Douglas Crockford's Javascript: The Good Parts per capire veramente come funziona JavaScript.

E mi piacerebbe davvero entrare in TDD (Test Driven Development). Ci sono un sacco di buoni libri su TDD, ma se stai facendo lo sviluppo di brownfield (che la maggior parte di noi è), ti consiglio davvero lo Working Effectively with Legacy Code di Michael Feather.

E infine il libro che mostra come può essere refactored e pulito il codice: Uncle Bob's Clean Code.

Answer 5

Oltre alla scrittura del codice, è necessario provare anche codice. Ad esempio, scarica il codice da progetti open source, prova ad armeggiare con esso e capisci cosa sta facendo e perché. Oppure prova a rivedere il tuo codice da un progetto precedente. Cosa faresti diversamente ora? Riesci ancora a capire perché l'hai costruito come hai fatto?

Si potrebbe anche voler esaminare alcune delle pratiche che sono venuti fuori dalla comunità agile. Soprattutto Test Driven Development viene in mente come un ottimo modo per migliorare la qualità del tuo codice.

Answer 6

I principi sono i punti in cui iniziare, con gli schemi che si avvicinano di un secondo.

Principi: C'è tutta una serie, ma questi sono quelli che ricevo chilometraggio pratico da:

• Single responsibility principle (SRP)
• Separation of Concerns (SoC)
• Interface segregation principle (ISP)
• Open/closed principle

Un sacco di questi (quando raggruppati insieme lei) sono noti come SOLID (progettazione orientata agli oggetti).

Patterns:

• miei biggets preferito da un miglio è il Dependency Inversion Principle (DIP), anche comunemente noto come (o almeno molto simile a) Inversion of control (IOC). È molto utile per astrarre le implementazioni di accesso ai dati dietro le interfacce. Martin Fowler lo chiama un nome diverso (mi dispiace non avere la mia copia di "Patterns of Enterprise Application Architecture" di fronte a me).
• Lazy Load è anche utile.
• Factory pattern è molto noto, per una buona ragione.
• Facade pattern mi ha anche aiutato a stare fuori dai guai.

Wikipedia ha una buona lista di Software design patterns, presumendo che tu non l'abbia ancora visto.

Un'ultima cosa da tenere a mente è che ci sono tre tipi base di modelli (più una quarta categoria per multi-threaded/concorrenza); può aiutare solo da sapere su queste categorie e per loro tenere a mente quando si sta facendo qualcosa, essi sono:

• Creazionale
• strutturale
• comportamentali

Answer 7

strumenti di mastering (ad esempio, programmazione paradigmi, schemi, controllo del codice sorgente, unit test ...) è essenziale, ma non è sufficiente definirsi un "professionista": IMHO, il marchio di un programmatore veramente professionale è la capacità di capire di cosa ha bisogno il suo cliente. Sfortunatamente, questo tipo di conoscenza è molto difficile da imparare da un libro.

Answer 8

Penso, Tutti gli schemi descritti nel libro Head First Design Pattern sono il minimo che un designer/programmatore deve conoscere. Suggerisco questo libro per iniziare a imparare modelli di design. Un altro libro, Design Pattern Work Book è anche utile per esercitarsi.