Sabe por que o código fonte dos outros é ruim? Porque os programadores começam o projeto sem saber quais partes do Software precisam de código realmente bom e, pior, não refatoram no decorrer do projeto. Estas partes do Software são as que mais sofrem manutenção, as mais sujeitas à bugs e alterações futuras. Para facilitar a explicação vamos chamar estas partes de Partes Relevantes.

Pois bem, sabemos que o código não vai ficar bom em 100% das partes do Software. Então, a chave é fazer o código bem feito onde ele precisa ser bem feito, ou seja, nas Partes Relevantes. O problema? No início de todo projeto sempre há aquela preocupação em fazer tudo genérico, bonito, organizado, etc. E justamente neste momento sabemos muito pouco sobre as Partes Relevantes. Como resultado, acabamos perdendo muito tempo implementando coisas bonitas e genéricas onde não precisava e isso toma justamente o tempo que deveríamos dedicar à… quem? quem? às Partes Relevantes do Software.

Então um outro programador assume o nosso código e, obvimante, ele terá que mexer…bem, você sabe aonde. E não importa o quanto seu código está bom nas outras partes pois ele não vai nem entrar nelas. Você teve sim a preocupação em fazer um código bom, mas fez isso no lugar errado pois não sobrou tempo para fazer no lugar certo. Por isso, o outro programador vai achar que o seu código é uma merda pois ele sabe do código bom que ele é capaz de fazer (mesmo que ele o faça onde não precisa) e está vendo a parte do seu código que até você tem vergonha. Então ele vai ficar dando palpites no seu código – mas agora é fácil, pois neste momento as Partes Relevantes são evidentes. Até que um dia ele precisa implementar um conjunto de funcionalidades novas e o ciclo se repete (outro assume, critica, faz bem onde não precisava e mal onde precisava). E assim continuamos achando sempre que o nosso código é melhor do que o dos outros pois sempre analisamos no final, numa atividade onde uma das coisas mais importantes é entender realmente o que precisa ser feito.

Mas eu desconfio que este ciclo poderia ser quebrado se a Refatoração fosse levada a sério. Eu disse: LEVADA A SÉRIO! Não falo do mito da refatoração no final do projeto. Falo em Refatorar sempre que adicionar uma nova funcionalidade, por menor que seja. Falo em adaptar o código existente para que esta nova funcionalidade se encaixe como uma luva sem a necessidade de “ifs” para tratar casos não previstos. Se o caso não foi previsto eu não vou colocar um “if” (ou violar os princípios de OOP) para que funcione, eu vou mudar o código existente para que ela se encaixe como se tivesse sido prevista desde o início.

Quando você Refatora corretamente o código fica melhor com o tempo pois a cada nova funcionalidade você entende melhor o que precisa fazer. A cada funcionalidade nova você entende melhor quais são as Partes Relevantes. Por outro lado, quando você não Refatora o código fica ruim com o tempo pois você está ignorando o que está aprendendo de novo sobre o que precisa de fato ser feito.

Para quebrar a rotina dos meus posts geralmente longos, esta eu peguei no Stackoverflow.

Excelente!

Que tem muito gerente incompetente, assim como muitos “subordinados”, todo mundo já sabe. Mas, o que eu quero entender é o meio e não o fim. Quero entender é porque a maioria dos gerentes de TI são uns bostas. Ao contrário do que você pode pensar isto não é um desabafo. Já tive contato com muito gerente bosta, mas enquanto escrevo este texto não penso em nenhum deles. Na realidade o que me motiva escrever este texto é um receio que um dia eu jogue neste time. E porque isto também pode acontecer com você, tentarei criar um cenário que tenta explicar alguns dos motivos pelo qual isto acontece.

Tudo começa quando você decide fazer um curso de exatas. Você toma esta decisão porque odeia os assuntos relacionados a humanas. Você, provavelmente odeia ler e quando pega um livro vai direto aos exemplos. Você só quer ver código e acha que tudo mais além disso é desnecessário.

Os anos passam e agora você é um bacharel em Ciência da Computação que mesmo depois da faculdade continuou atuando de modo a aprimorar suas competências técnicas. As pessoas respeitam você como técnico e é notável como você se destaca no time. E justamente por estar acima da média, justamente por estar se destacando dos demais, a empresa decide que você merece reconhecimento. Então você se torna gerente.

