Recursos para Profissionais de TI >
Página Inicial dos Fóruns
>
Fóruns do Arquitetura
>
Arquitetura de Soluções
>
Qual a forma mais eficiente de desenvolver software?
Qual a forma mais eficiente de desenvolver software?
- Pessoal, boa tarde.Hoje na Universidade, um colega de mestrado me fez a seguinte pergunta: "Se um aluno me pergunta - Como se faz um sofware no modelo de sistema comercial da forma mais eficiente?", no momento conversamos sobre MVC, Design Patterns, entre outros, mas mesmo assim ainda fiquei pensando: "De posse das tecnologias existentes hoje, qual a forma mais eficiente para desenvolver software"?Acho que a resposta mais correta: Depende do projeto. OK, mas como falei: um sistema comercial (sei lá, um sistema para uma padaria).Então a resposta mais correta: Desenvolva com a linguagem e ferramenta que mais detém conhecimento, com uma tecnologia relativamente avançada (.net 3.5 por exemplo, JSF...), utilizando os padrões de projeto, e principalmente no padrão MVC.Gostaria de saber a opinião de vocês: Qual a forma mais eficiente de desenvolver software no modelo de sistema comercial?
Todas as Respostas
- Caro Bruno,
Boa questão... É assunto pra encher essa Thread de respostas e discussões... :)
Acrescentando ao que você disse, além de nos preocuparmos somente com tecnologia, é muito importante buscarmos boas práticas no máximo de disciplinas da Engenharia de Software quanto for possível.
De cara, a minha opinião é que adotar uma metodologia de desenvolvimento ágil (XP, Scrum, etc) é fundamental... Desenvolvimento orientado a testes (TDD) é legal, Integração contínua (se necessário), uma boa estratégia de gerenciamento/versionamento de código-fonte, etc...
Com relação a tecnologia, acho fundamental hoje em dia utilizarmos um bom O/R mapper (NHibernate, LLBLGen, EntitySpaces, etc), um bom container de inversão de controle/injeção de dependência (IoC container/DI), como o Unity e o Castle Windsor.
Enfim, são muitas siglas, mas são "coisas" que sempre buscam aumentar a produtividade do desenvolvimento sem abrir mão da qualidade. Isso é importante...
Forte abraço,
André Borges Medeiros
MCPD, MCT
>> Se a resposta solucionar sua dúvida, favor Votar como Útil - Legal André, concordo com você!Duas dúvidas em relação ao seu Reply:1- O Linq é um O/R Mapper não é?2- Não conheço IoC container/DI, o que seria?
Legal André, concordo com você!
Duas dúvidas em relação ao seu Reply:1- O Linq é um O/R Mapper não é?2- Não conheço IoC container/DI, o que seria?
Fala Bruno,
1 - O Linq to Entities sim... Veja mais detalhes nesse artigo
2 - IoC Containe e DI Container são "sinônimos". Servem para fazer Inversão de Controle (IoC - Inversion of Control), também chamado de Injeção de Dependência (DI - Dependency Injection). É uma padrão bastante utilizado para minimizar o acoplamento entre "componentes" de um sistema... Essa é uma definição bem simplificada... Tem bastante artigo na Internet sobre isso, vale a pena dar uma pesquisada...
Forte abraço,
André Borges Medeiros
MCPD, MCT
>> Se a resposta solucionar sua dúvida, favor Votar como Útil- Bruno,Acho que não tem uma solução "certa". Depende do projeto e do objetivo.... vamos discutir alguns pontos...Você falou sobre um sistema comercial... tem vários aspectos sobre como conduzir o desenvolvimento de um sistema comercial, principalmente olhando para o "negócio" (tecnologia existe para apoiar um modelo de negócio).1) Web? RIA? Client/Server: Acho que esse é um principal ponto de decisão. Se vc falar de um "sistema comercial" focado em automação comercial, provavelmetne não vai ser bem-sucedido em Web, já que são sistemas que exigem uma interface com usuário rica e diversas integrações (máquinas de cartão de crédito, por exemplo). Essa é a primeira grande decisão que precisa ser tomada e talvez possa eliminar MVC de cara.2) Equipe. Se vc for trabalhar sozinho, pode explorar todo o SEU conhecimento. Se for um sistema grande, tem que levar em consideração que toda a equipe precisa estar na mesma maturidade técnica que você. Já vi muitos projetos fracassarem por isso. Você escolhe uma tecnologia mega-complicada e vira gargalo no projeto. É importante saber disseminar o conhecimento e criar padrões "factíveis".3) Ciclo de vida. Dependendo da dinâmica de manutenção desse sistema comercial, pode-se demandar um investimento em "infra-estrutura" de desenvolvimento muito grande. Em outras palavras... se vc está falando de um sistema web, single-instance com "n" clientes rodando na mesma instância, prepare-se para investir MUITO em processos. Gestão de configuração e versões, gestão de projetos e outros. Se vc pensa num software com uma instância rodando em clientes diferentes, tem que pensar se vai ter uma única base de código parametrizável, ou uma base de código para cada cliente. Cada uma trás junto de si custos e benefícios associados.Eu particularmente acredito nisso. Deve-se tentar entender o objetivo "do negócio" e procurar as tecnologias e práticas do mercado que melhor atendem o problema.Eu já tive casos reais em projetos que optar pelos padrões "menos" sofisticados deram resultado excepcional para o projeto. E também outros vários casos em que o investimento em padrões mais complexos e muito treinamento deu mais resultado.Pra mim o segredo está em conhecer muitas tecnologias, conversar com muitas equipes, conhecer casos de sucesso e fracasso para orientar melhor as decisões nesse sentido. O mais importante aqui é não só a experiência como também o aprendizado com ela. E não faltam histórias de terror associadas a decisões mal tomadas nesse quesito.Abraço,Eric
- Aproveitando o gancho da pergunta, que é muito pertinente e útil: Para o ambiente da minha empresa, sistemas CRUD, mestre-detalhe, em intranet achei que o padrão "Modelo > DAL > BLL > UI (Web)" atendeu bem, mas ainda não começamos a desenvolver. O grave problema é que já pesquisamos e muita gente está falando que esse modelo em camadas já está ultrapassado. Ou seja, nos identificamos com DAL/BLL em C#.NET in ASP.NET/WinForms mas já estamos nos sentindo ultrapassados. O pior é que todos falam que DAL/BLL está ultrapassado mas não dizem o que seria um paradigma superior que pudesse superar esse modelo considerado ultrapassado. Ou será que para esse ambiente vale a pena trabalhar com algo menos sofisticado e produtivo do que tentar usar uma sofisticação que seria DESPROPORCIONAL às nossas necessidades. Como diz o meu nick, "Keep It Simple, Stupid"... Quem puder ajudar dando dicas eu agradeço.
Obs.: Pensamos em usar Java no início, mas consideramos que o grau de complexidade e sofisticação eram bem DESPROPORCIONAIS para a nossa realidade, por isso estamos migrando de Delphi Cliente-Servidor para C#.Net in ASP.NET Intranet. - K.I.S.S,Tbém adoro essa filosofia ;-)Enfim, como eu disse no post anterior... esse é o grande desafio dos arquitetos. O melhor para uma realidade pode não ser o melhor para outra realidade. Não existe uma resposta única "qual é o melhor paradigma".Se vc vem de Delphi Cliente/Servidor, por exemplo, partir de um ambiente de desenvolvimento client/server para um ambiente Web já vai dar bastante trabalho.Mesmo que minha escolha fosse pela Web, eu não começaria um sistema em ASP.Net Web Forms hoje. Iria para ASP.Net MVC. Minha aposta é que MVC é um modelo mais maduro e mais próximo da Web.Pra quem vem de cliente/servidor ainda em outra tecnologia (no caso Delphi), eu acho que continuar em windows forms ou mesmo partir direto pro silverlight seria uma opção melhor.Tudo depende do nível de conhecimento dos demais desenvolvedores do time. As vezes dar um salto muito grande como esse pode ser bastante prejudicial para o projeto em questão...Sobre a estruturação das camadas, DAL/BLL e outros, isso é um universo.. tem muita gente que é totalmente "teórica" nesse assunto, fala, diz como os livros abordam o problema. O dia-a-dia é outra história completamente diferente. Eu costumo usar uma abordagem baseada em VO's e Services, justamente para obter muitos benefícios com a framework Spring.Net (não que seja obrigatório usa-la para esse modelo).Muita gente vem pejorativamente chamando esse modelo de "anêmico" em detrimento das novas abordagens de DDD. Eu venho trabalhando com essa abordagem a mais ou menos uns 3 anos e tendo resultados fantásticos em quesitos de organização e reuso de código.Se quiser conhecer mais sobre essa forma de trabalhar, recomendo essas leituras:http://ericlemes.wikidot.com/dotnet-spring-pt1http://ericlemes.wikidot.com/dotnet-spring-pt2http://ericlemes.wikidot.com/dotnet-spring-pt3http://ericlemes.wikidot.com/dotnet-spring-pt4Abraço,Eric
- Eric, Ajudou muito. Vou ler sobre o framework e perguntar a conhecidos o que acham. Estamos migrando para web pois nossos clients estão cada dia mais "fats" e nada "thins". Um navegador apenas, é o que queremos na máquina dos usuários (algum java script Ajax também). Ouvi falar sobre o mvc mas ainda nao testei na prática. vou testar também. Todas as idéias são bem vindas! Valeu!
- Não deixe de ver Adobe Flex e Silverlight...Se os usuários já estão ambientados com client/server, podem não se dar muito bem com Web... eu acho que essas tecnologias RIA (Rich Internet Applications) mesclam o melhor dos dois mundos...Simplifica o deploy e mantém a riqueza dos clientes. Arrisco dizer q o desenvolvimetno fica mais simples que em Web pura.Se a resposta foi útil, por favor, marque como resposta.Abraço,Eric
