Quanta libertà dovrebbe avere un programmatore nella scelta di una lingua e di un framework?

Ho iniziato a lavorare in un'azienda principalmente orientata al C #. Abbiamo alcune persone a cui piace Java e JRuby, ma la maggior parte dei programmatori qui come C #. Sono stato assunto perché ho molta esperienza nella creazione di applicazioni Web e perché mi appoggia a tecnologie più recenti come JRuby su Rails o nodejs.

Di recente ho iniziato un progetto per la creazione di un'applicazione Web con l'obiettivo di realizzare molte cose in breve tempo. Il responsabile del software ha dettato che uso mvc4 anziché rotaie. Potrebbe essere OK, tranne per il fatto che non conosco mvc4, non conosco C # e sono l'unico responsabile della creazione del server delle applicazioni Web e dell'interfaccia utente front-end.

Non avrebbe senso usare un framework che conosco già molto bene (Rails) invece di usare mvc4? Il ragionamento alla base della decisione era che il responsabile tecnico non conosceva Jruby / Rails e non ci sarebbe modo di riutilizzare il codice.

Argomenti contrari:

• Non contribuirà al codice e, francamente, non è necessario per
  questo progetto. Quindi, non importa se conosce JRuby / rotaie o no.

• In realtà possiamo riutilizzare il codice poiché disponiamo di molte app java da cui JRuby può estrarre il codice e viceversa. In effetti, ha dedicato alcune risorse per convertire una libreria Java in C #, invece di eseguire semplicemente la libreria Java sull'app JRuby on Rails. Tutto perché non gli piacciono Java o JRuby

Ho creato molte applicazioni Web, ma l'utilizzo di qualcosa di non familiare sta causando alcune spin-up e non sono in grado di creare un'applicazione fantastica in poco tempo come sono abituato. Questo andrebbe bene; l'apprendimento di nuove tecnologie è importante in questo campo. Il problema è che per questo progetto dobbiamo fare molto velocemente.

A che punto dovrebbe essere consentito a uno sviluppatore di scegliere i suoi strumenti? Dipende dalla compagnia? La mia compagnia fa schifo o è considerato normale? Esistono pascoli più verdi? Sto guardando questo nel modo sbagliato?

Direi che devi parlare con il capo squadra e dire qualcosa del tipo:

So che voi ragazzi siete un negozio .NET, ma in realtà sono stato assunto per le mie abilità Java / JRubyRails. Posso creare questa nuova applicazione in X tempo usando quegli strumenti che già conosco. Potrei imparare C # / mvc4 come vuoi, ma ci vorrà >> X quantità di tempo. Cosa vuoi?

Questo solleva la questione di "abilità-si-erano- (assumedly) -hired-per" vs. "abilità-you-need-ora" e mostra anche che siete disposti ad imparare le nuove competenze, ma che sarà prendere più tempo per sviluppare la nuova applicazione poiché non hai familiarità con questo set di strumenti. E tu cosa vuole dimostrare che siete disposti a imparare nuove abilità. Non essere aperti all'apprendimento di nuove competenze è un buon modo per garantire che il tuo rapporto di lavoro termini quando le tue competenze non sono più necessarie.

Quanto alla tua domanda alla fine:

A che punto dovrebbe essere consentito a uno sviluppatore di scegliere i suoi strumenti? Dipende dalla compagnia? La mia compagnia fa schifo o è considerato normale? Esistono pascoli più verdi? Sto guardando questo nel modo sbagliato?

Di solito dipende dalla compagnia. Se un'azienda acquista strumenti MS e standardizza tutto sulla piattaforma VisualStudio e .NET framework, potrebbe diventare molto imbarazzante se uno sviluppatore insiste sull'uso di Linux e C. Questo è normale. Potrebbero esistere eccezioni in cui la società è meno esigente nei confronti degli editori, come consentire agli sviluppatori di scegliere Vi vs Emacs, purché l'output sia lo stesso. So che alcune aziende consentono persino agli sviluppatori di scegliere Windows rispetto a Linux, ma la lingua in cui lavorano ha un ottimo supporto e tempi di esecuzione per entrambi i sistemi operativi.

Perché le aziende fanno questo? La coerenza è una delle ragioni. Può essere molto difficile eseguire il debug delle cose quando l'applicazione è una patchwork di file binari creati nei linguaggi / framework preferiti di vari sviluppatori, integrati in strumenti diversi e testati su sistemi molto diversi. Se tutti gli sviluppatori lavorano su configurazioni per lo più simili, questi tipi di problemi vengono risolti.

