Questi segni di cattivo sviluppatore? [chiuso]

Non direi che sei un cattivo sviluppatore. Essere consapevoli dei problemi ti porta già oltre questa definizione.

I requisiti cambiano. Questo è un dato. Un buon sviluppatore deve tenerne conto. Molte moderne tecniche di programmazione ti aiutano a farcela.

Rimanere fedele alle specifiche originali non è realistico. Anche non realistico sta cambiando i requisiti tutto il tempo.

Il cliente non ha sempre ragione. È "giusto" più spesso di quanto vogliamo che lui / lei sia, anche se (come nel caso, cerca di accontentarlo se non è completamente fuori). Ma quando lo vedi guidare il progetto nella direzione sbagliata, prova a sostenere le cose che pensi siano giuste.

Non ci sono regole rigide su queste cose, e anche gli sviluppatori buoni ed esperti non hanno raggiunto lo "Zen" perfetto. L'unico approccio sbagliato non sta cercando di migliorare su questi.

Ci sono casi in cui è il cliente. Ma questo è anche il tuo problema

Ci sono casi in cui è lo sviluppatore, e ci sono casi in cui è il cliente. Ma, di solito sono entrambi il problema tuo , quindi un atteggiamento di incolpare se stessi tende ad avere più successo, perché si sbaglia dalla parte del problem solving invece che dell'indifferenza del dito puntato. Pertanto, lo troverai spesso in sviluppatori più esperti.

Un atteggiamento ancora migliore è IMHO a guardarlo senza incolpare: "è colpa dei clienti che ho un codice scadente, perché cambia sempre i requisiti" quindi diventa "questo cliente sta cercando di capire cosa vuole, quindi feedback, prototipazione rapida e la flessibilità è più importante della completezza, della robustezza e della velocità ".

Tipo di mente Zen: non giudicarlo, basta vederlo come è.

In primo luogo, un cliente non sa cosa vuole finché non lo vede. Questo fa parte del fascino delle piccole iterazioni del paradigma Agile con il coinvolgimento di un grosso cliente. In secondo luogo, non aspettatevi che un prodotto sia "completo" quando il codice è completo.

Microsoft utilizza un prodotto chiamato "Watson" (il messaggio di feedback di invio che si ottiene quando si verifica un errore) per poter risalire direttamente a un client. La tracciabilità è un buon modo per rintracciare i problemi agli utenti che li vivono. Puoi ottenere la tracciabilità chiedendo. Oppure, se si dispone delle risorse, integrare la funzionalità nei prodotti. La chiave è tenere traccia dei problemi / miglioramenti in modo che possano essere affrontati.

Infine, i clienti sicuri possono essere volubili. In questi casi, cerco di concentrarmi sul segreto dell'iceberg .

I mutamenti dei requisiti sono un dato di fatto; ma la decomposizione del codice non è causata da questo.

Il codice si verifica quando alcune parti del codice non vengono esercitate frequentemente; quindi quando fai delle modifiche che "non dovrebbero influenzare nient'altro", potresti introdurre dei bug. In altre parole, il codice che non vede la luce del giorno si decompone lentamente e non puoi dire quando smette di funzionare.

Sì, è colpa tua e non del tuo utente.

La vera soluzione? prova tutto il tuo codice frequentemente. Certo, il modo migliore è avere test automatici con una buona copertura.

L'indecisione del cliente può essere un grosso problema e se non sei quello che ha il compito di gestire la relazione con il cliente piuttosto che essere molto difficile da gestire. Potresti parlare con la persona che si occupa del cliente e spiegare con calma che il progresso non può accadere finché il cliente non prende una decisione. Se sei responsabile della relazione con il cliente, devi dire al cliente che devono prendere una decisione prima che il progetto possa continuare. Potrebbe non essere che il tuo atteggiamento abbia bisogno di una revisione, solo un minuto di meditazione per calmarti. ;)

Javier rende un buon punto che i mutevoli requisiti sono un dato di fatto difficile. Anch'io sono frustrato da queste situazioni perché troppo spesso mi trovo a lavorare su un prodotto in cui lo sviluppatore deve prendere decisioni. La mia opinione era "Perché la gestione non può capirlo con il cliente?", O "Perché abbiamo iniziato questo progetto se il cliente non sapeva cosa volevano?", "È così tanto mal di testa quando cambiano così in ritardo nello sviluppo ".

