Se eu fosse um novato, recém integrado na faculdade, sem base acadêmica para duvidar de um Dr. [ou quase] eu estaria destruído com minha ignorância.

Esse é o temor que tenho da academia, a sua falta total de pé-no-chão ou conhecimento real daquilo que ensina, é o que me fez abandoná-la e nunca mais pisar por lá.

Tantas citações a obras importantes é típico da academia, mas o discurso que eu gostaria de ouvir não existe:

“Quando eu implantei CMMi na XPTO…”

“Quando eu trabalhava com RUP, nós…”

Na prática a teoria é outra

Caro Dr., eu estudei muito sobre isso, li todos esses documentos e até cheguei já a acreditar que eram válidos para garantir a qualidade de um produto. Claro, isso no início desse século quando eu era estagiário e sem conhecimento real.

Depois de passar por implantação de CMMi mais de uma vez, ISO e Mps.Br, foi que aprendi o valor da teoria e como aquilo que está escrito não reflete a realidade na “engenharia de software”.

Talvez o que mais me marcou em verificar que não existe engenharia de software [ou ela é ainda muito incipiente] foi ter participado de avaliações ISO em outros setores como indústria, imobiliária e serviços. Fica evidente para todo mundo que a avaliação nesses setores é de processo e não de produto e serviço porque eles tem métricas reais e aplicáveis em suas industrias.

Quando CMMi ou ISO falam em qualidade de produto eles não dizem como fazer e sim o que fazer, essa é a diferença básica entre processo e produto, caro Dr.

Essa bobagem semântica  faz toda a diferença, quando eu avalio a qualidade de um produto como uma garrafa PET, existem métricas reais para testar a qualidade [como por exemplo durabilidade], existe um processo normatizado por órgãos [como ANATEL, ANVISA, e tantos outros] que garantem a qualidade mínima do produto ou serviço.

Esse foi o seu primeiro erro conceitual, dizer que tem que fazer é diferente de dizer “como” tem que fazer. “O que” é processo, DR. “Como” é produto, Dr.

Testes de Software

Vou fazer um mea-culpa porque quando escrevo eu sempre esqueço que meus leitores não me conhecem e não podem advinhar o que fica nas entrelinhas, eu não gosto de citar referências por preguiça de sair catalogando nomes de livros e autores [só quando lembro na integra de cabeça e acho importantissimo] e espero que as pessoas não acreditem em uma só linha sem verificar. Como vão verificar, eles acham a referência por si só, não preciso colocar bibliografia nos meus textos.

Esse trecho fica evidente que falho por omissão:

Há controvérsias sobre testes automáticos garantirem qualidade interna, na verdade, não vejo onde há relação direta. Testes são sim de suma importância, independentemente de serem automatizados ou não, que fique claro, mas não garantem totalmente a qualidade, nem externa e muito menos interna (em breve explicarei o porquê), muito menos é o único método para se conseguir qualidade. Inspeções e revisão de software (e especificações associadas), juntamente com analisadores estáticos, são tão efetivos quanto testes na detecção de defeitos e tem possibilidade maior de melhorar a qualidade interna de produtos de software.

Quando falo em testes, é óbvio para quem me conhece que estou me referindo sobretudo a TDD e também BDD. Testes por si só não garantem nada, nem sequer que as falhas estão cobertas.

O processo de TDD é que fortalece a qualidade interna do software porque ao você aplicar as práticas desse processo, você se torna minucioso na verificação de coesão, complexidade, acoplamento sem precisar de ferramentas de análise de código.

Eu não estou afirmando que não use ferramentas de análise de código, longe disso, só que essas ferramentas não verificam qualidade real no código, no máximo elas avaliam erros clássicos e mau cheiro no código. É perfeitamente possível escrever um código horroroso e ilegível e passar por todas as ferramentas de análise de código facilmente, isso acontece na prática no cotidiano.

Como testar?

