Vamos precisar reescrever essa aplicação do zero.

Quem nunca disse ou ouviu isso? Vamos entender os motivos por trás dessa icônica frase.

Vamos precisar reescrever essa aplicação do zero! É a frase de rendição, é sinal que as coisas foram para o caminho errado. Dias, meses, anos de desenvolvimento que serão jogados fora por falta de um bom planejamento.

Vamos precisar reescrever essa aplicação do zero.

Quando chegamos nessa situação geralmente estamos diante de alguns dos cenários a seguir:

  • A tecnologia da aplicação é antiga demais e os novos recursos demandam mais tecnologia.
  • A arquitetura da aplicação é uma engenhoca complexa e sem sentido.
  • Devido a diversas implementações e manutenções do passado feitas de forma irresponsável ou sem padrão a aplicação se tornou a famosa “colcha de retalhos”, qualquer tipo de mudança é sofrível e demorada.
  • A cada mudança surgem diversos bugs em todas as partes da aplicação, pois existe muito acoplamento entre suas divisões, “tudo está acoplado com tudo”.
  • O time que trabalha na aplicação atualmente não concorda com a forma com que foi escrita e não está satisfeito em trabalhar nela.

Algumas situações muitas vezes não possuem uma escapatória, por exemplo o envelhecimento natural da aplicação. É muito caro manter uma aplicação sempre alinhada com a última versão da tecnologia, logo, algumas vezes prefere-se optar por saltos (atualizar a cada X tempo) ou simplesmente reescreve-la depois de alguns anos.

O cenário de envelhecimento da aplicação é um dos menores, geralmente a aplicação morre muito antes da hora. Eu trabalhei em uma empresa onde assisti a mesma aplicação ser reescrita 1 vez ao ano durante 3 anos. O que ocorre de tão errado assim?

Existem muitos motivos para tudo dar errado:

  • Equipe tecnicamente despreparada.
  • Falta de um líder técnico ou arquiteto que conduza o time e evite a deformação da aplicação.
  • Escopo mal planejado, falta de entendimento da entrega.
  • Prazo mal calculado.
  • Falta de visão. Típico caso do sisteminha de cadastro que virou um “ERP”.
  • Gestor de equipe que pula etapas e/ou não valoriza (não conhece) boas práticas, impondo uma metodologia que funciona apenas na teoria dele.

Motivos para dar errado são muitos, fazer software da forma correta é infinitamente mais complexo que simplesmente entregar software. É necessário ter uma boa equipe, um bom líder e um bom gestor.

Software é um bem durável assim como uma TV, Geladeira ou Carro, paga-se muito caro para desenvolve-lo e muito caro para mante-lo. A diferença é que o software precisa ser flexível e adaptar-se às constantes mudanças de escopo, logo não pode possuir uma engenharia fechada como uma TV e geralmente é ai onde mora a maioria dos problemas.

Para garantir um bom funcionamento da aplicação de forma que ela se adapte às diversas mudanças de escopo com o mínimo de esforço necessário e sem gerar outros problemas secundários, é preciso projetar a aplicação, não basta simplesmente escrever a aplicação e entregar.

Alguns pontos importantes devem sempre ser abordados:

Processo

Processo de desenvolvimento de software é um tema extenso demais, portanto deixarei apenas alguns pontos em destaque que devem ser levados bastante em consideração.

Processo de desenvolvimento de software é um processo diferente de outros, porém infelizmente ainda existem gestores que imaginam que desenvolver uma aplicação é o mesmo que construir um prédio, um navio ou um avião.

Durante a construção de um prédio com a obra em estágio avançado é praticamente impossível aplicar mudanças que mudam o aspecto do projeto, existe uma engenharia fechada e projetada para ser daquela forma, qualquer mudança poderia impactar em ter que iniciar novamente do zero.

Uma aplicação bem projetada deve ser flexível e estar aberta para mudanças de escopo com menor esforço necessário, portanto não devemos nos apegar em simplesmente entregar o que foi inicialmente levantado.

