A che punto abbandoneresti alcuni dei tuoi principi di sviluppo software per motivi di più denaro?

Vorrei porre questa domanda là fuori per vedere in modo interessante dove si trova il mezzo.

Devo ammettere che negli ultimi 12 mesi ho acquisito TDD e molti dei valori Agile nello sviluppo del software. Ero così sopraffatto da quanto fosse migliorato il mio sviluppo di software che non li avrei mai abbandonati per principio. Fino a quando ... mi è stato offerto un ruolo contrattuale che ha raddoppiato la mia paga da portare a casa per l'anno.

La società a cui ho aderito non ha seguito alcuna metodologia specifica, il team non aveva sentito parlare di odori di codice, SOLID, ecc., E di certo non avrei intenzione di cavarmela con TDD se il team non avesse mai nemmeno visto test unitari in pratica. Sono un sold out? No, non del tutto ... Il codice sarà sempre scritto "in modo pulito" (secondo gli insegnamenti di zio Bob) e i principi di SOLID saranno sempre applicati al codice che scrivo quando necessario. I test sono stati abbandonati per me, tuttavia, la società non poteva permettersi di consegnare un team così sconosciuto al team che, francamente, anche se avessi creato dei framework di test, non avrebbero mai usato / mantenuto correttamente il framework di test.

Usandolo come esempio, quale punto diresti che uno sviluppatore non dovrebbe mai abbandonare i suoi principi di artigianato per motivi di denaro / altri benefici a lui personalmente? Capisco che questa può essere un'opinione molto personale su quanto si è preoccupati per le proprie esigenze, esigenze aziendali e per il bene dell'artigianato ecc. Ma si può considerare che, ad esempio, i test possono essere abbandonati se l'azienda decidesse che preferirebbero avere un il team di test, piuttosto che comprendere i test unitari in programmazione, sarebbe qualcosa per cui potresti perdonarti come ho fatto io? Quindi, dato che c'è qualcosa che vorresti abbandonare, di solito dovrebbe esserci un uguale costo nel business che compensa ciò che lasci cadere - si spera, a meno che, ovviamente, tu non sia abbastanza fuori per allinearti e non collaborare con la comunità / sociale; ).

Raddoppia i tuoi soldi, torna a RAD? Oppure cammina e cerca qualcuno che fa Agile, e non guardare mai indietro ...

Da quando mi sono appassionato ai test unitari più di 10 anni fa, nella maggior parte dei miei posti di lavoro sono stato il primo ad averne mai sentito parlare. Ciononostante ho continuato a scrivere i miei piccoli test unitari ogni volta che potevo e ho stimato il costo dei test unitari nei miei compiti. Ogni volta che qualcuno mi chiedeva delle mie abitudini di programmazione, raccontavo cosa stavo facendo e perché funzionava per me. Di solito almeno alcune persone erano interessate, e alla fine ho avuto modo di tenere presentazioni sull'argomento e di fare da mentore alle persone per scrivere i loro primi test unitari.

Non è necessario iniziare a convincere le persone del modo agile il primo giorno nel nuovo posto di lavoro. Segui i principi nel tuo lavoro il più possibile. Se lo fai bene, fornirai un codice migliore. Se i tuoi colleghi e / o dirigenti lo notano, ti chiederanno come lo fai. Quindi puoi dirglielo.

Aggiornare

La maggior parte degli sviluppatori (e dei manager) esperti ha visto andare e venire tendenze e mode, quindi non si entusiasmano per le ultime parole d'ordine. Tuttavia, se riesci a dimostrare che un certo approccio (strumento, modo di pensare) funziona davvero nella pratica, nel progetto reale , quelli che hanno a cuore il loro mestiere quasi sicuramente si siederanno e ascolteranno. Ma se non hai persone del genere nella tua squadra, forse è tempo di cercare un posto migliore ...

Questo è dove penso che tutti gli sviluppatori dovrebbero anche sapere un po 'di gestione del progetto. Tutto è un compromesso tra tempo, denaro e risorse. Considerati la risorsa.

Nei miei 12 anni di programmazione non credo di aver mai completato un progetto e di averlo pensato come fatto, o completo nella mia mente. C'era sempre qualcosa che avrei voluto poter fare meglio o in modo più pulito. Mi ci è voluto molto tempo per capire che ciò è dovuto a quei compromessi.

Quindi, se stai pensando di cambiare lavoro solo perché le metodologie non ci sono, ci penserei di nuovo se fossi in te. Questi compromessi sono costanti e si applicano a tutti gli sviluppatori di software. Anche gli sviluppatori di giochi più dedicati desiderano poter ricominciare da capo o esercitarsi di nuovo con una metodologia diversa se ne avessero la possibilità.

Direi che dovresti esaminare le tue pratiche di sviluppo agile e capire che puoi farlo anche a livello micro. Sicuramente i tuoi compagni di squadra potrebbero essere fuori a La-La-Land facendo quello che vogliono, ma la tua soddisfazione personale sarà maggiore e sicuramente genererai un codice migliore di loro a lungo termine. Quindi quando il manager arriva e ti chiede perché il tuo codice è molto meglio, hai la possibilità di convertire il team :)

Ma se non ti piacciono le persone o il lavoro, penso che tu sappia già la risposta. Ma dubito fortemente che qualcuno entrerà nella stanza e ti dirà di non usare agili principi di sviluppo durante la programmazione ... se lo fanno ... corrono urlando.

Non lasciare mai qualcosa che ti farà infelice a lungo termine. Ovviamente, puoi iniziare nella terra di nessuno e cercare di far muovere la squadra nella tua direzione. Se sei disposto a impegnarti e ne vale la pena, questa può anche essere una sfida interessante.