Antes de me dizer, responda-me: Você faz que tipo de teste? Unitário, integração, sistema, aceitação? Testes funcionais, estruturais ou baseados em defeitos? Para testes funcionais, você utiliza classes de equivalência, análise de valor limite, grafo causa-efeito e ainda tenta error-guessing? Para testes estruturais, você aplica grafos de fluxo de controle? Como define seu critério de cobertura de instruções, decisões, condições e caminhos? E quais das métricas já citadas ou quaisquer outras tem adotado? (Zhu, Hall and May, 1997) Se você não tiver uma boa estratégia para cada uma destas táticas, sinto muito informar-lhe, mas VOCÊ NÃO SABE TESTAR SOFTWARE.

Eu não sigo as estratégias do Zhu “Who?”, eu sigo um AMADOR SEM EDUCAÇÃO chamado Kent Beck que não é nada científico mas funciona. Sim, eu faço testes unitários, integração, aceitação, stress, carga e o que der mais para fazer com o tempo disponível para entregar o software o mais saudável possível. As ferramentas de análise de cobertura são frágeis e deixam escapar a real cobertura, da qual temos que aplicar triangulação e outras práticas não-acadêmicas criadas por AMADORES SEM EDUCAÇÃO.

O bacana de tudo são esses números:

Ou seja, mesmo que você tenha 100% de cobertura, você terá apenas garantia de detecção de defeitos em 25% dos casos (Glass, 2002).

Minha vó dizia que os números quebrados tem mais credibilidade, se fosse pelo menos um 25, 37%… vá lá.

Não estou a par de nenhum estudo rigoroso que mostre relação positiva entre presença de testes automáticos e código mais coeso, desacoplado, limpo, claro e legível também.

Dr. o mundo não vive de Papers apenas, saia da academia e visite uma empresa que faça TDD e outra que não, o senhor avaliará por si só. Alias, quem deveria fazer esses estudos era a academia, não? Como farão se não saem às ruas?

Caso alguém tenha, por favor, entre em contato. Gostaria de saber também, se possível, quais processos preocupam-se com qualidade externa em detrimento de qualidade interna. Seriam os processos ágeis?

Todos os processos avaliam qualidade externa pelo que escrevi acima.

O seguinte trecho quase me faz não responder esse artigo:

Por fim, o PROJETO é a quarto e última variável necessária para construir software, porque planejamento e gerenciamento são nossas únicas armas para controlar a complexidade

O que diabos complexidade tem a ver com planejamento e gerenciamento?

Desde quando voce planeja a complexidade de um software?

Fazendo notação matemática do algoritmo?

Desculpe, mas nem todo mundo tem o tempo do Dr. Knuth para entregar software, precisamos de verificação rápida e não notação matemática e não existe um mecanismo que faça isso antes de ter um software escrito.

Novamente, o projeto pode ser tão detalhado e formal quanto se queira.

Não, DR. O projeto não pode ser tão detalhado e formal quanto o queira, isso eu acreditava antes de fazer coisas reais e ficava apenas em cima de livros, se a engenharia de software realmente existisse, eu tinha mecanismos reais para fazer esse detalhamento, mas hoje esses mecanismos reais não existem.

Cada vez mais me convenço de que a academia está morta e não produz nada de real, apenas papers repetitivos de bobagens que ninguem lê.

Deveriam ter terminado a notação formal da orientação a objetos mas estão preocupados demais com “modelos de qualidade” [sic] que nunca avaliaram na prática e não fazem idéia de como mensurar.

Isso não é científico, Dr.

Um grande problema na compreensão sobre Scrum é justamente achar que ele serve para gerenciar projetos, dessa forma para ser confundido com um PMBOK ágil é um passo. Gerência de projetos é um campo distinto da direção do desenvolvimento de software e não vou tratar ou especificar nesse artigo porque já rascunhei em artigo passado.

Scrum é um modelo de desenvolvimento de software. A Scrum Alliance que é uma espécie de “organismo” que rege a maturação do Scrum, não o definiu como Project Management, mas como:

“Scrum is an agile software development framework.“