Uma das formas mais práticas de atender a necessidade do cliente é a entrega contínua, releases parciais para acompanhamento e feedback do cliente, é muito mais fácil ajustar uma mudança de escopo com a aplicação 30% desenvolvida do que se estivesse 100%.

Focar em definir bem os requisitos das entregas mais próximas é muito melhor que tentar documentar 100% do projeto antes mesmo de iniciar a codificação.

Sim estamos falando de metodologias ágeis como o Scrum por exemplo, um projeto de software é diferente de um projeto de construção civil e merece um framework de desenvolvimento interativo e incremental.

Planejamento

É necessário analisar qual será o porte da aplicação, não existe uma receita para todo tipo de aplicação, se ela for grande e complexa é necessário abordar alguma prática de arquitetura, por exemplo DDD.

Se a aplicação for simples é necessário evitar exageros e complexidades que não beneficiam as funcionalidades da aplicação.

Orientações como o KISS e o YAGNI dizem para evitar os exageros e manter a aplicação simples, é fato, mas isso não significa que você deve fazer tudo na camada de apresentação por exemplo, uma mínima divisão de responsabilidades é essencial para a qualidade de qualquer tipo de aplicação.

Arquitetura

Arquitetura é a base de tudo, é muito importante fazer a escolha ideal e evitar a famosa “arquitetura BOLOVO” de 3 camadas (Modelo, Business e DataAccess).
Hoje em dia está claro que apesar de funcionar e ser simples esse modelo traz muitos problemas.

É muito importante ter uma pessoa no papel de arquiteto, que conheça diversas estratégias de arquitetura e saiba aplicar bem os inúmeros patterns disponíveis.

Uma vez que possui sua arquitetura definida a aplicação deve se manter dentro do aspecto da arquitetura original, corromper camadas para acessar mais facilmente o banco ou para resolver mais rapidamente um problema pode ser considerado um crime.

Descaracterizar a arquitetura de uma aplicação é o primeiro passo para a famosa “Colcha de Retalhos”. O arquiteto ou líder técnico deve ser responsável por garantir que a arquitetura não esteja sendo corrompida e que seja mantida dentro de sua proposta em toda extensão da aplicação.

Codificação

Mesmo com uma arquitetura definida a tarefa de codificação ainda é complexa e não existem motivos para ser diferente. Codificar exige muitas habilidades além do próprio conhecimento da linguagem e plataforma.

É importantíssimo valorizar os princípios básicos da orientação à objetos como o SOLID que apesar de ser básico podemos dizer que grande parte dos desenvolvedores ainda não sabem como escrever código usando injeção de dependência (DIP) para evitar o alto acoplamento. Realizam heranças sem sentido apenas pelo fato de um objeto herdar hierarquicamente de outro no mundo real. Deixam o princípio de responsabilidade única de lado (SRP) e não criam classes extensíveis (OCP) deixando o código sempre aberto.

Entre outros pontos falhos não citados, os mencionados acima já são responsáveis por grande parte dos problemas existentes em nossas aplicações. Codificar não é uma tarefa menos grandiosa como arquitetar um sistema, pelo contrário, precisamos valorizar mais o programador que possui esses conhecimentos.

Padrões de codificação como nomenclaturas e regras são importantes para manter a expressividade e facilidade de leitura do código. Antigamente programadores se gabavam por fazer códigos que somente eles entendiam, isso não deve existir, o código é uma série de instruções que devem ser de leitura clara e leve, muitas vezes dispensando uma documentação própria.

Uma técnica de codificação que vem ganhando popularidade é o TDD, apesar do TDD ter seu nome diretamente relacionado com testes o TDD na verdade é sobre codificação, os testes que guiam a codificação via TDD servem para garantir a qualidade do código que no final também garantem a sua testabilidade.

Testes

Testes é um assunto complexo, primeiramente devemos entender que teste de software não é apenas rodar a aplicação e ver se tudo está funcionando.

