Seu código é um vaso de plástico

  

Seu código é um vaso de plástico

https://www.linkedin.com/pulse/seu-código-fonte-é-como-um-vaso-feito-de-plástico-leonardo-k-shikida 

Programação Defensiva, Orientação por Objeto, Linguagens para as Massas. O título original desse post ia ser este.

Uma das minhas grandes birras com o Facebook é que ele é propositalmente ruim de fazer busca em conteúdo antigo. Então todo o conhecimento ali é perene. Porque não interessa ao facebook referenciar coisas antigas e estragar o cache deles. Facebook vive do fluxo, igual ao Tweeter.

Falando disso porque o Kiko começou uma discussão bacana sobre Java e suas burocracias e gente boa fez comentários pertinentes, mas eles irão se perder para sempre no conteúdo não-indexável do Zuck.

O artigo está aqui e os comentários estão aqui.

Ele já escreveu algo sobre código legado que também vale a leitura.

Eu queria falar um pouco aqui sobre a computação como linguagem, mas não como linguagem de programação, mas como linguagem de intenções e interpretações. O código fala, então parto do artigo do Kiko sobre código legado (a melhor definição que eu conheço de código legado é o código que está em produção. Entrou em produção, tornou-se legado, igual ao carro zero que virou carro usado ao pisar na estrada).

Ao contrário de muita gente de hoje em dia, eu aprendi Orientação por Objeto primeiro e uma linguagem orientada por objeto depois. Eu sou das antigas, aprendi C e Pascal e depois foi aquele parto para aprender Java. Acho que a experiência mais assustadora de Java é seu Hello World verboso e a primeira coisa que me veio à cabeça foi "por que? por que tanta coisa para dizer tão pouco?".

Diga-me então você, desenvolvedor. Por que?

Foi um semestre de orientação por objeto ministrado pelo legendário professor Bigonha (uma das estrelas do departamento da ciência da computação da UFMG, uma combinação de conhecimento e didática incomuns) apoiado num livro clássico do Bertrand Meyer, uma das cabeças por trás de Eiffel, e por conseguinte, de Java. Nenhum livro me influenciou mais na vida computeira que este livro. Se eu pudesse escolher um livro somente, seria este.

A computação se tornou social quando o primeiro programa de computador foi escrito a quatro mãos. A gente aprende rápido sobre a importância da segunda opinião na primeira sessão de debug em que você pede ajuda ao seu colega para achar o bug que seu olhar viciado não vê, e aprende a odiar o próximo quando recebe o código de outra pessoa para dar manutenção (o famoso "código bom é código meu").

Dizem que código deveria ser escrito como se um psicopata que sabe onde você mora fosse dar manutenção nele. E também dizem que a documentação do código é o código em si. Provavelmente a verdade está perto destas duas coisas.

Para permitir código feito por muitas pessoas ao mesmo tempo, criamos o aspecto social do código que é a sua organização, para podermos lidar com sua complexidade. Não criamos apenas padrões de codificação (que carregam consigo parte da cultura daquela linguagem), mas também criamos um processo de evolução da própria linguagem, que torna a linguagem de programação não apenas uma ferramenta, mas uma instituição, que decide sobre sua evolução, sobre a entrada de novos recursos (features), sobre a manutenção do código legado ou sobre a difícil escolha de abrir mão dessa compatibilidade em nome de mudanças estruturais no código (veja Perl).

Tudo numa linguagem de programação tem uma intenção. Tudo o que foi feito teve uma razão de ser. Tanto no seu programa quanto na sua linguagem.

Fora o livro do Meyer, uma das coisas que mais ajuda é tirar certificações. Certificações em si tem pouca importância prática, mas se forçar a estudar para tirá-las é inestimável. Não porque ela te força a aprender como a linguagem é, mas porque ela te leva a refletir porque ela é como é.

Uma vez, um colega de trabalho, muito mais inteligente do que eu, resolveu codificar na mão uma classe que já existia nas Collections do Java. Não porque ele era burro, nem porque era cabeça dura. Ele simplesmente fez isso porque ele achou que codificar aquele "util" era fácil o suficiente e iria resolver o problema dele. Mas eu chamei outro colega de trabalho (também mais inteligente do que eu) para me ajudar a convencê-lo de que aquilo não era uma boa idéia. 

Não porque ele ganhava em reutilizar código (reutilizar código exige aprender algo novo e isso nem sempre é mais rápido que codificar a sua solução), mas porque usar Collections naquele caso era programar para o outro, programar dentro da cultura da linguagem Java. Programar usando algo que o outro já sabe, que ele está familiarizado.