Nel tuo caso, sembra che tu sia stato assunto per lavorare in una tecnologia che non è standard in questa azienda. Mi sembra strano e potresti voler parlare con la persona che ti ha assunto del perché lo volessero.

A che punto dovrebbe essere consentito a uno sviluppatore di scegliere i suoi strumenti?

Quando non incidono sulla tua squadra.

Sto guardando questo nel modo sbagliato?

Assolutamente.

Sì, hai una scadenza breve. Sì, puoi farlo più velocemente in Rails. Ma l'intera azienda deve implementare e mantenere l'applicazione. Se la società ha una scuderia di buoni sviluppatori C #, probabilmente sarà più economico (e produrrà una qualità migliore) avere un'app C # da mantenere.

I tuoi amministratori di database e altro personale amministrativo probabilmente hanno familiarità con quello stack e dispongono di processi per distribuire e aggiornare tale stack. Anche se riesci a ottenere il codice più velocemente, potrebbe essere necessario più tempo quando si tiene conto di tutte le spese generali necessarie per rendere operativa un'app Web professionale.

Ricorda che passerai molto più tempo a mantenere la tua app che a scriverla. Ottimizza per quel costo.

1. Apparentemente sei stato assunto a causa della tua capacità di adattamento alle "nuove" tecnologie. C # non è diverso, al riguardo. Sei sicuro di non voler cogliere l'occasione per imparare qualcosa di nuovo?

2. ASP.NET MVC è molto simile a Ruby on Rails, in molti modi.

3. Non sarai al ritmo di una lumaca per sempre. Se conosci già ROR, ASP.NET MVC sarà un gioco da ragazzi per te. Il trucco sta imparando C #.

Argomenti per rimanere con Java / JRuby

È probabile che il tuo capo voglia che tu produca. Ti hanno assunto in modo che tu possa aggiungere valore alla compagnia. Assicurati che comprendano che, obbligandoti a utilizzare un framework che non hai familiarità, ti faranno :

1. Produrre risultati a una velocità inferiore
2. Crea un codice di qualità inferiore

Anche i migliori programmatori richiedono tempo di riscaldamento con nuove lingue / framework.

Argomenti per l'apprendimento di MVC4 e C #

Imparare nuove lingue è buono. Investire nelle tue capacità di programmatore è solo un rischio se la lingua / piattaforma che stai imparando sta per scomparire nel prossimo futuro, e con Microsoft che soffoca insieme, non penso che sia un problema. C # e MVC hanno entrambi avuto aggiornamenti recenti che li hanno migliorati entrambi, con ancora più aggiornamenti in cantiere.

Rendendoti, personalmente, uno sviluppatore più completo, ti impedirà di essere mai più messo in questa situazione. La parte migliore? Il tuo capo ti pagherà per imparare queste cose, il che significa che verrai pagato per farti valere più soldi.

La linea di fondo

Potresti finire per vincere questa lotta, ma rimarrai a lavorare con colleghi scontenti. Spiega i pro e i contro di ciascuno al tuo manager e poi uscirai entrambi dall'altra parte più felice.

A che punto dovrebbe essere consentito a uno sviluppatore di scegliere i suoi strumenti?

Quando detto sviluppatore è il capo del software.

Certamente, puoi (e dovresti) sostenere l'uso del diverso toolkit se sei preoccupato per la produttività, ma preparati a una risposta che non ti piacerà. Potrebbe esserci una dannata buona ragione per cui il tuo lead vuole che tu usi un toolkit specifico, che si tratti di compatibilità con l'architettura attuale, preoccupazioni sulla manutenzione, problemi di licenza, ecc.

A proposito, la frase

con l'obiettivo di fare un sacco di cose in un breve lasso di tempo

è responsabile di più bruciori di stomaco e caos nell'industria del software di qualsiasi altra cosa.

Noto che non dici di essere stato assunto come programmatore JRuby o Java.

Ecco perché hai detto di essere stato assunto: "[B] perché ho molta esperienza nella creazione di applicazioni web e perché mi appoggia a tecnologie più recenti come JRuby su Rails o nodejs."

In altre parole, gli piace la tua esperienza sul web e la tua volontà di apprendere nuove tecnologie.

Ora ti stanno chiedendo di usare la tua esperienza web e di apprendere una nuova tecnologia.