Existe mais de um tipo de teste, podendo ser de unidade, de integração e etc.

Os testes de unidade são necessários quase sempre, podemos dizer que 80% de cobertura de código através dos testes é um resultado bem positivo. Testes de unidade são muito importantes para garantir a boa escrita do código e validar a sua funcionalidade durante o desenvolvimento. Se durante a codificação um teste falhar pode significar que alguma coisa foi feita de forma que o código deixou de funcionar como deveria, logo evitará o deploy prematuro em produção e que o cliente tenha a infelicidade de descobrir um novo bug.

Descobrir um bug em tempo de codificação é N vezes mais barato que descobrir um bug em produção, evita retrabalho, horas extras, replanejamento de deploy, insatisfação com o cliente etc.

Muitas pessoas alegam que escrever testes de unidade fazem o software custar mais caro, pois aumenta mais o esforço de codificação. Isto parece fazer sentido se olharmos apenas no sentido da entrega, mas mesmo assim não faz. Os testes exigem mais esforço de codificação, porém conforme a cobertura de testes aumenta a velocidade de entrega aumenta junto, pois os testes facilitam muito as futuras modificações.

Contabilizar o esforço apenas baseado na entrega é uma falha. Devemos sempre levar em conta a manutenção e evolução, e quando falhamos nesse aspecto estamos iniciando o ponto onde a aplicação vai se tornar cada vez mais complexa para se testar, evoluir, receber manutenções.

Costumo dizer que programamos uma aplicação durante 6 meses e a mantemos durante 3 anos ou mais, sendo assim nosso foco deveria ser na manutenção e evolução e não apenas na entrega. Todo lucro obtido numa entrega mal planejada será perdido durante a manutenção, podendo inclusive chegar ao negativo, e esse é um dos principais motivos que levam diversos projetos falharem e se transformarem em prejuízo quando deveriam continuar gerando lucros.

Os testes de unidade são de responsabilidade do desenvolvedor, os testes de integração e etc podem ser de responsabilidade de um profissional de qualidade ou simplesmente de toda a equipe (equipes multidisciplinares sabem codificar e testar).

Testes de unidade garantem a qualidade de escrita do código e de sua funcionalidade, um código que não está coberto por testes não é um código confiável. Não existe processo ágil de desenvolvimento sem testes, portanto está claro. Testar é preciso!

Quando tudo deu errado.

O planejamento da aplicação não foi bem feito, a arquitetura não foi bem desenhada para atender o propósito da aplicação, a codificação está estruturada, acoplada e sem padrão, não existem testes de unidade e realizar qualquer manutenção significa alterar diversas partes do código e ser obrigado a testar manualmente todas funcionalidades de ponta a ponta, mesmo assim sempre escapando alguns novos bugs.

As noites são longas quando é necessária alguma manutenção, o deploy em produção é uma aventura preocupante, a satisfação de trabalhar no projeto já não existe mais e a pressão não vale a pena.

O gestor do projeto não aceita mais tantos bugs e exige mais assertividade, questionando inclusive a capacidade técnica da equipe, o cliente não aceita mais os prazos para ajustes simples e não quer pagar a mais por isso também.

Não dá mais!  Vamos precisar reescrever essa aplicação do zero.


Se você estiver interessado em conhecer mais e aprender como desenvolver aplicações Web com arquitetura baseada em DDD, aplicando os princípios SOLID, diversos Design Patterns e escrevendo testes de unidade inscreva-se em meu curso:

Vamos continuar a troca de experiências, deixe seu comentário abaixo, se gostou e concorda com o artigo compartilhe com seus colegas para transmitirmos essa mensagem para o máximo de pessoas possíveis. 😉

Quer ser um dos melhores ou vai ficar ai parado?

Este é um post diferente e começo com uma provocação:
Quer ser um dos melhores ou vai ficar ai parado?

Quer ser um dos melhores?