O processo de familiarizar com outra cultura é difícil e mexe com nosso orgulho. Eu gosto de me iludir achando que sou melhor eticamente, moralmente e tecnicamente que as outras pessoas, mas uma análise criteriosa certamente me dirá o contrário. É o que eu chamo da regra do 60/90. Por causa de uma pesquisa relatada neste livro (uma literatura pseudo-científica divertida para se ler no aeroporto e não ser levada tão a sério) que dizia que 90% dos pais se consideravam bons ou ótimos enquanto 60% dos pais consideravam os outros pais medíocres. :-)

Um dia eu fui parar numa fábrica de software CMMI-5 (uma das épocas mais felizes da minha vida, de verdade). Lá tinha um padrão de codificação que estabelecia regras que iam desde a obrigatoriedade do uso de chaves em IFs até a nomenclatura de métodos. Um dos arquitetos de lá me falava sobre a importância da conformidade de todos com o padrão. "Para quando outro desenvolvedor pegar seu código, ele achar que é o dele e não precisar pensar".

Para uma fábrica de software, ou para qualquer comunidade de computeiros que trabalhe junto, não precisar pensar na hora de pegar o código alheio é um benefício muito grande perto do problema de descobrir tudo de novo diante do código dos outros. É como viver em sociedade. Escolhemos abrir mão de pequenas liberdades individuais em prol de algo maior e comum (a medida em que isso ocorre geralmente consiste na diferença entre uma posição política e outra). 

Não bastasse haver um padrão, haviam reuniões periódicas de peer-review onde seus erros eram apontados pelo dedão do grande irmão da empresa. Minha primeira reunião desse tipo me trouxe obviamente revolta. Como ousavam questionar meu código diante daqueles padrões estúpidos. Ok, não era com essas palavras, mas era como eu me sentia, e tempos depois, quando EU era o revisor, eu me lembrava de tudo o que eu tinha sentido quando era o novato que se sentia invadido.

Isso porque, até o momento em que você programa com outras pessoas na sua equipe, seu código é seu castelo. Você fez com o seu suor, seu conhecimento, do jeito que você gosta. Dizem que a pornografia é o conto de fadas masculino, porque ali, tudo acontece do jeito que você queria. Pois bem, o código de uma pessoa só é sua própria pornografia computeira, digamos assim :-).

Eu faço questão de deixar claro os sentimentos porque não estamos falando do código e dos design patterns. Estou falando deste animal vivente que é o computeiro, provavelmente você, que está lendo.

Noutra ocasião, também discuti com outro colega de trabalho (que admiro até hoje) sobre o fail early. Não lembro exatamente sobre o que eu estava fazendo de errado, acho que eu estava tentando tratar as exceções enquanto isso impedia o sistema de expor suas falhas. Ele ganhou a discussão e eu aprendi algo novo.

As tais metodologias ágeis são baseadas nesta concepção da computação como um fenômeno social, de equipe. No fundo, o que ela prega é que a equipe resolva seus conflitos, internamente e com o cliente. Ela cria pequenos artefatos e rituais que, emboram pareçam o pão fatiado para computeiros, provavelmente já foram estudados à exaustão por alguém da sociologia, depois de visitarem muitas tribos indígenas. Computeiros deviam ler sobre sociologia. Já tivemos um presidente sociólogo mas nunca um presidente computeiro.

Agora entra a programação defensiva. Programar de forma defensiva é programar para os outros. Para o outro. É largar a sua pornografia para adotar a pornografia do processo :-). É ser social. É deixar claro para o outro o que você queria com aquele código.

Uma vez, eu peguei um sistema para desenvolver que era uma bomba. Não havia forma fácil de fazê-lo, mas a fábrica só podia contar com pouca gente boa e muita gente júnior então o código não podia ser difícil a ponto de impedir sua manutenção. Quando eu me sentia frustrado, eu escrevia código difícil, como forma de liberar a frustração. Agressividade passiva, dizem. 

Um belo dia, um colega de trabalho bom de serviço veio me perguntar o que significava 1 linha do código, que usava uma operação de XOR. Pense na última vez que você usou um XOR para montar uma interface gráfica. Aliás, pense o que faz um XOR ou como se escreve isso em Java. Lá estava eu, sendo um exibido egoísta babaca numa sociedade computeira que devia ser harmoniosa e altruísta. Lá estava eu, compondo BeBop e pensando "só um músico de jazz foda é capaz de tocar essa passagem". Era isto que se passava na minha cabeça.

A documentação é o código porque não há tempo hábil para manter código documentado. Não há. Java nem sequer checa se seu javadoc condiz com a assinatura do método, até onde eu saiba. Mas se seu método é público, isso diz muita coisa. E o livro do Meyer vai te explicar isso do ponto de vista teórico.