Semplice fatto: ciò accadrà sempre , non solo nella programmazione / sviluppo del software, ma in ogni ambito della vita. Il mondo sarebbe semplicemente un posto molto noioso e molto diverso se le persone non hanno mai cambiato idea, non si sono mai adattate, non hanno mai affrontato il cambiamento. Le persone hanno la tendenza a guardare quello che viene dato e migliorarlo. Non fai la stessa cosa con il tuo codice? Se ho un blocco di codice di cui non sono soddisfatto (è inefficiente, disordinato), lo migliorerò. (Il sistema operativo si lamenta con me? ... a volte, se sto usando un determinato SO senza nome, ma generalmente non lo è)

Come programmatori, abbiamo bisogno di cogliere le opportunità per migliorare le cose e non deprimerle o infastidirle. Cogli l'opportunità di parlare con le persone, migliorare il tuo stile, migliorare la tua etica del lavoro, approcciare le cose con una mente aperta, spingiti a essere migliore di ieri. Vai avanti nella tua carriera e non accontentarti troppo facilmente.

Capisco che non tutti saranno d'accordo con questa risposta, ma penso che sia importante che le risposte a questa domanda coprano una prospettiva più ampia.

Quando interagisci con un cliente, non stai programmando; stai imparando e insegnando.

Mantieni i clienti informati e istruiscili sul processo. Il cambiamento sta per accadere. Fai sapere loro che cercherete di implementarli, ma costerà di più. Lasciali decidere.

Non entrare nei dettagli tecnici anche quando la domanda che chiedono è di natura tecnica. Sei tentato perché ti sentirai un po 'sulla difensiva e vorrai affrontare una sfida / diventare il tuo geek. Non farlo; non si preoccupano dei dettagli e smetteranno di ascoltare dopo 45 secondi.

Se non glielo hai detto prima, non aspettarti che sappiano degli standard del settore e delle migliori pratiche o altre scuse per fare ciò che fai. Lo odio quando non vedo una commissione fino alla fine solo per avere il venditore mi dice che è lo standard nel settore. Non dovrei aspettarmi di saperlo. La mia risposta è: "Mi sta facendo sentire un idiota anche uno standard?"

Quando sei con un cliente, prestale più attenzione di chiunque o di qualsiasi altra cosa nella stanza. I cani domestici sono dei geni in questo; soprattutto se hai del cibo.

È una cattiva gestione dei requisiti o un'analisi errata. Il tuo analista aziendale (se ne hai uno) o chiunque abbia i requisiti deve sedere con il cliente e cercare di ottenere tutti i requisiti, anche quelli a cui il cliente potrebbe non pensare. I clienti di solito non sanno tutto quello che vogliono, un ottimo analista di business li aiuterà a capire tutto.

Questo è il motivo per cui dovresti sempre ottenere una configurazione del documento sui requisiti aziendali e firmare prima che qualsiasi applicazione vada oltre la fase di prototipazione / ricerca.

Ora, l'idea che questo documento sia effettivamente definitivo è difettoso, ma questo dovrebbe aiutarti a farti un'idea migliore di ciò che il cliente vuole realmente. E finché scrivi il tuo codice tenendo presente la manutenibilità, puoi mantenere i tuoi problemi al minimo.

E se hai bisogno di una scusa per ricominciare, puoi incolpare eventuali ritardi sul BRD, che il cliente ha firmato, non includendo tali e così via, ecc.

(Naturalmente, questa è solo una scusa nel caso in cui ne hai bisogno. Devi sempre pianificare su di loro la modifica di qualcosa )

Nella citazione di Emerson, "Una coerenza folle è la follia delle piccole menti ..." la parola più spesso trascurata è folle . La coerenza non è negoziabile in determinate impostazioni, ma spesso sostituisce il pensiero critico e l'analisi.

Da un lato, molti modelli di sviluppo sono progettati specificamente per aiutare nell'ambiente che stai descrivendo; quindi, se ti ritrovi a dover violare il tuo modello, o non lo stai implementando in un primo momento o se hai il modello sbagliato.

D'altro canto, se hai una giustificazione ragionevole e giustificabile per violare le tue regole e puoi dimostrare che il tuo metodo canaglia produce un codice più pulito e più gestibile, allora non dovresti aver paura di intraprendere la strada più ragionevole .