Estou há um pouco mais de 13 anos na carreira de desenvolvedor de sistemas, tempo suficiente para conhecer, analisar e categorizar muitos tipos de perfis dos profissionais desta área.

Muitos dos que trabalham/trabalharam comigo estão há pelo menos 5 anos como profissionais e é por isso que me motivei a escrever sobre este tema.

Pergunte a si mesmo e responda:

  • Quantas horas de estudo/aperfeiçoamento você dedica por semana?
  • Você costuma ler/experimentar/aprender uma tecnologia quando ela é lançada ou quando precisa trabalhar com ela?
  • Quais são seus planos (onde você se vê) daqui 5 anos?
  • Seus planos pessoais e conquistas dependem de um crescimento ou promoção na carreira?

Se você estuda pouco, não acompanha as novidades, não experimenta as novas tecnologias, tem planos maiores para daqui um tempo e eles dependem de resultados maiores, é melhor repensar a sua estratégia.

Eu sou um exemplo disto, em um emprego anterior onde fiquei cerca de 5 anos eu entrei atualizado e sai desatualizado. Me envolvi demais com a operação, com o negócio da empresa e suportei a tecnologia com aquilo que já sabia fazer, cresci na carreira, mas uma carreira que fazia sentido apenas dentro daquela empresa.

Quando sai deste emprego eu voltei a estudar e me dedicar ao que realmente me interessa, a tecnologia e a dor foi grande, pois recuperar em curto tempo grandes evoluções tecnológicas foi (e ainda é) uma tarefa pesada.

Conto que tive a sorte de conhecer/ter contato com diversos profissionais neste período de reaprendizagem e são neles que baseio meu “target” para chegar lá, buscar mais conhecimento, entregar melhores resultados e receber reconhecimento.

Ai vão as minhas dicas:

  • Estude todo dia, quanto tempo tiver a disposição, acostume-se com a rotina de estudar e vá aumentando a carga horária. Defina uma meta de horas e a alcance toda semana.
  • Leia muito, é lendo que surgem as dúvidas e descobrimos tudo o que não conhecemos.
  • Use o tempo ao seu favor, carregue podcasts no celular, no pendrive do som do carro e ouça enquanto se transporta, tenha sempre um PDF ou um artigo para ler no celular enquanto está a espera de algo. Ócio produtivo 🙂
  • Foque em pontos quais você pretende destacar sua carreira, conheça de tudo mas seja especialista em determinadas áreas.
  • Crie experimentos em casa, no trabalho, aprenda sem medo de errar.
  • Procure um bom curso/livro/treinamento online.
  • Certifique-se, mostre que você sabe.
  • Desenvolva sua oratória, não adianta muito saber algo se não sabe falar sobre.
  • Corte o tempo perdido com redes sociais, use-as, mas saiba tirar o melhor proveito destas ferramentas, faça network, converse com pessoas com quem você deseja aprender, se envolva.
  • Frequente comunidades virtuais, presenciais, visite workshops, assista palestras.
  • Não tenha medo de perguntar, mas saiba fazer sua pergunta, não pergunte sem antes ter tendado aprender/resolver sozinho.

E por fim, saia do seu círculo de conforto e experimente o sucesso, mas sem medo de fracassar, quem não erra não aprende.

Nossa área está mais do que carente de profissionais qualificados, as chances de crescimento, sucesso profissional e remuneração acima da média só depende do quanto você se dedica, e veja o lado bom, tem tanta vaga a espera que a concorrência é baixíssima. Aproveite a grande vantagem desta nossa área.

Este é um ano especial, sinta a oportunidade.

Me disponho a ajudar, indicar material/blogs/livros, convidar para palestras, tirar dúvidas, orientar. Me procure nos meus links ou deixe um comentário aqui no site e divida conosco seu feedback 😉

Abraços!
Eduardo Pires – Mais um cara tentando ser um dos melhores.

LightSwitch – Um jeito simples de criar aplicações modernas para empresas.

Olá pessoal, trago hoje mais uma novidade da Microsoft, o LightSwitch 2012

