Quando se faz um contrato de desenvolvimento e manutenção de sistemas, imagino que uma série de cuidados são tomados em sua redação: o contrato é revisto por inúmeros departamentos, passa na mão de várias pessoas, cada uma tentando achar aquele “pelo de ovo” que pode fazer com que de lucros exorbitantes a contratada passe a ter prejuízos fatais.
É muito triste ver, com muita frequência, que este cuidado tomado no começo do projeto não seja mantido ao longo dele.
O que eu vejo é que, tipicamente, fechado o contrato, a empresa contrata uma centena de programadores, fala do SLA, pode até dar um cursinho de programação na arquitetura do sistema, e daí larga os “minino” pra programar. Nesta hora, tudo o que interessa é cumprir os prazos acordados. E pode acontecer uma situação como a que descrevo a seguir.
Alguns anos depois do início do projeto, Minino, programador que estava desde o início no projeto, morreu.
Algumas semanas depois, o cliente reclamou que a rotina de faturamento não estava funcionando corretamente. Então os gerentes de projeto descobriram que Minino cuidava justamente da rotina de envio de faturas. Como a rotina era crítica, era sempre Minino que fazia a manutenção. Afinal, Minino “corrigia as coisas rápido pra danar” e suas correções eram sempre aprovadas pela equipe de QA de código fonte e de Testes Funcionais.
Aí, a gerência chamou Fulanim, o programador mais experiente da equipe, pra verificar o problema. Após passar algumas semanas olhando a tela fixamente, até baba sair dos cantos da boca, Fulanim é internado em uma clínica psiquiátrica: Minino fez pós-graduação em computação quântica, e resolveu utilizar um algoritmo obscuro no código, que chamaremos de PoliX, que só Minino conhecia: ninguém mais parecia ser capaz de dar manutenção na rotina de faturamento. O cliente ficou muito insatisfeito com isso, o SLA foi pro espaço, e o projeto desceu pelo ralo.
Existem várias formas de se evitar o problema demonstrado.
Porém, quero propor algo que seria intermediário entre a revisão formal e a programação em pares: em períodos específicos, de preferência frequentes, uma semana no máximo, os membros da equipe fazem uma revisão cruzada em pares: Fulanim revisa o código de Minino, e Minino revisa o código de Fulanim, em uma entrevista rápida. Além disto, a alternação entre pares deve acontecer: Fulanim revisa o trabalho de Minino num dia, daí Juquim revisa o trabalho de Minino em outro dia. No dia em que Minino tentar usar o PoliX, o seu revisor naquele dia, Fulanim, vai pegar Minino na consumação do ato, e uma das duas coisas pode acontecer:
É possível identificar os seguintes benefícios diretos da adoção da Inspeção Frequente:
Ainda há muito a ser refinado neste procedimento, e algumas questões a serem respondidas. Espero não morrer até lá…
You must be logged in to post a comment.
9:26:54 am
Penso que a empresa deve arcar com as consequencias da falta de visão e atualização bem como mente fechada dos seus proprietários. Os métodos ágeis propõe novas abordagens de parceria e colaboração cliente-fornecedor que podem ser bem interessantes em relação a esse assunto abordado, inclusive o autor menciona o “XP”. Infelizmente a cultura da corporação e a politicagem que hoje em dia são muito presentes nem sempre propiciam que sejam aplicados os métodos e soluções mais apropriados. Que se pague o preço, sem choro!
10:44:15 am
Bem, não entendo muito de códigos. Não é propriamente a minha área. Porém sou focado na solução de problemas. Assim, entre manter pessoas fazendo revisões de código e solucionar o problema eu sempre opto pela segunda alternativa. Então pergunto: Não seria mais fácil estabelecer padrões de codificação os quais devem ser seguidos por todos os programadores? Pergunto: Não seria melhor abrir uma frente para reescrever o código e eliminar o problema da manutenção corretiva constante?
Para mim fica claro que se uma rotina tem muita manutenção é melhor reescrevê-la. O custo da tarefa é bem menor do que o custo da manutenção e das rotinas constantes de revisão.
É só ver o histórico de frequência de manutenções de um determinado código para saber a onde está pegando. O resto é Gestão de Projeto de Manutenção.
11:56:01 am
Sergio, o Problema é que código sempre é um texto, uma redação, e a lógica é a ideia inspirada no momento para resolver uma situação (criar a rotina da funcionalidade esperada). Sendo assim, por mais que se crie padrões de código, o item criatividade sempre está presente e a criatividade está ligada também ao conhecimento. Esses fatores, criatividade e conhecimento, podem ser armadilhas para os novatos, E não é interessante, mesmo em desenvolvimento de sistemas nivelar a capacidade e criatividade por baixo. Ou seja, nivelar pelo programador como menos criatividade e conhecimento é deixar um sistema pobre. Rotinas que poderiam ser feitas com 5 linhas passam a ser feitas com 200 nesta concepção.
Sem contar outros fatores.
Na minha concepção o problema não está somente no desenvolvimento mas no levantamento dos requisitos que visa meramente entender as necessidades do cliente. Em meus 25 anos de desenvolvimento de sistemas eu aprendi que: o que o usuário precisa, nem sempre é o que o usuário quer. No entanto, uma pessoa com excelência tecnológica não necessariamente vai fazer levantamento adequado pois não consegue ver as entrelinhas.. aquilo que o usuário não consegue mostrar conforme e as vezes é mais importante do que aquilo que ele está pedindo. Isto gera Casos de uso que serão bem desenvolvidos, seguindo todos os padões de código porém com um nível de manutenção altíssimo.