Justificação para aprender / implementar tecnologias Microsoft mais recentes [fechado]

Trabalho em uma grande organização de saúde como desenvolvedor de software de nível médio. Tenho mais de 10 anos de experiência no setor de TI usando tecnologias Microsoft (ASP.NET e SQL Server).

Quando vou a conferências, campos de código, reuniões de grupos de usuários .net, ouço todos os tipos de novas ferramentas e tecnologias: MVC, LINQ, Entity Framework, WCF Web Services, etc. Acho que você pode dizer que estou à vontade usando o mesmo material antigo do asp.net 2.0. Eu uso conjuntos de dados digitados para minha camada de acesso a dados. Uso formulários da web e recursos avançados de controles de servidor com páginas mestras. Eu sei como usar o SQL antigo simples e criar consultas nos meus conjuntos de dados digitados para obter os dados que meus aplicativos precisam.

Ao longo da minha carreira, sou sempre sensível a não ficar obsoleta com o meu conjunto de habilidades. O que eu uso atualmente funciona bem e meu tempo de desenvolvimento é rápido. Mas estou preocupado que, se eu fosse demitido, seria perguntado em entrevistas quantos aplicativos MVC eu escrevi. Ou como eu estou com os serviços da web LINQ ou WCF.

Eu sei que não importa quantas conferências, livros ou vídeos eu assisto em alguma nova tecnologia ... Eu tenho que implementá-la / usá-la ou ela simplesmente não afunda. Além disso, os gerentes que entrevistam não se importam quanto alguém lê algo, apenas uso e experiência reais com uma tecnologia.

Eu tenho um novo projeto para escrever. Fui ao meu gerente e solicitei mais tempo para o projeto de aprendizado / implementação de tecnologia com a qual talvez eu não esteja familiarizado. Nossa organização incentiva seus funcionários a "aprender e crescer" e a continuar a educação. Mas sempre encontro resistência quando peço mais tempo para pensar em algo novo para implementar. Meu gerente está pedindo razões comerciais concretas para implementar essas novas tecnologias. Não tenho motivos comerciais. Minhas razões são porque eu não quero me tornar obsoleto. Eu poderia dizer que tornaria o projeto mais sustentável no futuro por outros desenvolvedores, já que em algum momento as pessoas poderiam parar de usar essas tecnologias mais antigas, mas isso é tudo o que consigo pensar. Os aplicativos Linq / Entity Framework / MCV têm melhor desempenho? Tanto que os clientes (usuários dos departamentos para os quais estou criando este aplicativo) precisam? Eu duvido.

Estou interessado nos pensamentos de vocês sobre isso. Muitos de vocês têm dificuldades semelhantes ao tentar usar novas tecnologias futuras? Duvido que também esteja na ponta da tecnologia. Existem "razões comerciais" que você traria à luz para usar essas tecnologias?

Desde já, obrigado! Desculpe pela longa parede de texto.

Não se tornar obsoleto parece uma boa razão comercial para o uso de novas tecnologias. Flui nos dois sentidos. Você não quer que seu conjunto de habilidades fique desatualizado, mas seu chefe também deve se preocupar com o fato de ele não conseguir encontrar funcionários dispostos ou capazes de trabalhar com tecnologia desatualizada. Se a maioria dos desenvolvedores e empregadores deixarem uma tecnologia antiga para uma nova, isso pode ser motivo suficiente para a sua empresa fazer isso também.

Para responder especificamente à sua pergunta, você deve avaliar cada uma dessas tecnologias individualmente para ver se elas atendem às suas necessidades. Vou dar a minha opinião, mas você realmente precisa gastar pelo menos meio dia para pesquisar e avaliar cada uma delas conforme elas se apliquem às suas necessidades comerciais específicas.

LINQ: Isso é algo que você pode usar, mesmo sem a estrutura da entidade. O LINQ é uma tecnologia usada para trabalhar com coleções de dados, e você pode usá-lo em seus aplicativos, mesmo que não o utilize para carregar esses dados do banco de dados. Faça um favor a si mesmo e aprenda como usar expressões lambda e métodos de extensão LINQ. Isso economizará tempo, facilitará sua vida como desenvolvedor e reduzirá a quantidade de código que você precisa escrever.

