Métodos frágeis

Uma das práticas mais desastrosas que eu já vi é a de nomear artefatos com os códigos dos casos de uso. A motivação é boa (relacionar os casos de uso ao código que os implementa), mas, como geralmente acontece quando os primeiros princípios são levados adiante por muito tempo antes de se dar uma espiadinha na realidade, o resultado é terrível.

Por exemplo, há quem dê aos JSPs de um projeto Java nomes como "UC123.jsp". Já vi até classes com esse tipo de nome.

Em primeiro lugar, poucos artefatos relacionam-se a apenas um caso de uso. O que o programador vai fazer para resolver isso? Não podemos chamar um JSP de "UC123,127,201.jsp". Em segundo lugar, fica muito difícil ler e encontrar o código que queremos em projetos grandes.

Em terceiro lugar (e este é o motivo mais importante), essas tentativas de burocratizar o código alienam todos os programadores que amam seu trabalho e que preocupam-se com a qualidade do que escrevem. Código bom tem qualidades estéticas para quem sabe apreciá-lo e esse tipo de nome obscurece qualquer tentativa de prover elegância a uma arquitetura.

Ramais rebeldes

Descobrir o ramal de uma pessoa é muito fácil. A intranet os tem todos. Mas algumas pessoas mais antigas (mesmo que de espírito) gostam do velho hábito de usar a telefonista. Como elas não existem mais, alguém vai cumprir o papel, mesmo que involuntariamente!

Então, em nome da paz no ambiente de trabalho, uma técnica pavloviana e pacífica deve ser usada para treinar os preguiçosos chamadores.

A técnica é simples e consiste em, inicialmente, fazer o chamador pensar que a chamada será redirecionada para o alvo pretendido. O treinador deve dizer que "vou passar a ligação para o ramal XYZ", mas deve colocar ênfase e repetir o número com "se a ligação cair, o ramal é XYZ". Então, aperta-se o botão para transferir e coloca-se o telefone no gancho, para que a ligação caia.

Se o chamador insistir, basta repetir a operação. É garantido o resultado em, no máximo, três chamadas (exceto para alguns casos extremos, geralmente restritos a peixes dourados).

Força superior

O usuário aproximou-se com um ar otimista e afirmou que "precisamos disponibilizar este software na intranet". A prática me levou a temer esses arroubos dos usuários. Fiz uma cara amigável e perguntei se o programa era para desktop ou para web.

Era desktop, claro. Mas isso é ruim? O diretor autorizou a publicação do sistema na intranet. Já está tudo aprovado.

Ah bom! Se o diretor aprovou a publicação na intranet, então não temos nada a temer. Vou retornar o workflow com um pedido de esclarecimentos.