Ma se devi lasciare le cose che mantengono il piacere di scrivere un codice (o qualsiasi lavoro del genere), la mia esperienza è che prima o poi te ne andrai. Ho imparato che la frustrazione non dovrebbe mai essere sottovalutata ...

Le persone del tuo ultimo lavoro conoscevano già TDD, SOLID, ecc. Fantastico. Sono sicuro che ti sia piaciuto lavorare lì e hai imparato molto. Ora hai l'opportunità di insegnare quei concetti (mentre fai grandi soldi allo stesso tempo). Nella mia esperienza, dover insegnare a qualcun altro un concetto mi ha sempre aiutato ad apprenderlo in modo ancora più dettagliato. Sii paziente con loro e continua a spingere i tuoi concetti uno alla volta. Quando sei frustrato, vai a casa e conta i tuoi soldi. Oppure cerca supporto su SE.

Devo ammettere che sono bravo in questo senso. Come libero professionista, qualunque cosa il cliente consideri la giusta metodologia per il progetto, è d'accordo con me. Ciò non significa che il denaro sia l'unica cosa a cui tengo, ma la decisione su cosa fare e cosa lasciare fuori dipende dal cliente. Tuttavia, non accetterei cattive condizioni di lavoro (rumorose, lunghe ore, ecc.).

Voglio citare un mio ex collega. Ha detto, ogni volta che è alla ricerca di un lavoro o di un progetto part-time, ci sono tre criteri che il progetto deve soddisfare:

• Deve essere divertente lavorare con
• Deve essere utile per lo sviluppo delle tue competenze (non sono sicuro che questo sia il modo giusto di esprimerlo)
• Dovrebbe pagare bene

Mentre leggo la tua domanda, questo progetto soddisfa solo gli ultimi criteri.

Dato che ti sei affezionato al TDD (proprio come ho fatto io), penso che andrai in giro ogni giorno e vorrei che tutti i tuoi colleghi avessero raggiunto la stessa intuizione che hai. Quindi i primi criteri probabilmente non sarebbero stati soddisfatti.

In secondo luogo, se vuoi perseguire progetti TDD e forse ottenere più esperienza con la creazione di team agili, lavorare su questo progetto non ti aiuterà a rafforzare quelle abilità. Pertanto, probabilmente anche il secondo non verrà soddisfatto.

Quindi, personalmente, se fossi nella tua posizione, e non fossi in grado di contribuire a introdurre TDD nell'azienda, guarderei altrove.

Mai.

La vita è troppo breve (soprattutto quando invecchi) per fare cose che odierai.

Certo, rende più difficile cambiare lavoro e ci sono meno posti in cui lavorare.

Ma almeno solo il codice legacy ha un cattivo odore. (E ho autonomia, quindi possiamo fare cose sensate come passare una settimana eliminando gli avvisi del compilatore dalla base di codice legacy ....)

In breve, la metodologia di sviluppo non fa parte di te. Non è una religione e non è chi sei. È uno strumento. Fai quello che ti viene detto, come ti viene detto e guadagna soldi extra. Migliaia di sistemi sono stati sviluppati e funzionano oggi senza TDD, Code Smell, ecc. In pochi anni nessuno saprà cosa significano questi termini perché le metodologie vanno e vengono più frequentemente di un autobus urbano. Lavora sodo come ti viene detto e prendi i soldi che è apprezzato in ogni momento e in ogni momento :)

Assicurati solo di lavorare con il nuovo team per un buon investimento del tuo tempo.

Forse funzionano in un modo più efficiente di quello che hai incontrato finora? In tal caso, lavorare con loro sarà un'ottima esperienza di apprendimento per te (quindi un buon investimento).

D'altro canto, le metodologie del nuovo team potrebbero essere di scarso valore per te (troppa "codifica da cowboy" ecc.). In quel caso, probabilmente non ne vale la pena (a meno che non si tratti di uno start-up pre-IPO o di qualcosa di straordinario). Probabilmente non imparerai molto ... e rischi di esaurirti.

Non avrei lavorato da qualche parte che non mi permettesse di lavorare come volevo. Con ciò voglio dire che non voglio essere micromanaged.

Lavoro supponendo che io sia bravo in quello che faccio, e se mi dai qualche compito, lo farò in modo efficiente ed efficace. Il modo in cui li implemento, purché non rompa le linee guida e i modelli del codice, dipende da me. Questa è la parte divertente del mio lavoro.

Se volessi testare l'unità ogni classe che scrivo, questo potrebbe essere un problema, ma scrivere test unitari in genere va bene, purché rispetti ancora le scadenze. Mi aspetto che un sostenitore del TDD sostenga che la scrittura di test unitari aumenti effettivamente la produttività (in seguito, ecc.). Se fossi nei tuoi panni, scriverei alcuni test unitari che mi faranno risparmiare un po 'di tempo in pista (presumibilmente meno bug, correzioni più facili). Se reinvesti quel tempo risparmiato in più test, allora si accumulerà in ancora più tempo risparmiato e alla fine potrai sederti con un grande sorriso quando hai una fantastica serie di test e puoi facilmente controllare le modifiche del codice quando qualche nuova undicesima ora requisito arriva.

Se non potessi farlo, non so se vorrei lavorare lì.

Quello che sto dicendo è che penso che ci dovrebbe essere un dare e avere in queste questioni - un po 'di negoziazione. Più mi pagano, meno mi aspettavo cose non monetarie. Ma ho sempre bisogno di un livello di autonomia e rispetto per me stesso, specialmente quando non c'è bisogno di rifiutare. Abbandonerò qualsiasi altro principio finché avrò quel pizzico di autonomia. Dopotutto, quella che potrebbe sembrare una metodologia folle all'indietro potrebbe essere la cosa migliore che tu abbia mai fatto!