Scrum é similar ao XP ou FDD, guia a equipe com um modelo baseado em práticas para um melhor desenvolvimento de software. Como esse pessoal – que muitas vezes nunca foram técnicos – encontra em Scrum práticas fortemente ligadas ao controle das iterações, transmuta toda a cultura burocrática adquirida em metodologias de gerência de projetos e confunde atividades – como avaliação de riscos e aquisição e controle de recursos – com as necessidades do time jogando fora o que os incomoda – como práticas necessárias ao desenvolvimento – e ficando apenas com o que sentem confortáveis.

Quando James Shore escreveu seu famoso artigo “The Decline and Fall of Agile” ele definiu isso muito bem fazendo analogia que estavam correndo para a sobremesa mas jogando fora os vegetais. Martin Fowler em seu artigo Flaccid Scrum [Akita traduziu e comentou], escreveu ter notado que o problema técnico acontece mais com Scrum devido a não prescrição [omite] de práticas técnicas e ser centrado em técnicas de “gerenciamento de projetos”, ou seja, o problema é de qualidade técnica interna.

Hoje todo mundo se diz Scrum Master, todos entendem e usam Scrum e mesmo assim já estamos vendo projetos com Scrum caírem no mesmo erro e problema de modelos anteriores. Como disse o Martin Fowler em seu artigo: “Esses projetos de Scrum flácido em andamento prejudicarão a reputação não somente do Scrum mas de todo Agile”.

Scrum é uma metodologia maravilhosa que tem muito a engrandecer o XP e as outras metodologias, mas usando um Scrum transviado de PMBOK é um caminho natural ao fracasso retumbante.

Solução?

Eu poderia escrever dezenas de linhas aqui com conselhos e bla-bla-blas mas vou ser direto e lacônico: XP.

Essa base mínima eu proponho que seja – dentro do modelo exposto -  raciocínio lógico. O resto ele pode aprender.

Raciocínio lógico está ligado diretamente a noção de avaliar a situação, encontrar um padrão, investigar soluções existentes e implementar a solução, além claro de bom senso.

Não adianta pregarmos que os profissionais deveriam ser melhor escolhidos assim ou assado porque a realidade é que as empresas não tem como medir satisfatoriamente quem é ou não competente e mais cedo ou mais tarde você se deparará com indivíduos em sua equipe vindos por diversas nuances administrativas, seja aquele superqualificado cheio de títulos ou o primo do diretor da empresa.

Aonde quero chegar com essa história?

Precisamos avaliar os riscos necessários com bastante antecedência para que toda a equipe e consequentemente o projeto não sejam lesados e paguem o preço da incompetência às vezes de um único elemento. Parece óbvio? Acredite, não é!

Temos um projeto em um cliente – uma Alfândega – que precisamos refatorar todo o código criado por um determinado profissional com apenas dois ou três meses pronto. O projeto ainda está no início e já temos que refazer código.

Convenhamos, tudo bem que o código de meia hora atrás já é legado, mas código tão recente não deveria já ser refatorado sem mudança na lógica de negócio ou arquitetural. Algo muito errado aconteceu.

Mudanças não funcionais acontecem, surge um novo paradigma ou framework que reduz o tempo de desenvolvimento e convenientemente é adequado sua mudança, isso é comum durante a manutenção de um software já em produção com um meio século de uso – que em informática dura cerca de 4 ou 5 anos.

O nosso em questão não há motivos. Projeto novo, sem restrição ou adequação à “Arquitetura de Referência”, Frameworks de última milha na plataforma Java como JSF, Spring e Hibernate. Testes unitários – mas não TDD.

Como dito, separei um exemplo em código para demonstrar aonde quero chegar. Tem uma lógica bastante simples, existe um processo de apreensão de mercadorias na alfândega e liberação dessa mercadoria.

Há 3 tabelas que representam isso no modelo E/R: TB_DEVOLUCAO, TB_ITEM_APREENSAO, TB_ITEM_DEVOLUCAO. Segundo a lógica relacional, a TB_ITEM_DEVOLUCAO é uma tabela de junção entre a devolução e os itens apreendidos para indicar que item será devolvido.