Um dia eu peguei um código aberto escrito por um biólogo americano, que em termos de computação, era um excelente biólogo. Variáveis globais por todos os lados. Pecado mortal para refatoração. Martin Fowler não é um gênio por causa do conceito de refactoring de código. Ele é um gênio porque apenas codigo BEM MODULARIZADO pode ser refatorado. É importante perceber a diferença. E eu precisava pegar aquela aplicação em swing e portar para a web. Como fazer isso num código de alguém que sequer sabia o que era MVC? Ele não estava programando para os outros.

Programação defensiva não é proteger o código de erros somente. É proteger também o código dos erros dos outros porque ele não foi feito para ser compreensível.

Outra coisa poderosa de Java e da orientação por objeto. A faca de dois legumes do aspecto dinâmico da linguagem. Você primeiro instancia e depois usa. É uma forma de compartimentar o erro. Um bug pode existir no seu código por uma eternidade, até que ocorra a condição que cause o bug. Alguns bugs vivem anos e anos no seu código. 

A cada nova versão, bugs antigos somem e outros surgem. O bug vem da nossa atividade humana de programar. Sempre estaremos lutando contra eles e eles sempre estarão surgindo. Poder compartimentar código e seus erros é o que permite um sistema ser desenvolvido por muita gente. É o que nos aproxima daquela engenharia que constrói represas, foguetes, aviões. A programação é social porque os projetos ficaram grandes demais. E as ferramentas se tornaram um problema por si só, porque as ferramentas também são software. E assim lidamos com a complexidade.

Java é verboso. É verboso porque é feito para computeiros serem sociais. Para poder fazer sistemas grandes, Para poder lidar com rotatividade de mão de obra. Para que eu possa tirar férias e o projeto não parar. Código fonte é apenas uma forma de expressar conhecimento sobre algo. Uma linguagem verbosa exige que vc se expresse, talvez mais do que vc gostaria. Nem todo mundo escreve bem ou resolve bem um problema, mas entender o que você faz é importante. Entender sua intenção. Lidar com a complexidade. Quebrar o problema e compartimentar seus erros.

Eu digo que Java é o Karatê das linguagens de programação. Sou faixa branca de tudo. Algumas artes marciais são práticas, como o Krav Magá, ensinam você a lidar com situações. Outras, trazem consigo uma história e uma filosofia por trás, como o Kung Fu. Outras, são modernas, como o Aikidô. Outras, foram feitas para as massas como o Karatê.

Karatê é uma boa luta para ensinar para tropas. As pessoas aprendem "kata"s, que são aqueles movimentos de golpes que vc repete à exaustão. Soldados costumam ser pessoas comuns, muitas vezes humildes, você não pode exigir muito conhecimento prévio. Você precisa dar para elas instruções curtas e simples, e principalmente, efetivas. Dificilmente você vai ver um mestre de karatê no UFC, mas as guerras não são vencidas com super soldados. São vencidas por pessoas comuns.

Da mesma forma, a TI não é feita de gente excepcional do Google, mas por pessoas comuns. Java é uma linguagem para pessoas comuns. A máquina virtual abstrai o que é específico da plataforma não somente pela portabilidade (útil porém rara, alguém já viu a necessidade de um sistema projetado para linux ter que ser portada para windows? é muito mais fácil e barato rodar noutra máquina, oras). A linguagem verbosa te força a ser claro na sua intenção (compare com códigos ofuscados intencionalmente em C ou Perl). É uma linguagem ubíqua (adoro esse termo - significa onipresente, mas foi traduzida como pervasiva) e portanto serve desde o server-side até sistemas android e raspberry pis da vida.

Java é uma das linguagens da commoditização da nossa profissão. A Microsoft não fez C# à toa. Eles sabem da importância de se ter uma grande comunidade de desenvolvedores à disposição no mercado. Estar no mercado é ruim porque os salários tendem a achatar, e é bom porque da mesma forma, dificilmente você ficará sem emprego. A mediocridade (que significa estar no meio e não estar embaixo) pode ser visto tanto do ponto de vista de ser dispensável quanto de ser empregável. 

Muitas vezes, do ponto de vista da empresa, é muito mais vantajoso você ter gente que sabe java em suas fileiras porque você quer ter elasticidade para contratar e demitir rápido do que começar um projeto numa linguagem obscura como Ruby por exemplo, por mais features incríveis que a linguagem te traga.

Acho que já falei demais, deixa eu tentar concluir isso aqui.

Em computação, tudo tem uma intenção. Existe o interesse de quem bolou a linguagem, da empresa que banca sua insituição (no caso de Java, a Oracle, e antes, a Sun). Existe a intenção do contratante. Existe a sua intenção como desenvolvedor. Existe a intenção dos outros da sua equipe. 

E existe a do cliente, que raramente quer ver seu código, que é como um vaso de plástico.

Ninguém se pergunta como aquele vaso de plástico foi feito desde que você possa plantar algo nele e ele dure pelo menos alguns anos.