Entity Framework: Este parece ser o futuro do acesso a dados no mundo da Microsoft. A maioria das novas estruturas, tecnologias e ferramentas da Microsoft foi projetada para funcionar com a estrutura da entidade. Não é perfeito, mas é muito melhor do que usar conjuntos de dados, especialmente se você usar o LINQ para entidades. Um motivo importante para o uso da estrutura da entidade é que ela reduz a quantidade de código SQL que você precisa escrever, pois a estrutura o gerará para você. De acordo com minha experiência, a maioria dos desenvolvedores não é muito boa em escrever SQL (e a maioria das empresas não possui um DBA dedicado); portanto, para a maioria das estruturas de entidades de aplicativos, as coisas devem ser mais rápidas e eficientes. A estrutura de entidades também permitirá que você trabalhe com POCOs com menos sobrecarga e mais fáceis de trabalhar do que conjuntos de dados.

MVC: Pode ser difícil justificá-lo, pois a maioria dos aplicativos pode não se beneficiar muito disso. Com base nas últimas ofertas de emprego que eu já vi, o MVC ainda é minoria (embora esteja ganhando terreno rapidamente). Para a maioria dos aplicativos de negócios, o MVC pode ser um exagero, e arrastar alguns controles para uma página aspx será suficiente. O MVC tem uma curva de aprendizado e, para ser produtivo e tirar o máximo proveito, você realmente precisa entender HTTP, HTML, CSS e JavaScript. O MVC funciona bem quando você precisa ter um aplicativo Web realmente personalizado, onde o desempenho é uma grande prioridade. Se não for esse o caso, e os funcionários não tiverem muita experiência com isso, provavelmente não há um argumento comercial forte para usá-lo.

Serviços Web do WCF: Você precisa fornecer dados para aplicativos clientes remotos? Provavelmente o WCF é o caminho a percorrer. Você está apenas escrevendo um aplicativo Web que será executado no mesmo servidor ou rede local que seu banco de dados? Não use o WCF, você não precisa dele e isso servirá apenas para complicar as coisas com abstrações desnecessárias.

Em resumo, use uma nova tecnologia quando isso fizer sentido e reserve um tempo para descobrir quando é isso. Leva muito tempo para aprender novas tecnologias, mas não deve demorar muito tempo para avaliá-las e saber se elas beneficiarão sua situação específica. Isso é algo que os altos executivos da sua empresa já deveriam estar fazendo, mas se não estiverem, você precisará fazer isso e dedicar algum tempo para educá-los sobre o que aprendeu.

EDIT: Depois de ler seus comentários acima, tive mais alguns pensamentos. Talvez seja útil adotar uma abordagem ágil para o desenvolvimento deste aplicativo e dividi-lo em diferentes componentes que podem ser totalmente concluídos antes de passar para o próximo. É mais provável que seu gerente aprove o tempo extra para novas tecnologias se ele conseguir ver que você está fazendo um progresso constante ao longo do caminho. Além disso, você não precisa escolher entre gravar o aplicativo inteiro nas páginas e conjuntos de dados MVC e Entity Framework ou ASPX. É possível usar os dois no mesmo aplicativo usando uma abordagem híbrida. Você pode começar usando o MVC e a estrutura da entidade para alguns dos componentes. Se as coisas estão indo bem e seu chefe está feliz, você pode continuar, mas se ele achar que é isso '

Embora você deva definitivamente aprender algumas das novas tecnologias de MS, minha experiência recente em aprender coisas como WPF e WCF me deixou um pouco mais cauteloso ao aprender as mais recentes APIs de MS.

Agora, o LINQ é um grande benefício para a produtividade que você definitivamente deveria usar; o bom é que você pode introduzir o LINQ para objetos em todos os tipos de situações aleatórias, com ou sem a sintaxe de consulta real (geralmente chamo Where()sem a from-selectsintaxe, pois geralmente é mais curta.) O dual matemático do LINQ, Reativo Extensões, é algo que você deve estar ciente, embora eu ainda esteja lutando para encontrar um bom caso de uso. Da mesma forma, todos os recursos do C # 3/4/5 são úteis, portanto você deve estudá-los e procurar lugares onde eles serão úteis, mesmo que você continue usando o material "antigo" da BCL.

No entanto, vou aceitar o advogado do diabo e sugerir que as grandes bibliotecas grandes de MS, como WCF e WPF, não valem necessariamente a pena aprender.

A principal razão é que eles são enormes e não são especialmente bem projetados (o primeiro é um sintoma do último). Eu escrevi brevemente recentemente sobre o porquê do WPF ser péssimo . Quanto ao WCF, o whitepaperfaz parecer que interoperará facilmente com "o servidor Java EE em execução em um sistema não Windows" e "aplicativos parceiros em execução em uma variedade de plataformas", mas a verdade é que as APIs do WCF são muito especificamente orientadas para SOAP e têm muito suporte limitado a protocolos não SOAP. A MS poderia ter projetado com facilidade um sistema geral que permita protocolos conectáveis, e talvez a capacidade esteja oculta (não documentada) lá em algum lugar, mas, tanto quanto posso dizer, eles escolheram projetar um sistema muito mais limitado que só pode fazer SOAP e HTTP limitado (desde que o corpo da mensagem seja um objeto .NET serializado, IIRC). Eu pesquisei o Entity Framework mais brevemente, mas notei algumas reclamações de que era incapaz de suportar alguns cenários que o (muito mais simples) LINQ-to-SQL pode lidar imediatamente.