Seguindo minha definição, um profissional com raciocínio lógico encontraria fácil a solução do mapeamento entre essas entidades apenas lendo a documentação, ele saberia que o Hibernate tem um mapeamento de OneToMany com Join Table Uni ou Bidirecional.

Mas não, ele criou essa bizarrice:

@Entity
@Table(name="TB_DEVOLUCAO")
public class Devolucao {
 
	@OneToMany(fetch=FetchType.LAZY, cascade=CascadeType.ALL)
	@JoinColumn(name="SEQ_ITEM_DEVOLUCAO")
	@Cascade(org.hibernate.annotations.CascadeType.DELETE_ORPHAN)
	private List<ItemDevolucao> itensDevolucao = 
		new ArrayList<ItemDevolucao>();
 
}
 
@Entity
@Table(name="TB_ITEM_DEVOLUCAO")
public class ItemDevolucao { //Para que essa entidade?
 
	@Id
	@GeneratedValue(strategy = GenerationType.IDENTITY)
	@Column(name="SEQ_ITEM_DEVOLUCAO", columnDefinition="NUMERIC")
	private Integer codigo;
 
	@OneToOne
	@JoinColumn(name="SEQ_ITEM_APREENSAO")
	private ItemApreensao itemApreensao;
 
}

Esse profissional em questão é graduado em computação, tem mestrado em uma federal, certificação como arquiteto Java e diversas outras certificações e pasme, anos de experiência em projetos. Mas não tem o básico, raciocínio lógico. Não investiga e não sabe desenvolver software de qualidade.

O código em questão pode parecer bobagem até mas isso se repete em todo o código criado por esse profissional.

Um profissional responsável em refatorar o código com apenas curso técnico e uma mísera certificação de programador java refatorou assim [como deve ser]:

@Entity
@Table(name="TB_DEVOLUCAO")
public class Devolucao {
 
	@OneToMany(fetch=FetchType.LAZY, cascade=CascadeType.ALL)
	@JoinTable(name="TB_ITEM_DEVOLUCAO",
		joinColumns = @JoinColumn(name="SEQ_ITEM_DEVOLUCAO"),
		inverseJoinColumns = 
				@JoinColumn(name="SEQ_ITEM_APREENSAO")
	)
	@Cascade(org.hibernate.annotations.CascadeType.DELETE_ORPHAN)
	private List<ItemApreensao> itensDevolvidos = 
				new ArrayList<ItemApreensao>();
 
}

Ad Hominem da minha parte? Tomar uma exceção pela regra? nada disso, eles são legião! Isso é meu cotidiano.

O prejuízo que esse profissional acarreta a todos os envolvidos é enorme e até difícil de ser mensurado porque envolve custos e humor da equipe que impacta em outros custos imperceptíveis na conta final que é a “fodisse” dos caras que tiveram que refatorar, ou seja, fizeram o seu e o trabalho alheio.

Ah, mas XP não prega o código coletivo? ir lá e consertar? Mas quebra o principal valor que é “Respeito”. Além do mais o projeto em questão seque o velho Cascata – mas culpa do cliente que exigiu ser assim, exigiu não, obriga.

Pela minha experiência de nada adianta você jogar um Clean Code nas mãos dele e pedir para estudar, ele vai continuar escrevendo nmDesc em uma propriedade ou IRepository em uma Interface. Ele foi treinado assim e sem raciocínio lógico no máximo que voce vão conseguir é retreiná-lo para conseguir comer a banana por outro túnel.

Um projeto sem um líder técnico responsável com aptidão e experiência necessária aliado a método baseado em BDUF sem um processo restritivo [como TDD] com modelagem ultrapassada com papéis de analista de sistemas “UMLizados” deixa esse tipo de profissional cometer esses pecados e prejudicar a todos os envolvidos retrabalho desnecessário.