Saem os Design Patterns, a OOP, o Refactoring e entra a liderança, a comunicação e a criatividade. Oras, isto tudo não teria mais a ver com humanas? Isto é justamente aquilo que você deixou de lado pois sabia que não tinha aptidão. Mas você não pode dizer não para esta proposta e deixar de ganhar mais do que você ganha como técnico, não é mesmo? Quem sabe você, além de ser um bom técnico, é um líder criativo que se comunica muito bem com as pessoas, não é mesmo?!

Bem, no início os seus subordinados respeitam você. Afinal de contas você conquistou este respeito enquanto você era um deles. Sempre que é preciso falar de coisas técnicas você ainda agrega muito à equipe. O problema é que você continua agregando valor muito mais como um técnico do que como um gerente. E quando surgem os primeiros problemas nos quais você deveria exercer sua capacidade de liderança você falha. Ao falhar repetidas vezes a equipe vai tendo a impressão de que você não faz nada como gerente.

Os anos passam e você não investe em aprender a ser um bom gerente porque os livros que falam disso são chatos: eles não tem código. Além do mais você odeia ler. Mas você acredita que chegou aonde está por méritos próprios e é muito orgulhoso para reconhecer que precisa recomeçar do zero. Também não lhe sobra tempo para se atualizar no mesmo ritmo que a sua equipe técnica evolui e aquele respeito que eles tinham por você desaparece. Neste momento você já não agrega valor nem como técnico nem como gerente. Então as pessoas começam a comentar pelos corredores que você de fato é um bosta que não sabe o que fala e que não faz nada.

Moral da história: ao te nomear como gerente a empresa não sabia que estava tomando uma decisão duplamente equivocada. A empresa não sabia que estava perdendo um excelente técnico e ganhando um péssimo gerente. Você é bom de exatas, mas agora ocupa um cargo onde saber resolver uma equação diferencial não faz a menor diferença.

Quando eu comecei a trabalhar com informática no programa de estagiários da ADP eu era um dos mais velhos e, conseqüentemente, um dos poucos que já fazia faculdade. O que me chamava a atenção naquela época era que muitos daqueles estagiários pensava em estudar administração ao invés de alguma coisa mais diretamente relacionada ao desenvolvimento de Software. Mais tarde eu fui perceber que não só os estagiários, mas também os programadores mais experientes consideravam desnecessário uma faculdade de Ciência da Computação ou coisa similar. Por muito tempo eu achei que eles estavam errados. Uma faculdade teria sim muito a agregar, principalmente no que diz respeito a conceitos tais como Estrutura de Dados, Algoritmos, Programação Orientada a Objetos e Engenharia de Software. No entanto, depois de 10 anos trabalhando nesta área eu já não tenho tanta certeza disto.

Não que a pessoa não tenha a oportunidade de aprender muito numa faculdade de desenvolvimento de Software, mas o problema é a dinâmica do mercado e o tipo de Software que a maioria das pessoas que saem da faculdade desenvolve. Afinal de contas, como é que um projeto de três meses lhe permitirá tirar proveito de boas práticas de desenvolvimento de software? Como é que se justifica um investimento maior em Engenharia de Software se a vida útil dos projetos vem diminuindo a cada ano? E pior, para que ter tanto conhecimento se você é obrigado a nivelar por baixo aquilo que você produz devido às pressões externas que vem do mercado?

Na faculdade eles não falam sobre o mercado (ou pelo menos falam muito pouco). Na faculdade eles não falam sobre o prazo. Ninguém também lhe ensina ter o bom senso de considerar que um trecho de código ruim não é o fim do mundo se aquele trecho tem a ver com uma funcionalidade pouco usada e cuja manutenção futura será inconstante. Mas eles falam sobre muitas outras coisas inúteis para o seu dia-a-dia. Você que trabalha com informática já ouviu falar de Modelo Ambiental ou Modelo Comportamental? Você programador que não fez faculdade já ouviu falar de Árvore Binária? Já ouviu falar de estrutura de dados com alocação dinâmica usando ponteiros? Você que trabalha com banco de dados já ouviu falar de Álgebra Relacional? Conhece normalização a fundo? Enfim, você está perdendo alguma coisa com isso? A resposta é: provavelmente não. E isso faz parte de um problema clássico do ensino no Brasil: a enorme distância do meio acadêmico para o meio coorporativo.

