Vivendo e Aprendendo.

Um belo dia eu descobri que Analista de Sistemas realmente não existe.

Na semana desse mesmo dia, eu entendi que não se pode FABRICAR um software sob o paradigma de uma FÁBRICA.

Dentro desse mesmo contexto eu avaliei que especializar-se é necessário sim, mas que o excesso de especialistas e a ausência de generalistas acaba por criar células isoladas.

Analista de Requisitos, Analistas de Sistemas, Arquitetos, Programadores, DBA´s Gerentes, Analistas de Teste, Executores de Teste, Analistas de Qualidade, Analistas de Métricas - Penso que a esmagadora maioria dos projetos não precisa de um profissional para cada um desses papéis, e até acho que todos esses papéis se fundem dentro de uma equipe enxuta, coesa, auto-grenciável, e multidisciplinar.

Ainda em meio a essas "descobertas" todas, comecei a encarar o CÓDIGO FONTE de uma outra forma. Antes de mais nada, o código é uma DOCUMENTAÇÃO. E digo mais, é a única documentação viva, certamente atualizada e confiável de um sistema.

Sempre que argumento algo desse tipo para, normalmente um não-programador, escuto coisas do tipo:

"Mas Analista de Requisito não entende de código, e nem deveria entender." Dizem eles…

Bem, quanto a isso eu sou radical. Acho que um mínimo de conhecimento técnico é essencial para QUALQUER profissional de TI que esteja envolvido em um projeto de Desenvolvimento de Software.

Analista de <coloque-aqui-o-que-quiser> que não cohece OO, ou que não tenha condições de transcrever um modelo de classes na tecnologia que está sendo utilizada no projeto, torna-se TOTALMENTE inútil para o projeto.

É óbvio, mas vou destacar, que um "Analista" não precisa ser expert em C# ou em Visual Studio, mas precisa SIM ter uma certa desenvoltura para abrir, compilar, debuggar o projeto; Entender grande parte do que está sendo feito nas classes do projeto, saber sobre o básico da arquitetura do projeto, ter condições de criar um teste unitário simples para validar uma determinada regra ou criar um novo cenário para uma regra já implementada... enfim... até posso concordo que a função principal desse profissional não será ficar com a IDE aberta o tempo todo, mas sim, ele tem que ter condições para trabalhar com ela.

E nesse contexto onde o código fonte torna-se essencial para um projeto, e não apenas um monte de palavras que representam uma meia dúzia de modelos UML, nasce a necessidade do código legível, do código com expressividade. Nasce a necessidade de outra categoria de profissionais de TI. Profissionais esses que não podem ficar se escondendo atrás de papéis e de artefatos, mas sim fazer diferença na equipe. E eu vejo que o mercado está muito carente desse perfil de profissionais.

Agile, muito mais do que uma Metodologia

Poucas vezes eu vi uma discussão tão acalorada quanto essa.

O encurralado está resistindo bravamente, responde até que educadamente a toda aquela enchurrada de críticas, umas construtivas e outras nem tanto.

Siceramente, eu até entendo, com algum esforço, o que o Diego quis dizer. Mas acho que ele errou na mão e no título ao criticar algo que, na minha humilde opinião, ele não conhece muito bem.

Acho que o grande problema está em definir Agile. Agile pra mim é um manifesto antes de tudo (valores), que levou a um movimento e desse movimento surgiram as metodologias (práticas). Então temos:

Manifesto Ágil + Movimento Agile + Metodologias Ágeis = NOVO PARADIGMA.

E esse é o ponto central. Trata-se de uma “nova” maneira de pensar sobre desenvolvimento de software e todo o seu universo, colocando no centro as pessoas.

Então, Agile antes de mais nada é um “novo” paradigma (não em idade mas sim em atitude). É uma forma diferente de entender, encarar e lidar com o Desenvolvimento de Software. Agile potencializa a competência e não tenta esconder a incompetência.

Agile não é pra qualquer um porque desenvolver software não é pra qualquer um, simples assim.

Simplicidade – Métodos curtos

Acho que a evolução de um Desenvolvedor ocorre quando o seu código começa a ficar mais legível e simples. Eu acredito que mais de 80% dos códigos legíveis são simples, mas nem todo código simples é legível.

Kent Beck em Programação Extrema Explicada, cita 4 restrições que define o que é mais simples na visão dele:

O que é mais simples?

1) O Sistema (tanto código como testes) deve comunicar tudo aquilo que você queria comunicar;

2) O Sistema não deve conter código duplicado;

3) O Sistema deve conter a menor quantidade de Classes possível;

4) O Sistema deve conter o menor número de métodos possível.

Os meus 3 últimos meses trabalho foram sempre em projetos legados, as chamadas manutenções. Os Sistemas já estavam em produção e precisavam de reparos ou evoluções. Foram 3 projetos com essa mesma característica, e todos eles estavam com um código bem bagunçado e ilegível, naturalmente complexos.

Nada de padrões de codificação, códigos sem expressividade nenhuma, e métodos muito longos.

Como os sistemas estavam funcionando, e os Gerentes normalmente colocam os prazos apenas olhando o que deve ser feito como manutenção, nunca posso refatorar tudo o que eu queria e nem do modo como eu gostaria. Então, a primeira providência que eu tomo é quebrar os longos métodos.

Agindo dessa forma, de cara eu consigo:

1. 1) Identificar de fato o que cada método faz ou deveria fazer;
2. 2) Começar a organizar a “bagunça”;
3. 3) Identificar e eliminar código duplicado;
4. 4) Minimizar o impacto de futuras mudanças;
5. 5) e por sim, simplificar um pouco mais as coisas…

Eu acredito que método curto normalmente:

1. 1) Faz somente o que deveria fazer;
2. 2) Torna-se fácil identificar o seu objetivo;
3. 3) Pode ser reaproveitado mais facilmente;
4. 4) Torna o código do sistema mais legível.

Bem, mas voltando ao início do post, Kent Beck define uma regra para simplicidade que é: O sistema deve conter o menor número de métodos possível.

O resultado das minhas refatorações, tentando quebrar os métodos longos, é uma quantidade bem maior de métodos na classe. Mas mesmo tendo uma classe com mais métodos do que no início, o resultado que eu percebo (e outros membros da equipe também) é que tudo fica muito mais simples. Bem, é verdade que fica mais simples do que estava, e é isso que hoje eu entendo. Agora eu sei que, deixar as coisas mais simples que antes não necessariamente é deixar as coisas simples.

Mas como explicar para o Gerente que precisamos “arrumar a casa” para tornar as coisas bem mais fáceis? Como refatorar com eficiência e produtividade sem uma cobertura de testes?

Cada vez mais vejo que codificar é modelar, e as práticas de XP fazem todo o sentido. Arrisco-me a dizer que, não existe como ter um projeto de qualidade e sustentável sem adotar ou adaptar as práticas de XP.

Você Testa o seu Software? Como?

É realmente interessante e animador ver a grande quantidade de material, artigos, palestras e demais conteúdos sobre Testes proliferando na web. Isso mostra que estamos amadurecendo…

Acho que muitas vezes, nesse caso específico de testes, não tem meio termo. Ou testamos o nosso código ou não estamos fazendo um software de forma profissional. Podemos variar em fazer TDD ou não, ter uma cobertura 100% de testes, enfim. Mas a única coisa que não podemos é deixar de testar.

O que eu acho engraçado é que eu sempre escuto por aí que desenvolvedor não gosta de testar. Mas eu nunca conheci nenhum desenvolvedor que desse o seu trabalho como pronto sem antes rodar a aplicação e ver se o código que ele acabou de desenvolver está se comportando como o esperado. Pois bem, isso é testar. E eu acho até que isso é muito divertido, ver o código que você escreveu se comportando como você planejou.

Claro que, ficar testando as diversas possibilidades de cenários para os erros e tentar encontrar um bug no seu recém nascido (código) não é tão divertido assim. Mas o que eu quero chamar a atenção é que sempre, de uma maneira ou de outra, estamos testando o nosso código. E o pior é que os nossos testes são às vezes muito chatos pois precisamos rodar a aplicação, encontrar a tela no menu da aplicação, preencher diversos campos de um formulário da forma correta, clicar no botão que irá disparar a ação no formulário e enfim começar a debuggar o código pois, a maioria dos nossos testes são via break point! Isso sim pode ser muito chato.

Mas, quando criamos um novo método e escrevemos um código de teste para ele, não precisamos de nada disso. Precisamos apenas clicar em run e ver os verdinhos aparecendo na nossa tela, dizendo: Sim!! você estava certo e seu código está funcionando!! Isso sim é divertido!

Então, eu realmente não entendo a resistência que existe em criar testes unitários automatizados. E indo um pouco além, criar o teste antes pode até ser bem mais divertido. Nos ajuda a pensar, nos dá um desafio mais objetivo e por fim garante que realmente estamos criando os testes para o nosso código.

A diferença é que com os Testes unitários automatizados conseguimos testar muito mais vezes de uma forma muito mais rápida, e aos poucos podemos incrementar os nossos testes ampliando a qualidade do nosso código, além de todos os inúmeros benefícios que os Testes trazem.

Então, alegar qualquer motivo para não testar é uma tremenda incoerência, sendo que necessariamente vc irá testar o código ou a funcionalidade que você acabou de implementar, de um jeito ou de outro.

Então, Sim!! é claro que você testa o seu software. Resta saber se você testa bem e é realmente eficiente no seu teste… ou ainda, se você testa da maneira correta e esperta, ou da maneira burra e improdutiva.

Requisito/Análise é o mais importante?

Na faculdade eu “aprendi” (!?) que a parte mais importante de um software é o Requisito. Também com uma vital importância encontra-se a Análise que realizamos baseada nos requisitos para chegarmos a um projeto de Software bem modelado, detalhado e definido. Após essa fase, dizem os “professores” (!?), teremos um conjunto de artefatos que possibilitará aos programadores apenas transcrever os requisitos em código. Feito isso, temos o nosso Software funcionando.

Bem, nunca é demais frisar que isso (o parágrafo a cima) não funciona. A (?) fase de análise (?) ou a Identificação dos requisitos, é apenas uma exploração. Trata-se de um pequeno passo na CONSTRUÇÃO (Código!!) de um software. Pequeno mas importante passo, é claro. O fato é que a única forma correta de validarmos os requisitos de um software é codificar o software e entregar uma parte dele para o cliente usar. Dessa forma sim, saberemos se estamos no caminho certo, e se os requisitos são aqueles mesmos que foram identificados.

Temos que entender que Codificar também é modelar (vide TDD). E precisamos aprender de uma vez por todas que modelagem gráfica (modelos e diagramas UML) ajuda na comunicação da equipe, ajuda a modelar também, mas que só poderá ser dada como válida ou correta após a implementação da mesma, do contrário é tudo especulação, é tudo desenho e ainda é uma abstração incompleta de um sistema.

Existem mais coisas importantes num ciclo de desenvolvimento de um software além do código… mas, quando vemos um software funcionando, a única certeza que temos é que ele foi realmente codificado por algum programador. Além disso, um software em produção está apenas iniciando a sua vida, então, mesmo tendo a melhor documentação do mundo, se o código estiver podre e mal cheiroso, essa documentação não irá adiantar de nada. Mas, se não tivermos nenhuma linha de documentação ou especificação desse produto mas o seu código for legível, coeso, expressivo, organizado, padronizado e possuir uma boa cobertura de testes, tenha certeza de que manter esse software será algo simples e divertido.

A verdade é que não existe, ou não deveria existir, uma separação entre as fases de requisito/análise e desenvolvimento. Vejo que é justamente tentando separar essas fases é que caimos numa perigosa cascata.