Na IMO, o design de todas essas bibliotecas é fundamentalmente defeituoso porque eles usam muitos componentes fortemente acoplados entre si, um gráfico de dependência das classes em cada estrutura provavelmente seria enorme e pareceria uma confusão de linhas rabiscadas. E mesmo que o design fosse bom, não poderíamos saber porque não existem documentos de arquitetura pública que se aprofundam nos detalhes de nível inferior, e os documentos do MSDN geralmente não são muito bons (eles tendem a obter menos e menos útil ao analisar as classes de nível inferior e inferior.)

O tamanho das bibliotecas também parece uma falha; Aprendi mais de 20 anos de programação que a simplicidade é uma virtude, que a Microsoft nunca valorizou.

Mas você pode perguntar "e daí"? Bem, com essas grandes bibliotecas você pode nunca sentir que realmente as entende. Isso significa que, quando você quiser fazer algo fora dos casos de uso para os quais a Microsoft projetou o WCF / WPF / EF especificamente, você não saberá como e é possível que ninguém fora de Redmond também saiba. E quando algo der errado, você terá dificuldade em descobrir o que deu errado. E daqui a 15 anos, quando a Microsoft migrar para a próxima API de próxima geração, ninguém gostará de manter o software construído sobre uma base que é tão mal compreendida.

Também devido à amplitude e complexidade dessas novas APIs, a alternativa de plataforma cruzada ao .NET, Mono, tem suporte ruim ou nenhum suporte para elas. Você provavelmente terá pouca dificuldade em usar suas tabelas de dados digitados no Linux ou Mac, mas o Entity Framework? Esqueça isso. Eu não ficaria surpreso se Mono nunca o apoiar.

Eu usei o LINQ-to-SQL em um novo projeto e não é ruim. De certa forma, poderia ser melhor, mas acho que a experiência do desenvolvedor é substancialmente melhor que o ADO.NET. Uma limitação significativa: o L2S é mais fácil, de longe, se você modificar as tabelas no modo "conectado", diferentemente do antigo ADO.NET, que foi projetado especificamente para funcionar sem uma conexão ativa com o banco de dados. De qualquer forma, como o LINQ-SQL é (de acordo com o pessoal da Mono) um quarto do tamanho do Entity Framework, é uma pena que a MS tenha decidido parar de trabalhar nele.

Eu desenvolvi o software baseado no Microsoft Windows por mais de dez anos antes de mudar completamente para o software livre e de código aberto e desistir do desenvolvimento do MS. Estou escrevendo isso a partir de uma longa experiência pessoal.

Além de outros motivos pelos quais mudei para o FOSS, o motivo relacionado à programação é que quase nunca há justificativa para aprender / implementar tecnologias proprietárias. O cerne da questão é que a Microsoft não está comprometida em oferecer suporte a cada peça de tecnologia que já distribuiu. Com muita freqüência, a Microsoft introduz alterações obsoletas em suas APIs e estruturas. Isso torna grande parte das APIs existentes, bem como seu conhecimento obsoleto. Na verdade, eles ainda fazem isso com o software do usuário final. Por exemplo, o MS Office 2007/2010 não é semelhante ao MS Office 2003 e, mais importante, o Windows 8 é um desvio radical das plataformas existentes. Em particular, é provável que haja todas as novas APIs e estruturas para o Windows 8, e você não poderá oferecer suporte ao Windows 8 (no futuro, se não agora) sem implementá-las.sem suporte , é um dos principais motivos de negócios para a implementação de qualquer nova tecnologia lançada pela MS. Se a MS parar de oferecer suporte à tecnologia antiga amanhã, aonde você vai com o código legado? Onde você obtém atualizações para isso?

Observe também que não estou pedindo que você abandone o desenvolvimento do MS e mude para o software livre. Eu só queria ajudá-lo aqui, tendo uma longa experiência em tecnologia MS.

Penso que o principal a fazer é descobrir quais são os benefícios concretos da adoção de uma tecnologia mais recente e apresentá-los como justificativa para fazê-lo, em vez de seu próprio desejo de não se tornar obsoleto. Você diz que não tem "razões de negócios", mas certamente pode encontrar algumas com pesquisas ...

Talvez a mudança para uma estrutura / tecnologia mais nova permita que você crie aplicativos que executam com menor espaço de memória, sejam mais responsivos, mais rápidos de implantar, etc. Todos esses seriam motivos comerciais concretos. Então, eu acho que sugiro recuar um pouco e investigar "por que as pessoas começaram a usar MVC, LINQ, Entity Framework, WCF Web Services, etc em primeiro lugar?" Responda a essa pergunta e você provavelmente encontrará alguma justificativa comercial a oferecer. Se é ou não suficiente abandonar a filosofia "siga o que funciona" é outra questão e pode ser uma função do seu vendedor.

O que eu uso atualmente funciona bem e meu tempo de desenvolvimento é rápido

Infelizmente, a Microsoft não se importa com isso, o que importa para eles é vender mais ferramentas. Isso significa criar novas tecnologias, o que significa que você também precisa adquirir mais treinamento! Vantajoso para as duas partes, para eles.

Para você, significa uma batalha constante para aprender coisas novas, e uma vez que você começa a se aperfeiçoar nelas e sua produtividade no desenvolvimento é tão rápida quanto costumava ser ... há mais alguma coisa para aprender e você precisa começar tudo de novo. Há uma razão pela qual o software geralmente é de baixa qualidade, porque não é tratado como os serviços "profissionais", como engenharia ou arquitetura, eles mantêm as coisas que funcionam. Jogamos fora e começamos do zero o tempo todo.

Mas, este mau estado do mundo não ajuda. Portanto, meu conselho é usar uma combinação de "acompanhar a tecnologia" e "não quero ficar para trás". Seu chefe deve se preocupar com o recrutamento; se você fez o desenvolvimento do VB6, será muito difícil recrutar novos funcionários (bem, na verdade, você provavelmente acharia muito fácil, todos os caras que gostaram do VB6 se reunirão com você, mas isso é outra questão).

Eu diria que você precisa verificar se a nova tecnologia x ajudaria você a desenvolver o desenvolvimento ainda mais rapidamente - então ela deixa de ser uma tarefa pessoal ou simplesmente inútil e se torna uma tarefa de aprimoramento dos negócios, as empresas estão sempre falando sobre como P&D " inovação "os ajuda a permanecer competitivos.

Como desenvolvedor, você precisa pressionar o gerenciamento para usar tecnologias mais recentes e justificá-lo, demonstrando os benefícios e o valor que trará para a empresa (por exemplo, desempenho, recursos, facilidade de uso, manutenção). O gerenciamento geralmente é avesso à mudança e não justifica mudar nada, a menos que traga alguns benefícios adicionais sobre o que está atualmente em uso.

O uso de alguma tecnologia nova e de ponta também é bom para a equipe de marketing, para que eles possam comercializar a empresa como estando no topo das tendências atuais da tecnologia e não ficando presa no passado usando plataformas e tecnologias herdadas.

Você precisará fazer alguns projetos menores no seu tempo livre, se a sua empresa não permitir que você aprenda sobre eles. O aprendizado que você faz em seu tempo privado deve fornecer o argumento comercial a ser apresentado ao seu chefe sobre as melhorias nas novas tecnologias. Se você está atualmente muito cansado do seu trabalho diário para aprender coisas novas, pode ser necessário tirar algumas semanas de folga , descansar por alguns dias e depois fazer uma sessão de treinamento intensivo.

Diga o que quiser sobre a Microsoft , uma coisa que você não pode culpá-los é disponibilizar gratuitamente ferramentas e treinamento para desenvolvedores . Instale o instalador mais recente do Microsoft Web Platform no seu PC, inicie-o e aguarde para ver todas as ferramentas e plataformas de desenvolvimento gratuitas que você pode experimentar. Visite os sites MSDN , ASP.Net e Channel9 e confira os tutoriais.

Ainda estou desenvolvendo o ASP Classic, se você pode acreditar, mas com algumas horas de persuasão convenceu meu chefe de que o .Net é o caminho a percorrer, fazendo um argumento comercial para ele. No próximo ano, começaremos a transição do nosso código legado.

A melhor maneira de justificar o uso de novas tecnologias é quando você pode mostrar que elas melhoram a produtividade do desenvolvedor. Isso significa mais trabalho realizado a um custo menor. Essa é a única coisa que importa da perspectiva dos negócios.

Alguns exemplos:

1. Ferramentas que facilitam o trabalho do desenvolvedor
2. Bibliotecas que fornecem recursos que, de outra forma, teriam que ser desenvolvidos internamente
3. Linguagens mais poderosas que podem resultar em código mais fácil de ler ou menos linhas de código que precisam ser gravadas / depuradas