Outros fatores também pesam a favor da banalização do desenvolvimento de software no Brasil. O primeiro deles, eu diria, é a invenção das endeusadas certificações. Estas basicamente provam que a pessoa tem boa memória e paciência o suficiente para estudar para uma prova extremamente chata. Às vezes eu penso que se o Tarcisio Meira quisesse tirar certificação Java ele conseguiria e com uma nota bem alta. Mas ser ator de novela certamente dá mais dinheiro do que ser programador.

Outro fator a ser levado em conta é popularização da Internet. Em primeiro lugar porque a Internet deixou o mercado ainda mais dinâmico. Ainda lembro do tempo em que as pessoas faziam um cursinho de ASP e se auto-entitulavam Web-Masters (ainda não estamos livres destes pseudo experts, mas hoje muitos deles gostam de se chamar Evangelistas). Em segundo lugar porque a maioria dos softwares que desenvolvemos em tempos de Internet não são softwares de missão crítica, ou seja, um bug não trará tanto prejuízo assim.

Quem começou a trabalhar com informática antes da Internet deve surpreender com o fato de que as empresas só há pouco tempo começaram a falar de UML, Processo de Desenvolvimento, etc. Na época do Client x Server isto já era natural. Com relação aos Processos de Desenvolvimento ainda temos outro problema. Conheço muitas empresas que usam os processos e as metodologias apenas por “status” – passa a falsa impressão de qualidade. Por outro lado, são poucas as empresas que usam estes processos como um meio para se gerar software de qualidade e não como um fim. Talvez por isso poucas pessoas são capazes de enxergar que tal como uma imagem vale mais do que mil palavras, um diagrama UML vale mais do que mil linhas de código. Mas, repito, levando em consideração a dinâmica do mercado e o tipo de software que desenvolvemos isso é mesmo necessário? Provavelmente não. Como resultado temos um mercado saturado de novos operários. Os operários do futuro. Programadores programados para fazer um trabalho que exige maior esforço físico e menor esforço intelectual: ficar sentado até de madrugada corrigindo bugs e fazendo pogs. E para ser operário, você de fato não precisa de faculdade. A não ser, é claro, para colocar no currículo.

Programar para computadores é fácil, difícil é programar para pessoas. São as pessoas que devem entender o que o seu programa faz. O computador sempre faz o que você pede sem questionar. Quem geralmente questiona porque você fez de tal forma são os outros programadores e, muitas vezes, você mesmo. Assim, programar bem é quase o mesmo que escrever bem. Não é a toa que o que usamos para programar se chama linguagem – Linguagem de Programação. Uma parte do trabalho do programador é traduzir o algoritmo que resolve o problema para uma linguagem que o computador entenda. A outra parte e, provavelmente a mais importante, é saber se expressar de forma clara a fim de lidar mais facilmente com a complexidade.

Quase todo software é um grande problema a ser resolvido. E para resolver um problema precisamos ter conhecimento do seu universo de informações. Porém, um novo problema surge por uma limitação do nosso cérebro: a quantidade de informação que somos capazes manter na memória enquanto pensamos numa solução é limitada. Por isto, geralmente decompomos o problema em partes menores. Estas partes menores, depois de resolvidas, nos permitirão ignorar grandes quantidades de informação que de outra forma manteríamos como ruído na nossa memória enquanto tentamos solucionar o problema maior. Em outras palavras, as partes menores do problema encapsulam detalhes que não são pertinentes saber enquanto pensamos no problema maior. E porque estamos livres de pensar em todos estes detalhes ao mesmo tempo o grande problema se torna mais fácil de ser resolvido. Esta é a melhor arma do programador para lidar com a complexidade e se chama Abstração.

A abstração pode existir em níveis infinitos, mas eu considero que para lidar bem com a complexidade precisamos entender três níveis de abstração:
1. Abstração de linguagem de alto nível
2. Abstração do SDK da linguagem
3. Abstração dos objetos do domínio

O primeiro e o segundo nível de abstração geralmente são fornecidos para o programador. Uma linguagem de alto nível já é uma abstração de muitos detalhes de outras linguagens de mais baixo nível. O Java, que é uma linguagem de alto nível, abstrai detalhes de mais baixo nível como o tratamento de ponteiros do C, por exemplo. Isto porque se considerou no projeto da linguagem Java que este tipo de detalhe (trabalho com ponteiros) seria um ruído desnecessário que o programador teria que manter em sua mente enquanto pensava sobre o problema a ser resolvido.