Todas as empresas atendem um determinado negócio e hoje em dia é praticamente impossível imaginar que não exista um sistema apoiando o controle do negócio ou pelo menos parte dele.

Desde a papelaria da esquina até um banco, todas empresas necessitam de um sistema, seja ele de apoio aos negócios ou de controle (estoque por exemplo).

As empresas possuem esta necessidade, é vital para seu funcionamento, mas nem sempre estão dispostas a investir financeiramente para adquirir um sistema moderno sob encomenda, tão quanto esperar aqueles meses de projeto para que fique pronto.

Resultado:
Sistemas Access, planilhas Excel, Softwares de prateleira ou até aquele sistema em VB5 que o vizinho tinha desenvolvido uns 10 anos atrás.

Em minha experiência com sistemas já presenciei diversos cenários, um dos mais intrigantes foi estar em um departamento de um banco de grande porte onde todo o processo era controlado por um sistema chamado “Planilhão”. O planilhão fazia tudo, controlava valores, entradas, saídas, diferenças.
Exposição à erros humanos, duplicação de informação e perda de dados era rotina.

Desenvolver um sistema sob encomenda que atenda o negócio de um determinado cliente não é barato para quem compra e não é fácil para quem faz.

Pensando nesse cenário a Microsoft inovou mais uma vez e lançou uma solução:

LightSwitch for Visual Studio

  • Desenvolva rapidamente aplicações de negócio.
  • Obtenha mais de seus dados.
  • Surpreenda os usuários finais.
  • Estenda sua aplicação sem redesenhá-la.

O LightSwitch é 100% RAD (Rapid Application Development).
Disponível para download no Visual Studio 2010, parte do Visual Studio 2012.
Cria automaticamente toda a estrutura (telas, CRUD, pesquisas, visualizações).
O único código que é escrito é a regra de negócios. Possui a facilidade de acompanhar o crescimento do sistema sem maiores manutenções.
Pode ser hospedado no Windows Azure 🙂

Arquitetura:

Arquitetura LightSwitch

Desenvolvedores tem em mãos com LightSwitch uma oportunidade de gerar novos negócios, pois possibilita o rápido desenvolvimento de sistemas, em conjunto com o Entity Framework todas as Entidades são criadas com base na modelagem de dados.

Não tem mais desculpa para usar o velho “planilhão” agora 🙂

Curioso para experimentar?
Abaixo uma série de vídeos passo-a-passo que irá prover todo o suporte necessário para se ambientar com a nova ferramenta:
(Conteúdo oficial Microsoft – Em Inglês) 

1 – How Do I: Define My Data in a LightSwitch Application?
(6 minutos 55 segundos)

2 – How Do I: Create a Search Screen in a LightSwitch Application?
(8 minutos, 58 segundos)

3 – How Do I: Create an Edit Details Screen in a LightSwitch Application?
(5 minutos, 15 segundos)

4 – How Do I: Format Data on a Screen in a LightSwitch Application?
(12 minutos, 52 segundos)

5 – How Do I: Sort and Filter Data on a Screen in a LightSwitch Application?
(9 minutos, 44 segundos)

6 – How Do I: Create a Master-Details (One-to-Many) Screen in a LightSwitch Application?
(9 minutos, 15 segundos)

7 – How Do I: Pass a Parameter into a Screen from the Command Bar in a LightSwitch Application?
(11 minutos, 44 segundos)

8 – How Do I: Write business rules for validation and calculated fields in a LightSwitch Application?
(15 minutos, 55 segundos)

9 – How Do I: Create a Screen that can Both Edit and Add Records in a LightSwitch Application?
(7 minutos, 30 segundos)

10 – How Do I: Create and Control Lookup Lists in a LightSwitch Application?
(7 minutos, 24 segundos)

11 – How Do I: Set up Security to Control User Access to Parts of a Visual Studio LightSwitch Application?
(23 minutos, 52 segundos)