É fácil resolver isso? É! O problema maior é que não podemos simplesmente aceitar que “o cliente quer assim”, temos um dever ético com nossa profissão de não permitir que o paciente escolha como ele quer ser operado e ceder médicos que não tenham capacidade de operá-lo.

Existe um tipo de falácia bem comum que está crescendo ultimamente se aproveitando da célebre frase: Não existe bala de prata!

Quando invocamos a necessidade de não considerar todos os problemas como um prego e a única arma um martelo, não estamos fornecendo a chave da irrestrita flexibilidade irresponsável.

Quando assumimos que em tudo depende, não estamos dizendo que não há uma fronteira. O avanço significativo do cálculo só foi possível com o advento do limite matemático.

Fazer ciência é investigar e fazer a pergunta certa ao contrário da resposta certa. Para isso identificamos padrões e formulamos teorias.

Antes de abandonar uma teoria devemos substituí-la por outra mais apropriada. Isso soa conservador mas é preciso para se fazer ciência, propor o abandono de uma determinada teoria sem a substituição por outra mais adequada é leviano.

Para entender como algo funciona não podemos simplesmente achar que qualquer solução é válida e sim descobrir qual a solução adequada.

Entender que existem soluções mais apropriadas – e que sim, existe um jeito certo ou um modo melhor de se fazer algo – não quer dizer que outras abordagens simplesmente estão erradas,  podem ser apenas incompletas e/ou inviáveis.

Em muitas discussões que tenho travado ultimamente sempre quando tento argumentar que uma solução específica é melhor do que determinada outra, ouço:

“Não existem balas de prata”. Bingo!

Essa pessoa não entende ou não quer aceitar por motivo qualquer que a solução dela está errada ou não satisfaz.

Aqui a proposta é pontual, para determinado conjunto de fatores existe uma solução mais adequada, isso é fato.

Existem Balas de prata!

Mas como somos fans de Supernatural, sabemos que o que mata é acertar no coração. O trabalho deve ser direcionado a combater a complexidade no coração do problema e não simplesmente num jogo de escolher a ferramenta certa.

Na área de desenvolvimento de software a maioria dos desenvolvedores se apegam a uma metodologia/ferramenta/arquitetura e tentam encaixá-la para a construção de qualquer sistema. Não entendem que aquela solução não vai resolver todos os problemas.

Até aqui tudo bem, o problema é aproveitar a defesa de que não existe uma ferramenta para todos os propósitos e considerar que “não existe o melhor” ou a “forma apropriada”, quando justamente por não existir ferramenta universal é que devemos usar algo por sua especialidade.

O manifesto ágil tem um trecho que diz:

“Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo.”

Observe que ele diz “melhores” e não “diferente” ou “de outra forma“.

No final diz:

“Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.”

Aqui reconhece que os itens à direita não estão errados, apenas que os da esquerda levam a uma melhor forma de tratar o campo específico que é desenvolver software.

Tentar levar o manifesto ágil para gestão de projetos, construção civil ou limpeza da sua casa o faz ser uma bala de prata e que não vai matar nada porque você não está atigindo o coração, apenas tentando criar um martelo genérico para um uso universal.

Todo o “KnowHow” associado ao manifesto ágil se refere única e exclusivamente ao processo de desenvolver software da melhor forma, atinge o pontual.

Agiletards sabem ser chatos também quando seguem metodologias de caixinhas e querem criar um novo dogma de desenvolvimento de software.

Existe o melhor e a forma mais adequada, procurar é nosso dever!

via Twitter @dalmaer

Ressalto a seguinte observação:

“A conclusão que nós chegamos é que engenheiros de software possuem o poder que falta para engenheiros civis/arquitetos e ainda assim usam as ferramentas de quem não tem este poder.”

Se alguém não entender essa frase eu posso desenhar, mas está claro e perfeito. Discussão encerrada.

Mas como sou um pessimista, sei que muitos [os de sempre] vão contestar com as mesmas falácias e sofismos.

Mas vá lá, leia o post inteiro e tire suas próprias discussões.