A che punto lascereste cadere alcuni dei vostri principi di sviluppo del software per il bene di più soldi?

Da quando sono diventato dipendente dai test unitari più di 10 anni fa, nella maggior parte dei miei luoghi di lavoro sono stato il primo a sentirne parlare. Ciononostante, continuavo a scrivere i miei piccoli test unitari ogni volta che potevo, e stimavo il costo dei test unitari nei miei compiti. Ogni volta che qualcuno ha chiesto delle mie abitudini di codifica, ho detto cosa stavo facendo e perché ha funzionato per me. Di solito almeno alcune delle persone erano interessate, e alla fine ho avuto modo di tenere presentazioni sul tema e di guidare le persone per scrivere i loro primi test di unità.

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

Aggiornamento

La maggior parte degli sviluppatori stagionati (e manager) hanno visto tendenze e mode andare e venire, quindi non si entusiasmano per le ultime parole d'ordine. Tuttavia, se puoi dimostrare che un determinato approccio (strumento, modo di pensare) funziona davvero nella pratica, nel progetto attuale , quelli che si preoccupano del loro mestiere quasi sicuramente si siederanno e ascolteranno. Ma se non hai queste persone nella tua squadra, forse è tempo di cercare un posto migliore ...

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

Nei miei 12 anni di programmazione non penso di aver mai completato un progetto e ho pensato che fosse completo o completo nella mia mente. C'era sempre qualcosa che avrei voluto fare meglio o più pulito. Mi ci è voluto molto tempo per capire che questo è a causa di questi compromessi.

Quindi, se stai pensando di cambiare lavoro solo perché le metodologie non ci sono, penserei di nuovo se fossi in te. Questi trade off sono costanti e si applicano a tutti gli sviluppatori di software. Persino gli sviluppatori di giochi più dedicati desiderano poter fare ancora qualcosa, o praticare di nuovo una metodologia diversa se ne avessero la possibilità.

Direi che dovresti esaminare le tue pratiche di sviluppo agili e rendersi conto che puoi farlo anche a un livello micro. Certo, i tuoi compagni di squadra potrebbero essere fuori a la-la land a fare quello che vogliono, ma la tua soddisfazione personale sarà maggiore e sicuramente creerai sicuramente un codice migliore di loro a lungo termine. Poi, quando arriva il manager e ti chiede perché il tuo codice è molto migliore, hai la possibilità di convertire il team:)

Ma se non ti piacciono le persone, o il lavoro, allora penso che tu sappia già la risposta. Ma dubito strongmente che qualcuno entrerà nella stanza e ti dirà di non usare principi di sviluppo agili mentre codifichi ... se lo fanno ... scappa urlando.

Non lasciare mai qualcosa che ti renda insoddisfatto a lungo termine. Ovviamente, puoi iniziare in terra di nessuno e cercare di far muovere la squadra nella tua direzione. Se sei disposto a mettere lo sforzo in esso e il lavoro ne vale la pena, questa può anche essere una sfida interessante.

Ma se devi lasciare le cose che mantengono il piacere della codifica (o qualsiasi altro lavoro per quella materia), 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 sapevano già di TDD, SOLID, ecc. È grandioso. Sono sicuro che ti è piaciuto lavorare lì e ho imparato molto. Ora hai l'opportunità di insegnare quei concetti (facendo contemporaneamente un sacco di soldi). Nella mia esperienza, dovendo insegnare a qualcun altro un concetto mi ha sempre aiutato ad apprenderlo in modo ancora più dettagliato. Basta avere pazienza con loro e continuare a spingere i tuoi concetti uno alla volta. Quando ti senti frustrato, vai a casa e conta i tuoi soldi. O cercare supporto su SE.

Devo ammettere che sono un b * tch in questo senso. Come libero professionista, qualunque cosa il cliente consideri la giusta metodologia per il progetto, va bene per me. Ciò non significa che il denaro sia l'unica cosa a cui tengo, ma la decisione su cosa fare e cosa lasciare è compito del cliente. Non accetterei comunque condizioni di lavoro negative (rumoroso, lunghe ore ecc.).

Voglio citare un mio ex collega. Ha detto, ogni volta che sta cercando un lavoro, o 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 competenze (non è sicuro che questo sia il modo giusto per esprimerlo)
• Dovrebbe pagare bene

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

Come ti sei affezionato a TDD (come ho fatto io), penso che andrai in giro ogni giorno e spero che tutti i tuoi colleghi abbiano raggiunto la stessa intuizione che hai. Quindi il primo criterio probabilmente non verrebbe soddisfatto.

In secondo luogo, se vuoi perseguire progetti TDD e magari avere più esperienza con la creazione di team agili, allora lavorare a questo progetto non ti aiuterà a rafforzare quelle capacità. Quindi il secondo probabilmente non verrà raggiunto neanche.

Quindi personalmente, se fossi nella tua posizione, e non ero nella posizione di aiutare a introdurre il TDD in azienda, avrei cercato altrove.

Mai.

La vita è troppo breve (soprattutto quando si invecchia) per fare cose che si odieranno.

Ovviamente, rende più difficile cambiare lavoro e ci sono meno posti di lavoro.

Ma almeno il codice precedente ha un cattivo odore. (E ho autonomia, quindi possiamo fare cose sensate come trascorrere una settimana eliminando gli avvertimenti del compilatore dalla legacy codebase ....)

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 fai i 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 vengono e diventano più frequenti di un autobus urbano. Lavora duro come ti è stato detto e prendi i soldi che si apprezzano in qualsiasi momento e in ogni momento:)

Assicurati che lavorare con il nuovo team sia un buon investimento del tuo tempo.

Forse funzionano in modo più efficiente di quello che hai incontrato finora? Se così lavorare con loro sarà una grande esperienza di apprendimento per te (quindi un buon investimento).

D'altra parte le metodologie del nuovo team possono essere di scarso valore per te (troppa "codifica dei cowboy", ecc.). In tal caso, il denaro aggiuntivo probabilmente non ne vale la pena (a meno che non sia una start-up pre-IPO o qualcosa di straordinario). Probabilmente non imparerai molto ... e rischi di bruciarti.

Non lavorerei da qualche parte che non mi permettesse di lavorare come volevo. Con ciò intendo che non voglio essere microgestito.

Lavoro partendo dal presupposto che sono bravo in quello che faccio e, se mi dai dei compiti, li farò lavorare in modo efficiente ed efficace. Come li realizzo, purché non infranga le linee guida e i modelli del codice, dipende da me. Questa è la parte divertente del mio lavoro.

Se volessi testare tutte le classi che scrivo, questo potrebbe essere un problema, ma scrivere test unitari generalmente va bene, purché continui a rispettare le scadenze. Mi aspetto che un sostenitore del TDD sostenga che i test delle unità di scrittura effettivamente aumentino la produttività (in seguito, ecc.). Se fossi nei tuoi panni, scriverò alcuni test di unità che mi faranno risparmiare alcuni tempi lungo la traccia (presumibilmente meno errori, correzioni più facili). Se reinvestisci quel tempo risparmiato in più test, allora si accumulerà ancora più tempo risparmiato e alla fine potrai rilassarti con un grande sorriso quando avrai una fantastica serie di test, e potrai facilmente controllare le modifiche al codice quando arriverà una nuova undicesima ora il requisito arriva.

Se non potessi farlo, non so se mi piacerebbe lavorare lì.

Quello che sto dicendo è che penso che ci dovrebbe essere dare e prendere in queste materie - un po 'di negoziazione. Più mi pagano, meno sottigliezze non monetarie che mi aspetto. Ma ho sempre bisogno di un livello di autonomia e rispetto per me stesso, soprattutto quando non c'è bisogno di rifiutare. Lascerò cadere ogni altro principio fintanto che avrò quel po 'di autonomia. Dopotutto, quella che potrebbe sembrare una metodologia pazza all'indietro potrebbe essere la cosa migliore che tu abbia mai fatto!