12 – How Do I: Deploy a Visual Studio LightSwitch Application?
(20 minutos 24 segundos)

13 – How Do I: Deploy a LightSwitch Application to Azure?
(12 minutos, 41 segundos)

14 – How Do I: Modify the Navigation of Screens in a LightSwitch Application?
(04 minutos, 19 segundos)

15 – How Do I: Open a Screen After Saving Another Screen in a LightSwitch Application?
(08 minutos, 41 segundos)

16 – How Do I: Connect LightSwitch to an Existing Database?
(15 minutos, 20 segundos)

17 – How Do I: Connect LightSwitch to SharePoint Data?
(15 minutos, 26 segundos)

18 – How Do I: Save Data from Multiple Data Sources on the Same Screen?
(07 minutos, 19 segundos)

19 – How Do I: Set Default Values on Fields when Entering New Data?
(03 minutos, 21 segundos)

20 – How Do I: Copy Data from One Row into a New Row?
(07 minutos, 18 segundos)

21 – How Do I: Add Commands as Buttons and Links to Screens?
(08 minutos, 15 segundos)

22 – How Do I: Show Multiple Columns in an Auto-Complete Dropdown Box?
(02 minutos, 39 segundos)

23 – How Do I: Create Custom Search Screens in LightSwitch?
(18 minutos 22 segundos)

24 – How Do I: Handle Database Concurrency Issues?
(14 minutos 12 segundos)

O objetivo desse post é divulgar a novidade, em breve postarei mais conteúdo como exemplos, códigos e dicas.

Downloads:

Saiba mais em:

Quer ser mais produtivo? Pomodoro Technique!

Olá pessoal, Vamos falar de Pomodoro Technique?

Pomodoro Technique

Codificar nunca foi tarefa fácil, hoje em dia muito menos, telefone, analista de negócios ou clientes com perguntas, sem falar nos e-mails, Twitter, Facebook entre outras distrações do dia-a-dia. Tem dia que não rende mesmo, e quando acordamos sem aquela motivação muito menos.

Técnicas de produtividade existem várias, vamos abordar uma hoje que vem me ajudando e estou gostando bastante.

O Pomodoro Technique foi inventado em 1980 por Francesco Cirillo.
A intenção é transformar o tempo em nosso aliado, mensurando o que devemos fazer e estabelecendo metas de tempo, gerando aperfeiçoamento do trabalho executado.

Vamos a receita:
Um timer (temporizador), material para anotação ou notepad 😉

Cozinhando com concentração, 25 minutos é o Tempo.

  1. Escolha uma tarefa a ser feita.
  2. Programe o timer para 25 minutos (o Pomodoro é o timer);
  3. Trabalhe concentrado até que o Pomodoro toque, então marque ‘ok’ na tarefa;
  4. Faça uma breve pausa (5 minutos são suficientes)
  5. A cada 4 tempos Pomodoro faça uma pausa mais longa.
Basicamente é isto!

Fazendo uma analogia com o filme “A Rede”:
Lembram em que determinados momentos os desenvolvedores do site Facebook estavam “Conectados”, ou seja, fones de ouvido, totalmente alheios ao mundo exterior, não atendiam a chamados, nem olhavam para os lados, foco, foco, foco!
Este é um momento Pomodoro.

Momentos como esse nos tornam extremamente produtivos, elevam a capacidade intelectual e de concentração, nos fazem manter o foco na finalização da tarefa.

E nos intervalos entre 1 ou 4 Pomodoros você pode checar os e-mails, Twittar e etc…

Eu não defendo que tudo deve ser seguido a risca, eu mesmo tenho momentos durante o dia em que realizo cerca de 20 Pomodoros contínuos e pronto, já me ajuda muito a resolver aquelas tarefas que exigem qualidade e atenção máxima, mas sem me sentir uma espécie de robô programador.

Existem alguns aplicativos para ajudar a desenvolver a técnica do Pomodoro:

E para quem quer mais sobre o assunto:

Referências: