Best practice o standard di progetto

Ho un modo di dire, e non so se nessun altro l'ha detto prima di me, ma mi piace pensare di averlo inventato.

"Seguire fedelmente le best practice non è una best practice."

Fondamentalmente, dipende. Se il tuo cliente non usa il controllo del codice sorgente, allora sì, questo è un grosso problema e IMO è una battaglia che vale la pena combattere soprattutto perché la risoluzione del problema costa un cliente $ 0 (git). Se qualcuno non usa la tua convenzione sui nomi, allora tendo a succhiarlo e ad andare con il cliente. C'è stata questa volta però, quando un client ha preceduto il prefisso di ogni nome di colonna in una tabella con il nome di tablatura. Le colonne sembravano letteralmente: Person_PersonID. Di nuovo, questo, IMO, è una battaglia che vale la pena combattere.

OK, in realtà, era peggio di così. Invece di chiamare la loro tabella degli elementi pubblicitari di budget "LineItems", in realtà la chiamavano "BudgetDepartmentProduct". Che, naturalmente, ha reso il PK del tavolo "BudgetDepartmentProduct_BudgetDepartmentProductID". hai per amarlo. Ovviamente, oggigiorno con cose come Linq to SQL, è abbastanza facile mettere un po 'di zucchero su quel mucchio di cacca e non interagire con quei nomi come programmatore. Ma questo progetto era invece centinaia di procedure memorizzate tagliate e incollate. Ho combattuto contro questo e ho perso. Questo è il motivo per cui fatturo a ore.

Quindi la tua risposta finisce per essere "dipende". Un ottimo consulente impara per esperienza quali battaglie combattere, e nella mia esperienza, la maggior parte dei clienti apprezza l'onestà se l'argomento è fatto in un modo che non danneggi l'ego o il morale della squadra. Ciò richiede il giudizio e la fiducia molte volte prima.

Se riesco a lavorare in un progetto che segue standard che non sono d'accordo, faccio due cose:

• Seguo lo standard in uso
• Io sostengo un modo migliore di lavorare

Spesso ci sono ragioni (più o meno ben fondate) perché il lavoro è fatto nel modo in cui è. Se è così, potrebbe benissimo avere senso, anche se potrei non essere completamente d'accordo. Se non ci sono ragioni ben fondate per la struttura data, trovo spesso che ci sia spazio per aiutare a introdurre modi migliori di lavorare.

Penso che dipenda dal fatto che le convenzioni e la coerenza funzionino. Se le pratiche attuali sono davvero contro le migliori pratiche, sicuramente avranno un impatto negativo percettibile? Se non lo sono - allora qual è la motivazione per il cambiamento?

Potrebbe accadere che alcune buone pratiche appagheranno visibilmente solo a più lungo termine. Ciò li rende più difficili da vendere se la convenzione e la coerenza forniscono ciò che è richiesto nel presente.

Personalmente ho una serie di pratiche alle quali mi piace lavorare e che spero di impiegare in qualsiasi squadra in cui mi trovo. Tuttavia, cerco di riconoscere il valore nel conformarsi alle pratiche esistenti se danno i risultati attesi e richiesti.

Un esempio classico è lo stile di formattazione del codice: il valore non è nello stile stesso (purché ragionevolmente ragionevole) - il valore è nel team che adotta uno stile standard.

In generale, sono d'accordo con la maggior parte dei punti già fatti. Ma vorrei rispondere ad alcune cose che non sono completamente d'accordo. Lungo la strada, penso che tesserò insieme una risposta interessante alla tua domanda.

Da risposta di Dave Markle :

"Blindly following best practices is not a Best Practice."

Le buone pratiche sono buone idee che funzionano nella maggior parte dei casi sulla maggior parte dei progetti e della maggior parte dei team. Generalmente, coprono idee che vorresti probabilmente mettere in atto in un progetto, ma ci sono anche momenti in cui sono inappropriati.

Un esempio di best practice è "usa sempre il controllo del codice sorgente". La cosa su cui devi concentrarti, almeno in questo esempio, non è l'uso del controllo del codice sorgente, ma i vantaggi dell'utilizzo del controllo del codice sorgente, ma anche i costi (in termini di tempo, denaro, risorse) che verranno sostenuti, e poi chiediti se ha senso seguire la pratica o non dare il progetto.

Alcune domande che dovresti porci su ogni best practice sono cose come:

• Stiamo facendo qualcosa di simile a questa pratica o che contraddice questa pratica?
• Quali vantaggi offre?
• Quali svantaggi ci sono in questa pratica?
• Abbiamo le risorse (persone, hardware, tempo, denaro) necessarie per implementare questa pratica?

If your client is not using Source Control, then yes, that's a big problem and IMO is a battle worth fighting especially since fixing the problem costs a client $0 (SVN).

Il più grande impatto dell'introduzione di pratiche (o processi) in un progetto in ritardo è sul thrashing. Steve McConnell ha un interessante articolo su The Power of Process . L'introduzione del processo in ritardo su un progetto ha l'effetto di ridurre la quantità di tempo trascorso nel lavoro produttivo.

Molte buone pratiche possono essere implementate con strumenti disponibili gratuitamente. Tuttavia, solo perché lo strumento è gratuito non significa che il processo sia gratuito. Se il tuo team non ha familiarità con gli strumenti (o, peggio, con le pratiche in sé indipendenti dagli strumenti), allora devi spendere tempo e denaro per addestrarli in modo che possano essere efficaci.

Devi considerare il "quadro generale", dalle persone ai processi, dal business alle prospettive tecniche, quando cambi il funzionamento di un progetto, specialmente nel mezzo.

Da risposta di teabot :

Personally I have a set of practices that I like to work to and would hope to employ in any team in which I find myself. However, I do try hard to recognize the value in conforming to existing practices if they yield the results expected and required.

Sono d'accordo con questo 100%. Non si tratta di conformarsi alle best practice, ma di fornire software di lavoro di alta qualità ai tuoi clienti in tempo e in budget (o, se vuoi essere un po 'più pessimista, che riduce il superamento di tempo e denaro). Non si tratta di creare una checklist di pratiche e di seguirle nella lettera di ogni progetto.

Da risposta di soru :

If they are being followed and enforced, but are objectively stupid, try to get them changed. Otherwise, just quietly do the right thing.

Sono parzialmente d'accordo con questo. Ritengo che le retrospettive del progetto (o, per progetti più lunghi, discussioni periodiche sullo stato di salute del progetto) siano molto importanti. L'idea è di permettere a tutti coloro che sono coinvolti in ogni aspetto di un progetto di avere voce in capitolo nel bene, nel male e nel brutto. È anche importante non focalizzarsi sul cattivo, ma anche sul bene. Penso che una discussione a tre livelli sia la migliore:

• Cosa sta andando bene? Perché funziona? Possiamo applicarli ad altri progetti?
• Cosa sta succedendo? È sufficiente? C'è qualcosa che sta peggiorando, potrebbe mettere a rischio il progetto? Possiamo migliorare qualcosa durante questo progetto o per progetti futuri?
• Che cosa sta andando male? Che impatto hanno questi sui progetti.

Acquisire questi e condividerli attraverso l'organizzazione ad altri team di progetto dovrebbe consentire a project manager, gestori di programmi e altri dirigenti di lavorare per il miglioramento dei processi e un software di qualità superiore.

Sono gli standard del progetto:

• Scritto?
• Seguito in pratica da persone sul squadra?
• Almeno forse sensato?

Se si applicano due dei suddetti, seguiteli. Se vengono seguiti e fatti rispettare, ma sono obiettivamente stupidi, cerca di farli cambiare. Altrimenti, fai tranquillamente la cosa giusta.

Assicurati che ciò che vuoi fare è diverso (in generale) e non solo diverso e ASSICURATI di sapere perché le cose sono state fatte in un certo modo (non limitarti a leggere il codice, chiedi a qualcuno che faceva parte del processo decisionale). Se si scopre che hai un modo migliore, usalo, Colon Powell ha detto una volta di mettere sempre in discussione gli esperti - rende tutti migliori. Assicurati solo di documentare l'approccio, comunicare con il resto del team (ottenere l'acquisto) e pianificare il refactoring del codice esistente.