Qual è la differenza tra un principio e una buona pratica?

Non considerarlo come un principio contro le migliori pratiche. Nel processo di scrivere il mio libro su MVVM (direi che era una spina spudorata ma non è ancora uscito), ho escogitato un'analogia. Proprio come nell'arte ci sono stati vari movimenti nel corso dei secoli, ci sono alcuni movimenti all'interno dell'ingegneria del software. Proprio come è possibile identificare una cattedrale gotica attraverso i contrafforti e i rosoni volanti o un dipinto impressionista attraverso le sue pennellate visibili e la composizione aperta, in modo da poter identificare il codice che segue un determinato movimento del software cercando alcuni elementi.

Il movimento MVVM ha il modello di vista come il fulcro con codice minimo dietro, funzioni incapsulate nei comandi e messaggistica disaccoppiata tramite un aggregatore di eventi. C'è una bellezza nel modo in cui questi componenti sono strutturati.

Chi segue Domain Driven Design crea oggetti di dominio ricchi con ignoranza di persistenza e logica incorporata nel nucleo degli oggetti.

I sostenitori di CQRS separano i loro modelli di dominio in un modello di Query e Command, indicato anche come modello di lettura e modello di scrittura. A loro piace utilizzare le chiamate asincrone tramite un bus dei messaggi che aggiorna l'archivio transazionale e l'archivio query nello stesso momento. E preferisci un concetto chiamato consistenza finale.

Le "migliori pratiche" di questi movimenti non sono applicabili a livello globale, ma più o meno attributi che sono coerenti con il movimento. Man mano che i nuovi movimenti salgono al dominio ei vecchi movimenti svaniscono, non saranno così importanti, ma ciò non significa che le tecniche di un movimento non saranno utili con una successiva.

Quindi cos'è un principio

I principi, come detto nell'articolo, sono applicabili a livello globale indipendentemente dal movimento. Pensa a Uncle Bob's principi SOLID . O la Gang of Four's Composition over Ereditarietà . Questi principi sono applicabili quasi ovunque. Quasi la parola chiave.

Naturalmente, non è possibile applicare i principi OO alla programmazione funzionale. Beh, puoi ma assumono forme diverse. E una volta che hai abbastanza esperienza, saprai quando un principio non si applica. (Saprai se hai abbastanza esperienza se non devi chiedere "Si applica qui", saprai solo che non guarda Dreyfus Model of Skill Acquisition a livello di esperti, non hai bisogno dei principi ... sono lì ma non ti affidi per prendere decisioni).

Allo stesso modo, una volta che hai raggiunto l'esperienza usando un certo approccio o uno stile di programmazione, inizi ad aggiungere il tuo tocco personale a quello stile. Ad esempio, io e alcuni altri pionieri MVVM contemporaneamente e indipendentemente "abbiamo scoperto" il pattern DelegateCommand (e l'abbiamo chiamata la stessa cosa tranne Josh Smith che ha chiamato il suo RelayCommand che è praticamente un sinonimo di Delegato).

In breve

I principi sono la guida per sviluppatori meno esperti che li aiutano a prendere decisioni tramite le regole.

"Best practice" o stili di codice sono approcci allo sviluppo che forniscono coerenza e familiarità per coloro che seguono tale stile

Saprai quando è opportuno ignorare ciascuno quando "lo sai senza saperlo".

What separates a principle from a best practice (if anything)?

La pratica sarà di solito specifica e concreta dove gli esempi dell'articolo includeranno il controllo del codice sorgente, il test unitario, l'integrazione continua e altre idee che mentre il concetto può essere astratto, ci sono strumenti specifici che potrebbero essere usati per dimostrare che questo è in uso. Ad esempio, Subversion può essere utilizzato per il controllo del codice sorgente, nUnit per il test dell'unità, Cruise Control.Net per l'integrazione continua.

Un principio, d'altra parte, sarebbe più nebuloso e quindi non così tangibile. The Agile Manifesto che elenca queste quattro idee:

• Individui e interazioni su processi e strumenti
• Software di lavoro su documentazione completa
• Collaborazione con il cliente per la negoziazione del contratto
• Risposta al passaggio successivo a un piano

Quindi, mentre si può fare un esempio specifico e osservare se questi vengono applicati, non c'è proprio lo strumento da estrarre per mostrare: "Ehi, abbiamo un software funzionante su una documentazione completa perché usiamo X!" mentre le pratiche che ho notato sopra hanno strumenti che potrebbero essere una cartina di tornasole.

How can you distinguish between the two, and how can you determine when it's appropriate to ignore either?

A mio parere è un livello di dettaglio. In che misura uno desidera entrare nell'applicazione di un'idea? Ad un livello elevato ci sono principi e ad un livello inferiore ci sono pratiche.

Per quanto riguarda il momento in cui è opportuno ignorare entrambi, è qui che devi considerare caso per caso. Ad esempio, se sto scrivendo uno script che verrà utilizzato per generare alcuni dati di test che probabilmente userò una volta, è davvero utile per me passare ore a pianificarlo, costruire test unitari e applicare un sacco di overhead extra quando quello che potrei fare è passare la mezz'ora a scrivere lo script, eseguirlo e poi impegnare i miei dati quando ho finito. Questo si concentra un po 'di più sulle pratiche in quanto sono più facili da vedere dove valga la pena di applicare le cose poiché a volte su piccole cose, potrebbe non valere la pena di impostare varie pratiche che sarebbero utili in altri ambienti. I principi possono essere un po 'più difficili da dare un esempio specifico.

Come conquistare gli amici e influenzare le persone è indicato nell'articolo come avente principi e qui è qualcosa da prendere in considerazione i modi per conquistare le persone al tuo modo di pensare:

Twelve Ways to Win People to Your Way of Thinking

1. The only way to get the best of an argument is to avoid it.
2. Show respect for the other person's opinions. Never say "You're Wrong."
3. If you're wrong, admit it quickly and emphatically.
4. Begin in a friendly way.
5. Start with questions to which the other person will answer yes.
6. Let the other person do a great deal of the talking.
7. Let the other person feel the idea is his or hers.
8. Try honestly to see things from the other person's point of view.
9. Be sympathetic with the other person's ideas and desires.
10. Appeal to the nobler motives.
11. Dramatize your ideas.
12. Throw down a challenge.

Sebbene questa sia una buona lista, vale la pena notare che alcune idee qui possono essere un po 'contrastanti. Ad esempio, c'è un modo amichevole per lanciare una sfida? Forse ci sono modi più amichevoli ma nel cercare di convincere qualcuno ad affrontare una sfida, c'è qualcosa da dire per far sì che la persona si stiracchi. C'è un altro insieme di idee nel libro che potrebbe valere la pena di rivedere anche qui:

Be a Leader: How to Change People Without Giving Offense or Arousing Resentment

1. Begin with praise and honest appreciation.
2. Call attention to people's mistakes indirectly.
3. Talk about your own mistakes before criticizing the other person.
4. Ask questions instead of giving direct orders.
5. Let the other person save face.
6. Praise every improvement.
7. Give the other person a fine reputation to live up to.
8. Use encouragement. Make the fault seem easy to correct.
9. Make the other person happy about doing what you suggest.

Nota come alcuni di questi sono simili. Il numero 7, "Dare all'altra persona una buona reputazione per cui vivere fino a", è simile al numero 12 nella prima lista, "lancia una sfida", che può dimostrare un principio su come molte persone hanno un istinto di combattimento interiore che può essere usato a volte Allo stesso modo, nota come il numero 3 di ciascuna lista riguarda l'ammissione degli errori che potrebbero riguardare un principio di umiltà.