Quindi la domanda è: hai intenzione di farlo o no?

La più grande spesa in software è nel suo mantenimento

Ho letto che la spesa maggiore (80%) è relativa alla manutenzione del software. Lo sviluppo iniziale rappresenta solo il 20% del costo totale di sviluppo.

Ho letto un caso su uno sviluppatore che ha sviluppato codice e commenti nella sua lingua madre (non inglese) e quando gli altri membri del team sono andati a migliorare e mantenere il codice, era quasi impossibile perché il linguaggio (non alcun linguaggio di programmazione) era straniero a loro.

Allo stesso modo, se si sviluppa il codice in un linguaggio di programmazione di propria scelta, sarebbe difficile da mantenere per gli altri membri del team.

Soluzione: accoppiare la programmazione

Considera di chiedere ai tuoi datori di lavoro di accoppiarti con qualcun altro che conosce il linguaggio di programmazione richiesto e che puoi lavorare insieme. Puoi imparare gli uni dagli altri e se uno di voi lascia la compagnia, l'altro conoscerebbe il codice.

Articolo di Wikipedia su "Programmazione di coppie": http://it.wikipedia.org/wiki/Pair_programming

Molte aziende preferiscono semplicemente attenersi a ciò che hanno sempre fatto o a ciò che è "sicuro". C'è una ragione per cui Java e PHP sono ancora molto popolari. Al momento, la ricerca di "COBOL" su indeed.com restituisce 2144 elenchi ... che dovrebbero davvero parlare da soli. L'industria non si preoccupa del buon codice, si preoccupa del codice che può mungere il più a lungo possibile (questo non implica che C # sia cattivo, in realtà non lo è).

Pensaci: il codice ti sopravviverà. C'è una buona probabilità che qualcun altro manterrà il tuo codice e C # è una scommessa più sicura di Node.js e Rails. Non mi sorprenderebbe se in 5 o 6 anni il numero di programmatori Ruby si dimezzasse, dopo che lo stesso è accaduto al Perl e a qualsiasi altra lingua che è stata considerata ad un certo punto il linguaggio web "it". È probabile che Javascript non vada via, ma stiamo già iniziando a vederlo usato come una sorta di ASM (o persino C) del web - una lingua intermedia che altre lingue possono compilare per scrivere in questo modo il codice lato server molto bene diventa obsoleto.

La mia principale preoccupazione per gli sviluppatori che scelgono come implementare i loro obiettivi è che normalmente assumono solo che modificheranno il codice. Guarda in questo modo, 12 mesi dopo potrebbero aver bisogno di cambiamenti; non sei disponibile (hai lasciato l'azienda o sei davvero impegnato in un'altra attività) e un altro sviluppatore deve modificare il tuo codice. Se si tratta di un negozio C #, utilizzare il loro set di strumenti è un buon lavoro di squadra. Le nuove tecnologie dovrebbero essere studiate e implementate, ma solo quando il lead pensa che sia il momento giusto, in quanto tengono d'occhio molti obiettivi, non solo uno.

Giralo, per favore. Immagina di essere stato tu a assumere uno sviluppatore di Ruby e insistono nell'implementare il loro lavoro in Asp.net/MVC.

Cosa diresti loro? Questo è il nostro stack, amico. Impara a conviverci.

La regola d'oro, ecco, lei che ha l'oro fa le regole.

Esistono numerosi obiettivi contrastanti e il problema è trovare il miglior compromesso. Abbiamo la scadenza, abbiamo un team leader che richiede un determinato set di strumenti e abbiamo uno sviluppatore inesperto con quel set di strumenti, ma destinato a produrre qualcosa in un arco di tempo (ovviamente breve).

È importante capire che il responsabile del team ha probabilmente alcuni buoni motivi per cui esige esattamente questo set di strumenti (uno dei quali potrebbe essere davvero quello di abituarti a questo set di strumenti per qualche motivo che potresti non conoscere ancora). La cosa migliore che puoi fare al primo avvio è scoprire quali sono esattamente questi motivi.

Metti nella tua posizione, proverei a parlare con il responsabile del team e cerco di spiegare la situazione, come è a tuo avviso, e le opzioni e quali risultati (inclusi gli effetti economici a breve e lungo termine) saranno generati seguendo ciascuna di queste opzioni. Ad esempio, un altro sviluppatore più esperto potrebbe essere assegnato ad allenarti, magari con alcune sessioni di programmazione di coppia o simili.

A meno che il capo del tuo team non sia un completo idiota, dovresti essere in grado di trovare un consenso sensato in merito al progetto e agli obiettivi generali dell'azienda.

Bah. Tutti hanno torto.

Sii uno sviluppatore migliore di quelle persone su una piattaforma e avrai molte più opzioni interessanti che mai. Quindi, per ora, impara MVC. E nel tempo libero, scopri di più sulle piattaforme che ti interessano davvero. Sviluppa le tue abilità di nodo. Impara un po 'di Django. Presta attenzione a qualsiasi shenanigans Java o pre MVC .NET a cui sei esposto e poi scappa, ma almeno impara abbastanza per essere in grado di criticare e spiegare quanto pensiero hai messo nel tuo odio di masterizzazione a malapena nascosto di quelle piattaforme. (ok, forse sto proiettando lì)

E ora per l'importante consiglio. Se continui ad affinare le tue specialità diversificando al contempo le tue competenze in altre aree, alla fine ti troverai in un posto dove puoi trovare nuovi lavori in qualsiasi momento dell'anno in meno di due settimane in una delle principali città facendo cose che sono per lo più interessante almeno la metà delle volte. Quando ti trovi in ​​questo posto, non tollerare questi lavori dove dicono di volerlo e dal secondo giorno ti fanno fare questo senza alcuna speranza di un recupero prevedibile nel lungo termine. Spiega e scusa educatamente, ma no, non volevi davvero farlo e hai detto così tanto al tuo colloquio e poi! @ # $ IngMettiti e vai avanti quando passano un paio di settimane e inevitabilmente non hanno fatto nulla per il fatto che ti abbiano travisato la posizione e si rifiutino di riconoscerlo.

Ma fidati di me, trovare un nuovo concerto è sempre molto meglio che essere seriamente irritato e infelice per un periodo di tempo superiore a 5 minuti. Ma ovviamente, prima devi pagare le tue quote in modo da poterlo fare. Alcune persone non lo faranno mai. Ecco perché vogliono tutto ciò che sanno meglio. E ovviamente altre risposte non sono proprio sbagliate. Ha senso che un negozio .NET vada con .NET se deve mantenere la cosa sciocca.

Naturalmente, ciò che non ha senso è il motivo per cui si diversificherebbero con uno sviluppatore Rails / JS / UI e gli farebbero fare solo app MVC. Ma per ora. Potrebbe essere necessario ritirarlo e pagare le quote. E come ho detto nei commenti, MVC non è poi così male. Una scelta davvero pessima date tutte le opzioni ma sicuramente non la peggiore. È piuttosto semplice, non getta 10.000 strati di astrazione su tutto ciò che sta realmente accadendo e non si stravolge così tanto con il lato client che malediresti i nomi degli ingegneri MS responsabili se qualcuno potesse essere disturbato per impararli.

Quindi vai in quel posto dove puoi andartene quando vuoi se non l'hai già fatto e potresti persino scoprire di avere un occhio più scettico sulle cose che al momento ti piacciono. Potresti persino trovarti antipatie tanto quanto me. Non che ci sia qualcosa di sbagliato in Ruby (a parte il suo interprete ovviamente).

A seconda della tua situazione, potrebbe essere pericoloso presumere che tu sappia perché ti hanno assunto, e ancora di più supporre che il tuo manager lo sappia e sia d'accordo che assumere persone con le tue abilità sia una buona idea.

Vorrei chiedere il consiglio sopra e fare un caso aziendale sul perché dovresti andare con JRuby su C #, forse la tua discussione e le tue scadenze significano rompere dai vecchi modi ha senso. Non vorrei solo supporre che vada bene o no, dare al manager o guidare i fatti e lasciare che prendano la decisione, è per quello che viene loro pagato un sacco di soldi, più un po 'di CYA.

Secondo la mia onesta opinione, una delle cose che separa i bravi sviluppatori da grandi è la loro capacità di adattarsi alle nuove tecnologie. Viviamo in un mondo frenetico in cui la migliore tecnologia di oggi diventerà obsoleta domani. Pertanto, uno sviluppatore che non è disposto ad adattarsi è di scarsa utilità per l'azienda. Questo andrebbe bene, se non per un piccolo fatto che trovare e assumere brave persone è davvero molto difficile da fare e quando un'azienda trova la sua gemma, stanno pianificando a lungo termine.

Ho visto le aziende assumere dal loro ambito tecnologico e lo fanno esattamente per lo stesso motivo. Vogliono mettere le mani su grandi sviluppatori, anche se ciò significa aspettare che si adattino alle nuove tecnologie.

Ora alla tua situazione. Come nuovo ragazzo nel gruppo, starei molto attento a ciò che dico e non dire ai miei superiori. Certo, te ne andrai molto con il presupposto che sei ancora in procinto di adattarti al tuo nuovo ambiente. Tuttavia, minare l'autorità e la tenace perseveranza nei confronti della tua tecnologia preferita farà solo pensare ai tuoi superiori di aver fatto un errore assumendoti e che non sei disposto a lasciare la tua zona di comfort.

Quello che sceglierai dipende da te, ma ti suggerirei di provare a imparare nuove tecnologie. Non farà male, lo prometto.

Presumo che tu sia stato onesto durante l'intervista sulla tua mancanza di conoscenza di C #, perché se non lo fossi, potresti essere in una posizione molto precaria dal punto di vista legale.

I bravi programmatori conoscono la programmazione. Sebbene nessuno possa ovviamente essere esperto in tutte le lingue e tutti i framework, esiste una notevole comunanza tra la maggior parte di essi. A meno che non ti venga chiesto di lavorare in una lingua che è enormemente diversa da ciò che costituisce il mainstream in questi giorni (Lisp, per esempio), allora un buon programmatore dovrebbe essere in grado di adattarsi.

Naturalmente c'è una curva di apprendimento. Se il datore di lavoro ti ha assunto, allora deve essere sicuro delle tue capacità di seguire quella curva in un ragionevole lasso di tempo (di nuovo, supponendo che tu fossi onesto in anticipo riguardo al non conoscere C #). Il linguaggio C # prende in prestito pesantemente da Java e, più in generale, la maggior parte dei linguaggi di programmazione basati su classi sono fondamentalmente abbastanza simili (hai menzionato node.js, che si basa su ECMAScript, che è un linguaggio basato su prototipo, quindi sei ovviamente a proprio agio con altri paradigmi di programmazione.

I bravi programmatori dovrebbero, oltre ad essere flessibili, essere desiderosi di imparare cose nuove. Nello sviluppo del software generalmente stai imparando o diventando irrilevante.

Ovviamente il tuo datore di lavoro, supponendo che sapessero che non conoscevi C #, deve incontrarti a metà strada. Se mostri entusiasmo di imparare, allora devono darti il ​​tempo e le risorse per farlo. Lanciarti nel profondo è ingiusto e inutilmente stressante. Devi sederti e avere una discussione calma e razionale con il tuo superiore. Se lo vogliono in C #, devono essere pronti ad accettare che ti troverai su una curva di apprendimento mentre ci lavori e che sarebbe ingiusto imporre loro scadenze strette. Se le scadenze non sono flessibili e se sono di grande importanza strategica, devono essere pronti a concederti un po 'di spazio per svolgere il lavoro entro tale scadenza. Se hanno bisogno che sia nella lingua più comunemente usata nel loro ufficio, allora puoi forse richiedere di implementarlo ora in quello che avere familiarità con il rispetto della scadenza, quindi come prossimo progetto reimplementarlo in C # come esercizio di apprendimento e portare il software in conformità con i requisiti interni una volta soddisfatti quelli esterni. Come ho detto, la maggior parte delle lingue più comunemente utilizzate oggi hanno molto in comune, quindi si tratta principalmente di dettagli di implementazione.

Devi essere pronto ad accettare prima o poi che lavori in un negozio C # e quindi devi avere C # sotto controllo.

Forse non sono soddisfatti del modo in cui tutti usano MVC nell'ambiente .NET. Ci potrebbe essere troppo trattarlo come moduli web. Questo non è diverso quando qualcuno con un background procedurale inizia in OOP, mette tutto in una grande classe e va avanti come al solito.

Questo primo progetto non è la situazione ideale perché vogliono farlo così rapidamente. Mantieniti aggiornato su .NET il più possibile e inizia a sfogliare le funzionalità il più velocemente possibile. Non ti piacerà il modo in cui stai facendo le cose, prova solo a ricordare che inizierai a riformattare queste cose e ad applicare le tue abilità in un'altra lingua.

Spero che il tuo modo di usare MVC4 (supponendo che tutti gli altri non lo stiano facendo nel modo giusto) in uno stile più Ruby prenderanno piede e distoglieranno tutti dalla mentalità dei Webform.