Porém, mesmo as linguagens de alto nível possuem detalhes que podem ser considerados de mais baixo nível e por isto existem os SDKs. O SDK do Java oferece mais um nível de abstração que evita que o programador tenha que saber no detalhe o que é preciso fazer até mesmo para tarefas simples como imprimir uma mensagem no console – isto está encapsulado na classe “System”. Assim, os SDKs elevam ainda mais o nível das linguagens de alto nível fornecendo determinados serviços que deixam o programador mais livre para pensar naquilo que lhe é pertinente.

Por fim, existe a abstração que é responsabilidade do programador. Esta é a abstração dos objetos do domínio; os objetos que o programador cria para o seu negócio. O problema a ser resolvido pelo programador é adicionar itens num carrinho de compras e não adicionar “floats” para preços, “strings” para nomes e “ints” para quantidades numa “Collection”. Se o programador tiver que pensar em “floats”, “ints”, “strings”, “Collections”, etc. enquanto tenta resolver o seu problema ele estará ocupando espaço em sua mente com detalhes demais ao mesmo tempo e não estará lidando bem com a complexidade. Assim, o programador pode criar um Objeto que deixa as coisas num nível ainda mais abstrato. No caso do carrinho de compras o programador poderia criar algo do tipo ShoppingCart.add(item). Desta forma é possível ler um programa quase que em linguagem natural, o que permitirá ao programador pensar sobre o seu problema nos termos do seu negócio e não nos inúmeros detalhes técnicos. Isto reduz imensamente o overhead cerebral que nós mesmos criamos ao não usar bem a abstração e é como se nós tivéssemos criado o nosso próprio SDK com os objetos do domínio do problema que queremos resolver.

Este terceiro nível de abstração também é importante porque ao ler o seu programa outro programador precisa ter inicialmente um entendimento global da solução. Neste momento é suficiente saber que ShoppingCart.add(item) faz o seu trabalho e não como isto é feito. Mais uma vez (não me canso de repetir) isto evita que o outro programador tenha que manter em sua mente o modo como o carrinho de compras funciona enquanto tenta entender o Shopping virtual como um todo. Se ele quiser saber como o carrinho de compras especificamente funciona ele desce um nível na abstração e assim sucessivamente até chegar ao nível mais baixo que desejar.

Mas pior do que não criar os seus objetos do domínio é o programador usar instruções cada vez mais baixo nível para implementar funcionalidades de negócio. Lembro que certa vez eu mostrei para uns amigos a instrução “de baixo nível” ChangeWacher.watch() do SDK do Flex e isto se espalhou por todo o software que estávamos desenvolvendo. Não estou dizendo que não devemos usar instruções de baixo nível, mas a questão é onde usá-las. Se você está implementando um Caso de Uso ou uma User Story,quando você ou outro programador for ler o programa ele tem que se deparar, inicialmente, com algo no terceiro nível de abstração. O que o programador deve ler inicialmente ao ver o seu código são chamadas aos métodos e propriedades dos objetos do domínio do seu problema. Misturar estas chamadas com instruções de baixo nível como “ChangeWatcher.watch” não é uma boa prática. Afinal de contas, para quê eu preciso saber que alguém usou um “ChangeWatcher.watch()” quando tudo que eu quero saber é como o meu Shopping virtual funciona como um todo? Sempre que vemos uma instrução de mais baixo nível enquanto tentamos entender a implementação de uma funcionalidade de negócio somos obrigados a parar e tentar adivinhar porque ela foi usada daquela forma e naquele momento.

Conclusão: se tivermos que pensar em detalhes técnicos (ints, floats, Collections, etc.) enquanto resolvermos o nosso problema não estaremos usando o terceiro nível de abstração, o único de responsabilidade do programador. Ao trabalhar com o SDK e com linguagens de alto nível o programador pode resolver facilmente os problemas menores – os detalhes técnicos de implementação. Ao trabalhar com os objetos do domínio o programador pode resolver facilmente problemas maiores – os problemas do seu negócio. Assim ele consegue o nível de abstração necessário que lhe permite lidar melhor com a complexidade. Assim ele escreve programa para pessoas, não para computadores.