Certamente você já trabalhou ou trabalhará com código legado durante sua carreira, pois nem sempre estaremos em projetos novos com tecnologias novas, certo? Errado.

Um código legado não é somente o código antigo que é mantido porque funciona, segundo Michael Feathers, autor do livro Work Effectively with Legacy Code, a idade do código não é o mais importante nesse caso. O principal sintoma de um código legado é a ausência de testes. Essa é uma perspectiva interessante, pois podemos estar hoje mesmo escrevendo código legado no nosso super novo projeto.

Essa diferença é fundamental, pois os testes nos dão a confiança de modificar, corrigir e melhorar um sistema existente, uma vez que eles garantem que não incluímos bugs ou fazemos modificações erradas/inesperadas no sistema. Logo, trabalhar efetivamente com código legado é garantir que nossas modificações não mudem o comportamento do sistema que já funciona há muito tempo. Mas como conseguimos garantir que fazer uma modificação de cada vez mantendo o comportamento do sistema? A forma de garantir que após uma modificação o sistema continua a se comportar da forma esperada é escrever testes para o comportamento. Ou seja, os testes garantem o comportamento atual do sistema, ou da parte do sistema que queremos realizar modificações.

A estratégia apresentada por Michael Feathers no artigo, se resume da seguinte forma:

• Identificar os pontos de alteração
• Encontrar o ponto de inflexão
• Cobrir o ponto de inflexão
• Realizar alterações
• Refatorar

Identificando os pontos de alteração​

Em um código legado, dependendo da qualidade do mesmo, uma alteração pode requerer mudanças em várias áreas do sistema. No primeiro passo, devemos identificar todas as modificações necessárias, pois elas nos ajudarão a encontrar o ponto de inflexão.

Encontrando o ponto de inflexão​

O ponto de inflexão é a interface para um conjunto de classes. Ou seja, o ponto onde o código a ser alterado interage com o resto do sistema. Qualquer modificação executada no conjunto de classes terá impacto no ponto de inflexão ou consequentemente no sistema.

Imagine que em um sistema que está organizado em camadas, no qual uma classe de serviço usa um repositório, se tivermos que realizar uma alteração em uma entidade e no repositório, o ponto de inflexão seria o service, pois qualquer alteração nelas teria impacto diretamente no service ou no resto do sistema.

Dependendo da complexidade do sistema, é provável que exista mais de um ponto de inflexão. A correta identificação desses pontos é muito importante, pois é preciso garantir que as alterações identificadas não “vazem” para o resto do sistema sem passar pelo ponto de inflexão.

Cobrindo o ponto de inflexão​

Após identificar o(s) ponto(s) de inflexão, é necessário cobri-lo(s) com testes. Geralmente grande parte do esforço é concentrada aqui. Em sistemas legados e com design ruim, o código tende a ser muito acoplado, e colocá-lo sob teste geralmente envolve resolver problemas de dependências que podem ser internas ou externas.

A coisa mais simples que você pode fazer é tentar instanciar uma classe (ponto de inflexão). Em um bom design, as dependências dessa classe são passadas pelo construtor, se forem dependências obrigatórias, ou via setters se forem opcionais. Essas são as dependências externas. Essas dependências podem ser tratadas com mocks ou até mesmo NullObjects. O importante é conseguir testar o ponto de inflexão, logo fazer mocks das dependências não é preocupante, pois não são o foco dos testes.

As dependências internas são mais difíceis de lidar. Aqui entram objetos criados internamente, variáveis estáticas ou globais, ou até mesmo singletons que são invocados dentro dos métodos, o que dificulta muito os testes (motivo pelo qual singleton pode ser considerado um antipattern). Para lidar com dependências internas, muitas vezes é necessário estender a classe que queremos testar e sobrescrever comportamentos e dependências internas.

Após resolver as dependências é hora de escrever testes que cubram o ponto de inflexão. Como mencionado anteriormente, o código atrás dessa interface não pode afetar o sistema sem passar por esse ponto. Dessa forma, começamos a escrever testes que cobrem essa área do código.

Lembre-se que o comportamento correto do sistema é o que ele já faz.

Realizando alterações​

O ideal é fazer alterações incrementais e executar constantemente os testes. Tente escrever testes antes de fazer suas alterações e procure cobrir alguns corner cases.

Refatorando​

Com o código coberto por testes, temos agora a oportunidade de melhorar o design. Se o código for mal estruturado, geralmente existem classes grandes com métodos grandes e alguns padrões de refactoring podem ser usados como extract method e extract class. Uma boa referência desses padrões é o livro Refactoring de Marting Fowler.

À medida que refatoramos, devemos adicionar mais testes. Lembre-se também que código de teste é tão importante quanto o código de produção. Testes devem ser fáceis de manter, pois caso não sejam, provavelmente serão negligenciados.

Com o passar do tempo, as partes principais do código legado começam a ser cobertas por testes e acabamos com pequenas ilhas de testes que serão muito úteis nas próximas intervenções. Além disso, testes também são uma forma de documentação e podem ser a única fonte no futuro.

A estratégia apresentada aqui foi baseada apenas no artigo Working Effectively With Legacy Code e certamente há muito mais para ser visto sobre isso. Se quiser se aprofundar no assunto, recomendo o episódio do infoq podcast com Michael Feathers ou o livro onde esses temas são detalhados.

Referências​

• Working effectively with legacy code
• InfoQ Podcast

Recentemente, aproveitando a promoção do 25ª aniversário do Java, atualizei a minha certificação Java 8 para a versão 11 e algumas coisas foram diferentes dessa vez. Não só os novos tópicos incluídos na prova, mas também a forma pela qual optei em fazer o teste.

Novos tópicos​

Foram removidos da lista de conteúdos, Java SE Date/Time API e o design de classes e padrões de projetos como singleton e classes imutáveis. O primeiro tópico aparece de forma discreta dentro de outros tópicos como Localization. O segundo não aparece. No entanto, para compensar, novos tópicos foram adicionados.

O Java 9 trouxe o mundo modular para a plataforma e essa big feature não estaria de fora de uma certificação Java 11. O exame não cobre todos os aspectos da programação modular e foca apenas em princípios, como definir minimamente um módulo e os comandos necessários para compilar e executar códigos modulares. Essa é uma feature que certamente ditará o rumo do java e você deve focar um tempo nesse assunto de qualquer forma. Um bom material é o capítulo do livro Core Java Volume II que cobre os principais pontos do sistema de módulos.

Outra novidade do exame é a inclusão da inferência de tipo em variáveis locais e o uso apropriado do var. Nesse ponto, o teste espera que você seja capaz de identificar usos incorretos do var.

Nas certificações anteriores, era cobrado basicamente o uso de somente uma annotation, @Override. Agora, esse tópico foi alargado e nele estão incluídos temas como a correta criação, aplicação e processamento de anotações, além do uso de outras annotations como @SafeVarags e @SuppressWarnings.

Além dos tópicos mencionados anteriormente, foi adicionado também uma sessão de codificação segura ou Secure Coding in Java SE Applications. Esse é um tema amplo e importante que merece uma dedicação exclusiva. Você deve esperar pelo menos duas ou três questões sobre segurança. Aqui a certificação foca mais em boas práticas e menos no uso da API. Todo o material necessário para esse tópico pode ser encontrado no Guideline Java. Independentemente, se você pretende se certificar, essa é uma leitura obrigatória e é um tema que ainda aparecerá por aqui. 😀

A prova​

Dessa vez, devido ao contexto atual, não fiz a prova em um test center e optei por tentar de casa. Certamente foi a melhor opção, primeiro porque não precisei me deslocar e segundo porque me senti muito mais confortável. O teste é feito pela PearsonVue também e é necessário baixar o software do exame. Antes do teste, você precisa validar seu computador, webcam, microfone e conexão com internet, que são os itens principais. Sistemas operacionais Linux não são suportados.

Antes do teste é obrigatório tirar fotos do ambiente e da mesa onde você fará a prova. Sua mesa deve conter somente o computador e não é permitido dois monitores, celulares ou relógios. Minutos antes do início do teste, um “fiscal” entrou em contato por uma chamada através do próprio sistema de certificação e me pediu para ver o ambiente em que eu estava para que pudesse ser novamente validado. Tive que fazer um mini tour pela sala e me comunicar em inglês com o fiscal. Não sei se em outros timezones haverá alguém que fale outras línguas. Mas você deve estar preparado para ao menos entender e atender aos pedidos realizados.

O ponto negativo de não estar em um centro de teste é que nos tornamos responsáveis por coisas importantes que seriam garantidas pelo test center, como um ambiente tranquilo e sem interrupção. Caso opte por esse tipo de teste, escolha um bom lugar e garanta que não será interrompido, pois caso alguém apareça no ambiente enquanto você está realizando a prova, ou vozes sejam ouvidas, é possível que seu teste seja anulado. A webcam fica ligada durante todo o tempo e o teste é gravado.

Eu não tive muito tempo para me preparar para essa certificação, então acabei por focar nos novos tópicos e revisar os anteriores com simulados. Eu treinei para o exame usando o banco de questões da Enthuware, ferramenta que usei também para os testes anteriores. Fiz ao todo 12 simulados com cerca de 50 questões, dos quais falhei somente em um. Esses simulados são mais difíceis do que o teste real, o que ajuda muito na preparação. Como resultado, consegui me certificar com 80% o que não é mau, embora tenha sido abaixo da minha nota anterior.

Na minha opinião, o ritmo de adoção das versões é mais lento que o ritmo de lançamento, não necessariamente precisamos ficar ansiosos com novas features, uma vez que as empresas adotarão as versões em ritmos diferentes. Um ponto importante a ser notado é o fato de que as versões non-LTS só possuem suporte por seis meses. Sendo assim, talvez seja melhor adotar as versões LTS que são lançadas a cada 3 anos. O Java 11 é a atual versão LTS e será “substituída” pelo Java 17, no entanto é previsto um tempo de suporte de cerca de 8 anos para versões LTS. Ou seja, ainda temos muito tempo para nos adaptarmos ao mundo modular.

Deixo abaixo um webinar onde apresento um resumo das alterações que foram introduzidas na linguagem entre as versões 9 a 15.

À medida que o tempo passa e seu conhecimento cresce, você será naturalmente mais interrompido por dúvidas, reuniões, mensagens, etc. Interrupções contínuas diminuem a produtividade e certamente será um problema que você terá que lidar cedo ou tarde. Neste artigo, apresento 3 "coisas" que me ajudaram a lidar com essa situação.

Quando alcançamos um certo nível de senioridade, alguns minutos nossos podem salvar horas da equipe. Pense nisso, um membro da equipe pode demorar horas para resolver um problema ou entender parte do projeto ao passo que você pode explicar e/ou dar um direcionamento em questão de minutos, ou seja, te interromper pode literalmente economizar dinheiro.

No entanto, em algum momento você vai perceber que parte significante do seu trabalho é ajudar os outros e que possivelmente você terá menos tempo para resolver suas próprias tarefas. Quando esse dia chegar você precisará ser mais eficiente.

Algo similar aconteceu comigo e depois de ler um artigo enviado por um amigo, consegui pôr em prática algumas coisas que me ajudaram a ser mais produtivo e evitar algumas interrupções. Vamos a isto!

Documentação​

Talvez demore um tempo até percebermos a importância de documentar (apesar que gerir documentação efetivamente é um pesadelo à parte). Não é incomum interrompermos alguém com dúvidas recorrentes, por isso documentar pode nos salvar vários minutos. Então tente tornar a atividade de documentar algo natural. Dúvidas gerais podem ser documentadas a fim de servir como referência, ou um FAQ. Por exemplo:

• Qual o processo para solicitar uma nova regra de firewall?
• Qual o processo de release de uma nova versão?
• Já viu esse erro…?
• ...

Percebo que para muitas pessoas a documentação está necessariamente associada a coisas técnicas e requisitos, ao passo que coisas mais rotineiras como processos não são documentadas. Para demonstrar esse ponto vamos a um exemplo.

Recentemente estive envolvido na migração de alguns microserviços para uma nova plataforma. O microserviço no qual estava trabalhando não era o único que deveria passar pelo mesmo processo e existiam outras quantas tarefas similares. Certamente os problemas encontrados por mim seriam encontrados nas próximas tarefas.

Então, ao iniciar a tarefa, aproveitei para criar uma nova página no confluence do time onde coloquei os principais steps da migração, os erros encontrados e as soluções. Feito isso, enviei a documentação para todos do time e pedi que atualizassem conforme fosse necessário. Desta forma, além de compartilhar o conhecimento acabei por otimizar meu tempo, não tendo que responder dúvidas recorrentes.

Experimente da próxima vez que te perguntarem algo, gastar alguns minutos a mais para documentar sua resposta. Quando a mesma dúvida surgir novamente, gaste apenas alguns minutos revisando o que havia escrito e envie o link da documentação. Além de economizar tempo, isso ajuda a educar o time a documentar e procurar por soluções antes de gerar interrupções.

Timeboxing​

Timeboxing é a estratégia de alocar um período fixo de tempo para tarefas específicas. Experimente alocar um tempo diário para suas tarefas e adicione isto ao seu calendário para que os outros membros da sua organização vejam que durante este período você não estará disponível.

Tente descobrir em qual período do dia você é mais produtivo e aloque tempo para suas próprias tarefas durante esse timebox. É basicamente uma reunião com você mesmo. Bloqueie o calendário se possível. Obviamente, algumas reuniões são mais importantes do que outras e é possível que essa estratégia nem sempre funcione. Por isso é preciso também evitar reuniões desnecessárias.

Evite reuniões desnecessárias​

Quando perceber que a sua presença em uma reunião é desnecessária, peça educadamente para sair da reunião. Reuniões são caras e como profissionais devemos gastar nosso tempo da forma mais produtiva possível. De forma similar, caso esteja responsável por alguma reunião, tenha a sensibilidade de liberar as pessoas tão logo elas não sejam mais requeridas. Assim é possível otimizar o trabalho e reduzir interrupções.

Reuniões sem agenda ou pelo menos um título claro explicando do que se trata são ótimas candidatas a serem ignoradas. :)

Referências​

• Why senior engineers get nothing done

Recentemente precisei escolher uma licença open source para um novo projeto, o e-cordel. Para atingir meu objetivo, tive que pesquisar, ler, ver conferências, etc até estar minimamente seguro. Percebi que mesmo usando projetos open source durante toda a minha carreira, não tinha um bom entendimento sobre o tema. Por isso, trago hoje um pouco sobre esse tópico. Antes de mais nada, deixo claro que não sou advogado e este artigo é apenas um compilado do meu atual entendimento sobre o assunto.

Para compreender o que é um projeto open source e porque licenças são importantes, precisamos primeiro saber o que são direitos autorais.

O criador de uma obra intelectual possui direitos e prerrogativas que lhe garantem exclusivamente o direito de explorar, copiar, vender e colher qualquer benefício proveniente desse trabalho. O direito autoral é garantido por lei e serve para proteger a propriedade intelectual do indivíduo. Como você pode imaginar, essas regras também se aplicam à produção de software, pois obviamente é trabalho intelectual, como pode ser visto abaixo na lei 9610/98.

Art. 7º São obras intelectuais protegidas as criações do espírito, expressas por qualquer meio ou fixadas em qualquer suporte, tangível ou intangível, conhecido ou que se invente no futuro, tais como:

...

XII - os programas de computador;

...

§ 1º Os programas de computador são objeto de legislação específica, observadas as disposições desta Lei que lhes sejam aplicáveis.

Lei 9610/98

No Brasil, a lei 9610/98 que trata de direitos autorais, divide os direitos do autor em dois tipos, direitos morais e patrimoniais. Os direitos morais são intransferíveis e irrenunciáveis, são eles que garantem a autoria da obra. Os direitos patrimoniais por sua vez podem ser cedidos e tratam do direito exclusivo de utilizar e explorar a obra. Nesse caso, o autor deve autorizar expressamente a modalidade de uso, incluindo, cópia, reprodução parcial ou integral, etc.

Para entender estes conceitos, faremos uma análise de um caso hipotético. Imagine que você criou um algoritmo que produz receitas com rapadura de forma aleatória, chamado de rapadura++, e agora deseja compartilhá-lo com a comunidade. Então você decide imprimir o algoritmo e colar no mural da universidade sem nenhuma autorização explícita de uso. Os alunos então começam a ler o código e comentar como poderiam utilizar o mesmo em outras situações. Devido ao sucesso do seu algoritmo, um dos alunos retira o código do mural, faz uma cópia e devolve o mesmo ao local de origem. Você considera isso um problema?

Uma vez que não foi dada nenhuma autorização explícita de reprodução, a cópia não autorizada pode ser considerada uma violação dos direitos autorais, mais especificamente dos direitos patrimoniais, mesmo que o aluno que realizou a cópia não a explore comercialmente, pois segundo o artigo 29 da lei 9610/98, a utilização da obra depende de autorização prévia e expressa do autor.

Logo, se o seu intuito era realmente permitir que as pessoas explorem seu algoritmo, você deveria autorizá-las expressamente, poderia inclusive especificar em quais condições o uso do algoritmo é permitido. Ao dar explicitamente essas permissões, você estaria criando uma licença. No entanto, você não precisa criar a sua própria licença, pois já existem várias conhecidas e aprovadas e que cobrem muitos aspectos. Então, faça sua vida e a vida dos outros mais fácil, escolha uma licença existente, pois certamente há alguma que atende os seus objetivos.

Fazendo uma analogia com o mundo técnico, o mural da universidade é o Github. Quando publicamos código em um projeto público, estamos colando o código no mural da universidade sem explicitamente dizer como ele pode ser utilizado. Logicamente, ao concordarmos com os termos de uso, estamos dando autorização para o Github armazenar e disponibilizar nosso código. Por isso, se o seu objetivo é permitir que outras pessoas usem seu projeto, você precisa escolher uma licença, pois é possível que a falta de uma licença impeça um indivíduo ou organização de o utilizar por medo de possíveis problemas judiciais.

Versão curta: Você possui o conteúdo que você cria, mas nos concede determinados direitos a ele, para que possamos exibir e compartilhar o conteúdo que você publicar. Você ainda tem controle sobre seu conteúdo e responsabilidade por ele, e os direitos que você nos concede são limitados àqueles que precisamos para fornecer o serviço. Temos o direito de remover conteúdo ou fechar Contas se precisarmos.

Termos de serviço do Github

Tipos de licença​

Como está claro, compartilhar um projeto não significa somente tornar o código público, é necessário tratar da distribuição do software e da autorização de uso, ou seja da licença. Conforme mencionado anteriormente, existem várias licenças open source e não é necessário criar uma do zero. Mas o que é uma licença open source?

Licenças open source são licenças aprovadas pela Open Source Initiative e que cumprem os 10 princípios da definição open source, como a livre redistribuição e a não discriminação contra pessoas ou grupos.

As licenças open source se dividem em dois grandes grupos: copyleft e permissive. Copyleft são licenças que requerem que qualquer modificação no software ou trabalho derivado seja publicado com a mesma licença do trabalho original. A maioria das licenças copyleft são open source, no entanto nem toda licença open source é uma licença copyleft. Uma licença copyleft muito conhecida é a GNU General Public License, usada por projetos como Ansible, Bash e Gimp.

Licenças do tipo permissive são basicamente não copyleft, ou seja, elas permitem a distribuição das modificações e trabalhos derivados em outros termos. Isso significa que um projeto não copyleft pode ser inclusive redistribuído como um software proprietário. As licenças MIT e Apache License 2.0 são exemplos de permissive license e são amplamente utilizadas.

Em geral, empresas preferem projetos licenciados como não copyleft. Existem inclusive empresas que mantém projetos open source, como a Confluent, principal committer do projeto Apache Kafka. Não é raro ver empresas de tecnologia que foram criadas pelos autores do projeto open source e que se dedicam quase que exclusivamente a prestar consultoria e/ou desenvolvem versões enterprise do produto.

Como escolher​

Já sabemos que existem várias licenças e provavelmente você vai encontrar uma que se adeque às suas necessidades. Mas como escolher dentre várias opções?

Sites como choose a license e tldr legal, te ajudam a escolher uma licença ou pelo menos te dão um caminho. Nesses sites você pode encontrar um resumo da licença, indicando o que ela permite ou não.

Para escolher uma licença open source eu diria que precisamos responder minimamente à seguinte pergunta:

Você espera que todo trabalho desenvolvido a partir do original seja sempre compartilhado?

Se você se importa com as contribuições e quer evitar que outras pessoas possam distribuir versões fechadas do seu trabalho, provavelmente você deveria escolher uma licença copyleft, como a GPL.

Se você não se importa com isso, provavelmente deveria escolher uma licença permissiva, como MIT ou Apache License 2.0.

Para o projeto e-cordel que estou desenvolvendo atualmente, a resposta para a pergunta anterior foi um não. Nós do projeto e-cordel não nos importamos que o projeto possa ser copiado e redistribuído com outra licença. O objetivo do projeto, para além de contribuir com cultura do cordel é ajudar o desenvolvimento tecnológico da região no qual está inserido. Ou seja, se uma empresa ou alguém criar um produto a partir do trabalho desenvolvido, estaremos indiretamente contribuindo com o desenvolvimento da região também.

Dentre as licenças permissivas mais famosas, escolhemos a Apache License 2.0 em detrimento da MIT pois a MIT é demasiadamente simples e não trata de itens como a transmissão dos direitos dos contribuidores, ao passo que a Apache License 2.0 define uma cláusula para isso. Ou seja, ao contribuir com um projeto licenciado como Apache License 2.0, você está automaticamente cedendo seus direitos patrimoniais ao projeto.

Outro ponto a ser notado é que as empresas tendem a utilizar mais projetos com licenças permissivas, pois licenças copyleft podem ter um comportamento viral. Mas isso é tema para um outro post.

Special Thanks​

Outras pessoas participaram da construção desse artigo, portanto deixo o meu muito obrigado para…

• Dr. Marcelo, advogado tributarista e irmão, revisou o conteúdo legal deste post.
• Régis Brilhante, engenheiro de software e amigo, contribuiu na construção e revisão do artigo e é uma das forças motoras do e-cordel.

Fontes e Referências​

• Choose a license
• TL-DR legal
• opensource.org
• O que é open source
• Lei 9609/98
• Lei 9610/98

Por isso, considere que esse texto se refere exclusivamente às certificações para programadores.

Eu adquiri duas certificações java com scores altos e hoje posso dizer que não me arrependo de ter investido tempo e dinheiro nesse objetivo. No entanto, depois de ter passado por esse processo e de ter ganho mais experiência ao longo dos anos, penso que desenvolvi um olhar diferente sobre as certificações.

O grande ponto da certificação na minha opinião não é necessariamente o certificado, mas sim o processo. Durante a minha preparação para adquirir certificações java descobri o quanto eu desconhecia a linguagem com a qual trabalhava. Possuir um conhecimento mais aprofundado nessa linguagem teve um impacto muito positivo na minha carreira e isso se refletiu no meu trabalho diário e também nas avaliações e entrevistas das quais participei.

Aprender bem as tecnologias com as quais você trabalha é fundamental e esse é o ponto principal. Obviamente esse objetivo pode ser alcançado de outras maneiras e não exclusivamente através de uma certificação. Ou seja, é possível comprar o material específico da prova e/ou outros materiais e estudar por conta própria sem ter que se submeter a um teste. Ou talvez você nem precise comprar material algum, você pode somente ler a documentação da sua linguagem, livros, blogs etc. e aprofundar seus conhecimentos.

Algo a ser notado também é que uma certificação não te tornará imediatamente um bom programador. A prática e o auto criticismo sim. Programar é em geral fácil, programar bem é difícil. Por exemplo, ter uma certificação não fará você desenvolver um código limpo e fácil de manter. Na minha opinião, um bom programador é um conjunto de habilidades + conhecimento adequado da linguagem e ferramentas, ou seja, a certificação é apenas uma parte da sua jornada. A maioria dos profissionais com os quais trabalhei não eram certificados e isso de forma alguma diminui a relevância ou capacidade deles. A diferença entre os melhores está nas bases e na experiência adquirida. Não é o título que conta, é a experiência.

No entanto, como discutido no vídeo abaixo, a certificação pode fazer muito sentido para quem deseja entrar no mercado de trabalho. De certa maneira esta era a minha situação quando decidi me certificar, pois eu procurava uma realocação fora do país e vi nas certificações uma forma de adquirir e comprovar meus conhecimentos.

Como conclusão, acredito que o processo de se certificar te proporcionará mais conhecimento e se assim como eu, você precisar de um incentivo extra para estudar, elas podem ser uma ótima opção. Mas lembre-se, se certificar pode ser um processo difícil e caro que pode não te trazer um retorno imediato. Se você já possui anos de carreira, acredito que ler bons livros te trará um resultado igual ou superior com um custo menor. Além disso, a relevância da certificação está muito atrelada à fase que o profissional se encontra o que não quer dizer que a certificação não vale a pena ou seja desnecessária, significa apenas que no momento atual existem outras coisas que podem fazer mais sentido para você.

Durante a minha (curta) carreira como programador, raramente tive que otimizar trechos de código para extrair o melhor rendimento possível, acredito que isso se deve principalmente por ter trabalhado em projetos simples, sem tantos requisitos de performance. Ainda assim, acredito que raramente você estará escovando bits. Porém, em situações adversas e com infra limitada, será necessário lutar por milissegundos.

Imagine o seguinte cenário: uma aplicação multithread, que processa milhões de registros diariamente e que deve fazer isso de forma eficiente. Imagine também que escalar verticalmente e/ou horizontalmente não é uma opção neste exemplo, por enquanto aceite que não há mais recursos e que depois de code reviews e algumas otimizações lógicas você tem a sensação de não saber mais o que fazer. E ai?

Bom, algo similar aconteceu comigo. Como relatei anteriormente, raras as vezes tive que otimizar aplicações para extrair o melhor rendimento, além disso, o fiz em contextos mais simples, não concorrentes. Então estava em uma situação onde o conhecimento e experiência que eu tinha me levaram o mais longe possível.

Aumentar o paralelismo da aplicação já não me parecia a melhor ideia, muito provavelmente devido a deadlocks e starvations, clássicos problemas de programação concorrente. Então, em conversa com outros programadores, decidimos analisar a aplicação com um profiler a fim de encontrar hot spots.

Profilers são tools para análise dinâmica de código, eles funcionam basicamente observando a execução do código de forma a extrair informações, como quantas vezes um trecho foi executado e qual o tempo de execução.

Com esse tipo de ferramenta é possível visualizar os famosos hot spots, ou seja, partes do programa que demoram mais a serem executados ou partes executadas mais frequentemente. Também é possível identificar quais partes do código consomem mais memória, se esse for o caso.

No mundo java, um bom profiler é o visualmv, o qual é enviado juntamente com JDK 6, 7 e 8. Esse profiler instrumenta o código java adicionando bytecodes extras a fim de monitorar a execução. Para executá-lo basta utilizar o comando jvisualvm no terminal.

Caso não queira utilizar a versão enviada juntamente com JDK, você pode fazer o download da última versão aqui.

Para ilustrar o uso do visualvm, criei um exemplo simples que emula um processamento demorado. Uma simples classe que para cada número par, soma 100 e apresenta no console o resultado. No entanto o último step do processamento é propositalmente lento, pois sem isso não haveria artigo 😂.

Ao executar o visualvm, é possível ver na tela inicial todos os processos java que estão sendo executado na máquina local. Para começar a analisá-los o que você precisa fazer é simplesmente um double click. Com o código de exemplo executando, procure no visualvm um processo chamado Main. Abra o processo, selecione a aba Profiler e depois clique no botão CPU. Nesse momento o visualvm deverá instrumentar o código a fim de começar a registrar os dados necessários. Em aplicações grandes esse processo pode demorar algum tempo, por isso, nas configurações podemos especificar quais classes ou pacotes queremos instrumentar.

Na imagem abaixo é possível perceber que o método process é responsável pelo maior tempo de CPU mesmo sendo executado metade das vezes do método evenNumber. O que quero ilustrar aqui é o fato de um profiler poder indicar pontos mais específicos, nos quais podemos focar nossos esforços de otimização.

Esse foi exatamente o resultado no projeto que estive envolvido. Após executar o profiler na aplicação identifiquei alguns hot spots que eventualmente foram reescritos para reduzir o tempo de processamento, seja utilizando cache dos resultados de processamentos externos ou reaproveitando objetos caros.

Pessoalmente, não acredito que devemos sair por aí executando profilers em todas as aplicações e otimizando indiscriminadamente algo que funciona muito bem. Devemos otimizar código somente quando for necessário, pois nem toda otimização tem o mesmo ROI, ou seja, algumas otimizações não serão percebidas pelo seu cliente. No entanto, isso não quer dizer que podemos ser desleixados com o código, otimizar o código de certa forma passa naturalmente por conhecer melhor as ferramentas que usamos, como por exemplo saber quando faz sentido usar LinkedList no lugar de ArrayList. De toda maneira, um bom profiler é uma boa opção para se ter na sua caixa de ferramentas, porém nunca esqueça que em muitos casos a otimização prematura é a raiz de todo mal.

Mas para atingir objetivos precisamos do mínimo de planejamento. Para um planejamento de um ano precisamos principalmente ser realistas com nós mesmos e não nos enganarmos. Muitas vezes, iniciar com objetivos menores nos motiva a buscar objetivos maiores. Além disso, um objetivo muito ambicioso, por parecer muito difícil alcançar, pode nos desencorajar.

Uma técnica que uso para realizar meu planejamento anual é conhecida como smart goals. SMART é um acrônimo que representa 5 caraterísticas de uma boa meta, as quais podem ser úteis para avaliar as suas metas pessoais.

SMART Goals​

SMART é um acrônimo que representa 5 caraterísticas de uma boa meta, as quais podem ser úteis para avaliar as suas metas pessoais.

Saiba mais

Como SMART Goals funciona​

Basicamente cada letra SMART possui um significado, uma característica que nos ajuda a focar e pensar se nossa meta é boa em um determinado aspecto. O segredo é verificar se sua meta possui todas essas qualidades. Abaixo explico de forma resumida o significado de cada letra:

S - Specific (específico)​

Uma meta precisa ser específica, ou seja, precisa ter um resultado claro, não pode ser genérica ao ponto de não sabermos como alcançá-la. Aqui pode ser necessário identificar pontos como: quem, quando, como, onde, etc.

M - Measurable (mensurável)​

Uma boa meta precisa ser mensurável, precisamos saber quão perto estamos de alcançá-la. Definir o tamanho da meta nos ajuda a monitorá-la e entender se a mesma é realista. Nada de manter a meta aberta.

A - Achievable (alcançável)​

Logicamente uma meta precisa ser alcançável. Não é raro vermos pessoas que traçam metas absurdamente difíceis de forma que são inatingíveis. Metas realistas nos ajudam a nos mantermos no caminho, metas irreais nos desmotivam.

R - Relevant (relevante)​

Ao pensarmos em metas precisamos pensar em objetivos relevantes, algo que faça sentido para nós ou para o projeto. Metas que não são relevantes serão descartadas tão logo surja um impedimento.

T - Time-bound (tempo limite)​

Por fim, uma meta precisa de um tempo definido, um deadline. Quando precisamos ou desejamos obter os resultados? Saber quando algo termina nos ajuda também a começar.

Um exemplo de uma meta SMART​

Para ilustrar tudo isso de forma mais prática, compartilho uma meta pessoal de 2020, identificando os 5 pontos SMART nela.

Em 2020 eu gostaria de ler mais livros do que li em 2019. No ano passado eu li um total de 6 livros, entre livros técnicos e não técnicos. Considero importante o aprendizado constante e além disso, ler é um ótimo hábito. Para mim, a leitura está associada diretamente ao desenvolvimento profissional, por isso a maioria dos livros que pretendo ler em 2020 me ajudarão a construir um conhecimento para me tornar um profissional melhor. No entanto, ler mais livros que 2019 não é tão específico, por isso, decidi que em 2020 a minha meta de leitura é:

Ler pelo menos 8 livros em 2020, de forma que a maioria seja sobre engenharia de software e áreas afins.

Specific (específico)​

Quero ler 8 livros, mais que o ano passado e principalmente livros sobre engenharia de software. Já sei quais os títulos que quero ler, o que certamente me ajuda a priorizar e não ler outros temas não relacionados com o objetivo, como as Crônicas de Gelo e Fogo.

Measurable (Mensurável)​

Consigo facilmente medir se estou alcançando a meta, assim, se ao chegar ao meio do ano e não tiver ao menos próximo de concluir o 4º livro, estou provavelmente atrás do esperado. Lógico, existem livros mais difíceis de ler, livros maiores e menores, mas no geral sei exatamente onde estarei.

Achievable (alcançável)​

Considero essa meta alcançável de acordo com os recursos disponíveis, nesse caso, meu tempo. Eu poderia muito bem definir a meta para 10 livros, mas é provável que eu não consiga alcançá-la. Assim, prefiro definir um mínimo de 8, que é superior ao ano passado, mas que principalmente me sinto capaz de fazê-lo.

Relevant (relevante)​

Essa meta está diretamente ligada a minha carreira e desenvolvimento pessoal, por isso é relevante, faz parte de um objetivo maior.

Time-bound (tempo limite)​

Prazo para conclusão dessa meta é o ano de 2020. O importante aqui também é notar que o tempo pode influenciar o tamanho da meta. Se minhas metas fossem traçadas para seis meses, certamente teria que diminuir a quantidade de livros, ou aumentar o recurso (tempo) para alcançá-la.

Conclusão​

Espero que esse artigo o ajude a definir boas metas, não só para os próximos anos, mas também em seus projetos. Planejamento é algo importante e muitas vezes negligenciado por nós. Não podemos ver o ato de planejar como algo exclusivo do mundo empresarial, planejamento deve ser parte do seu mundo pessoal também.

Depois de alguns anos trabalhando como programador no interior do Ceará, decidi que precisava tentar passos maiores na minha carreira. A região que vivia, o cariri cearense, ainda não se tornou um polo tecnológico, portanto, conseguir um bom emprego na área de TI por lá pode não ser tão fácil, já que a região não absorve todos os profissionais que a mesma forma.

Conseguir um emprego melhor como programador, para mim era igual a abrir mão do meu emprego como funcionário público e migrar para os grandes centros. Então, já que teria que deixar minha cidade e ir pra longe, decidi que o melhor seria fazer uma mudança para o exterior.

Embora tivesse alguns anos de experiência, os quais considero pouco, me sentia despreparado para o mercado internacional e por isso, iniciei algumas ações que me ajudariam a conseguir a tão sonhada realocação. Compartilho aqui de forma resumida, 4 coisas que me ajudaram nesse processo:

1. Certificações​

Inicialmente decidi adquirir certificações java, para mim, essa era uma forma de provar que eu possuía conhecimentos suficientes com a linguagem que decidi trabalhar. Estudar para certificações me fez aprender mais profundamente sobre Java e suas principais APIs, e esse é o principal objetivo alcançado. Não quero dizer que certificações são obrigatórias, mas o conhecimento mais aprofundado sobre a linguagem que trabalhamos é sim obrigatório, o qual pode ser adquirido de outras formas logicamente. O importante é dedicarmos um tempo para aprendermos o máximo possível o stack com o qual trabalhamos.

2. Inglês​

Não é necessário comentar que emigrar para outro país, torna o inglês obrigatório. No meu caso, foi um diferencial, já que vim para Portugal. No entanto, a quantidade de projetos nearshore e de empresas de outros países em Portugal, faz com que a língua inglesa seja considerada obrigatória para vários processos de recrutamento. Por isso, dediquei praticamente dois anos de estudos online e um mini intercâmbio para que me sentisse confortável o suficiente com outro idioma.

Além disso, na área de tecnologia, o fato de não saber inglês nos coloca em posição desfavorável, pois os melhores livros e documentações são lançadas em inglês e depois traduzidas pelas comunidades. Saber inglês, pode te colocar em contato direto com a fonte. Quando estudei para certificações java por exemplo, não havia livros em português e a prova de certificação também não era traduzida. Por isso, considero obrigatório ter ao menos um bom nível de leitura em inglês, mesmo que não esteja nos seus planos morar em outro país.

3. Side Projects e Voluntariado​

As empresas buscam profissionais com experiência validada, o que chamam de real world experience. Mas como podemos adquirir experiência de forma rápida? Bem, a área de TI é uma das áreas mais democráticas de trabalho. Não é necessário um grande investimento para começar, podemos comprar um bom equipamento para trabalhar, podemos começar de casa, até mesmo podemos criar um novo projeto e usá-lo como meio para adquirir mais experiência.

Com isso em mente, procurei um projeto internacional no qual pudesse me juntar e contribuir como voluntário, assim poderia pôr em prática o inglês e comprovar para os recrutadores que eu já estava habituado a trabalhar com outro idioma e projetos internacionais.

Seguindo a recomendação de um amigo de trabalho, me cadastrei no site Volunteer Match, e encontrei um projeto para contribuir como voluntário, o qual faço parte ainda hoje mesmo já estando em outro país. O projeto em questão é o 8billionminds, um projeto que promove o compartilhamento de conhecimento gratuito.

Com esse projeto, tenho a oportunidade de discutir temas como arquitetura e evolução do sistema com outros devs de várias partes do mundo, pratico inglês gratuitamente e aumento meu networking. Isso é fantástico, você não precisa sair de casa ou fazer muito para conseguir uma experiência validada. Publique seu código no github, crie projetos open sources, mesmo que não haja contribuições no início. Ter um projeto para se dedicar, também é uma ótima maneira de aprender outras tecnologias.

4. Estudo contínuo​

Se temos que focar em aprender algo bem, devemos focar em aprender o básico. Ter uma base sólida, traz grandes vantagens ao aprender coisas mais complexas. Na minha opinião, devemos focar um tempo considerável em aprender mais profundamente sobre uma linguagem ao invés de frameworks, pois frameworks nascem e morrem e quando você tiver que mudar para um novo, a sua curva de aprendizado será menor caso domine muito bem os conceitos básicos. Por exemplo, trabalhem certo tempo com Java EE, e quando decidi mudar para Spring não senti dificuldades, principalmente porque tinha acumulado um conhecimento mais sólido por conta das certificações.

Conteúdos como algoritmos, orientação a objetos, clean code, TDD são tópicos que transcendem linguagem de programação. Se você trabalha com uma linguagem orientada a objetos, aprender bem o design OO é fundamental, talvez até mais importante que a própria linguagem.

Temos muito o que aprender e por isso, acredito que esse é o tópico mais importante. Muitos desses conhecimentos, só virão com a experiência e a prática, então não se desespere por não saber tudo, você nunca saberá 😀.

Recentemente comecei a ler o famoso livro Clean Code juntamente com o time do projeto no qual me encontro atualmente. Esse é um livro, que na minha opinião, todo programador deve ler e que certamente lhe fará mudar a forma como você programa. Talvez, assim como eu, você pode se perguntar porque não o leu antes.

Passamos mais tempo lendo código do que realmente escrevendo código, portanto não faz sentido mantermos um código sujo. Em um projeto anterior no qual fiz parte, lidamos por muito tempo com um sistema legado e complexo, onde a legibilidade do código era certamente um fator que atrasava todas as estimativas. Além disso, não tínhamos uma cobertura de testes suficiente para nos proporcionar a confiança de refatorar o sistema.

Por várias vezes cogitamos iniciar um novo projeto, que seria melhor e fácil de manter, mas será que conseguiríamos atingir nossos objetivos? Ou acabaríamos por criar outro sistema difícil de manter e que eventualmente seria criticado por outros programadores? Quem garantiria a qualidade do código além do aspecto funcional? Afinal de contas, se funciona ninguém mete a mão. Será se seríamos tão cuidadosos quando os deadlines se aproximassem?

É comum cairmos na armadilha de sermos um pouco mais desleixados porque precisamos ser rápidos. E por que fazemos isso? Certamente, um médico não deixaria de lavar as mãos antes da cirurgia porque o paciente está com pressa. Não há voltas a dar:

Bagunças antigas, reduzem o rendimento, a única maneira é manter o código limpo. Robert C. Martin

Ok, mas o que é um código limpo? Bem, essa é uma pergunta de muitas respostas, não é por acaso que no primeiro capítulo do livro várias personalidades da ciência da computação definem o que é clean code. Dentre as definições apresentadas, ficarei com algumas que na minha opinião resumem a ideia geral:

1. Testes: Um código sem testes não é um código limpo.
2. Legibilidade: Somos autores e temos que tornar fácil a leitura, pois isso facilita a escrita.
3. Responsabilidade: Um código limpo faz bem apenas uma coisa.

Definitivamente, um código sem teste não está limpo. Além de garantir a qualidade do código, os testes nos dão a confiança para melhorá-lo, sem eles, preferimos não tocar no que funciona. Se tivéssemos uma boa cobertura de teste, refatorar um sistema não deveria ser uma grande dor de cabeça, afinal, os testes assegurariam o comportamento anterior.

Embora seja óbvio que módulos, classes, métodos, todos eles devem fazer somente uma coisa, será que realmente entendemos isso? Pessoalmente, acredito que essa qualidade requer um pouco de treino. Após ler alguns capítulos do livro, comecei a perceber que vários métodos que eu escrevi faziam mais de uma coisa e/ou sabiam demais e assim, se acoplavam com outros módulos/classes desnecessariamente.

O código abaixo foi retirado do meu trabalho de conclusão da graduação em 2014. Embora seja um código simples e pequeno ele sofre de vários problemas. :’(

public List<Product> getList() {
	if(productService == null){
		ProductDAOImpl produtoDAOImpl = DAOFactory.createProductDAO(contextBean.getEntityManagerForTenanty());
		productService = new ProductService(productDAOImpl);
	}
	if (list == null || list.size() == 0) {
		list =  productService.list();
	}
	return list;
} 

Inicialmente, o nome do método nos sugere, que o mesmo retornará uma lista mas não de que e porque, sabemos que é uma lista de produtos, mas quais produtos? Os mais recentes? Os últimos comprados? Um método deve expressar sua função claramente, assim como o nome de uma variável. Outro ponto, e o que me incomoda mais, é que esse método não deveria se preocupar em instanciar o DAO e o Service, esse método já faz mais de uma coisa. Além disso, esse tipo de código cria um outro nível de acoplamento, a classe sabe demais. Ela sabe como recuperar DAOs e criar services. Lembre-se do S do SOLID, um objeto deve ter uma só responsabilidade.

Se a classe A, depende da classe B para funcionar e B é uma dependência obrigatória, então a classe A, deveria receber B através do construtor, basicamente por dois motivos:

1. Isso deixa claro para quem deseja usar a classe A, que ela depende de B e não é possível usar A sem B. Tente não deixar coisas implícitas. Expresse suas suas intenções o mais claro possível.
2. Declarar explicitamente as dependências de um objeto facilita a escrita de testes e como já sabemos, um código sem teste não é um código limpo.

Certo dia, trabalhando no projeto legado o qual mencionei no início do artigo, tentei criar um simples teste unitário e para minha surpresa, ao instanciar uma classe de nome Unidade (salvo engano), com construtor padrão, recebi um erro de conexão com banco de dados. Durante o debug, descobri que objetos que eram criados no construtor da classe sob teste, tentavam se conectar ao banco de dados. What!? Isso mesmo. Por fim, não fiz o teste e não refatorei o código, porque não havia testes que me dessem segurança para fazer tal trabalho. Ou seja, implícito muitas vezes é ruim, falta de teste é ainda pior.

No primeiro capítulo, Uncle Bob relata que deveríamos deixar o código melhor do que o encontramos, o que eu não fiz na ocasião porque caí na armadilha do “depois eu faço”. E aqui mora outro problema conhecido como a lei de Leblanc, depois é igual a nunca. E realmente foi, pelo menos para mim. Nunca voltei no código para refatorá-lo e é provável que o mesmo esteja tal qual o deixei.

Quando se tem um código “sujo”, com bagunças anteriores, sem testes, com baixa legibilidade, etc, temos mais desculpas para não fazermos um código melhor, afinal, tudo já está sujo mesmo não é? Não faz diferença. Isso me lembra da teoria das janelas quebradas: sinais visíveis de desordem encorajam mais desordem. Não tenho dúvida quanto a isso, pelo menos não quando o assunto é código.

Outro ponto negativo do método anterior, é a falta de expressividade no nome das variáveis e métodos. Nomes significativos, métodos pequenos, classes coesas, tudo isso tem um impacto sobre a legibilidade. O código limpo deve contar uma história, deve expressar bem suas intenções e não deveria deixar nada implícito. Aparentemente, um lazy loading é realizado na lista que armazena os produtos, mas isso não é tão expressivo.

Após ler 8 capítulos do livro, veja abaixo como eu reescreveria hoje esse código:

public List<Product> getAllProducts() {
	if (productListIsEmpty()) {
		productList =  productService.getAllProducts();
	}
	return productList;
}

private boolean productListIsEmpty(){
	return productList == null || productList.isEmpty();
}

Primeiro ponto, o nome do método é mais significativo. Segundo ponto, ele faz só uma coisa, recupera a lista de produtos e para isso usa uma instância de um service, que por sua vez, seria passado via construtor da classe, provavelmente por um framework de injeção de dependência como o Spring.

Esse código conta uma história um pouco melhor que a anterior e esse é o último ponto. Devemos contar histórias através do código, para que o próximo programador não tenha que se esforçar tanto para entender o que está acontecendo ali. Mantenha seu código pequeno e simples, tente contar um história e lembre-se, se você precisa escrever comentários para explicar o que está acontecendo, esse pode ser um mau sinal.

Disclaimer: o código acima parece fazer também uma espécie de cache e guarda a lista carregada em uma variável local. Caso não haja uma boa razão para isso, provavelmente a melhor estratégia seria delegar essa função para o framework. Em um projeto Java/Spring a anotação @Cacheable poderia ser um solução aceitável. O que tornaria o código ainda mais limpo, removendo a complexidade acidental.

Este é um post de uma série onde eu comento minhas impressões sobre livros que li e que acredito que valem a pena ler. Você pode conferir a minha lista de must read com os principais títulos no link abaixo.

Referências​

• Clean code
• SOLID

No vídeo abaixo, a poliglota Lýdia Machová conta que decidiu investigar como outros poliglotas aprendiam um novo idioma e qual método eles usavam. Mas para sua surpresa, não existia um método único, cada poliglota usava técnicas diferentes e ferramentas diferentes, no entanto todos tinham algo em comum.

Então qual é o segredo? Aquilo que ninguém te conta? Que a globo não mostra? No fim, o que todos tinham em comum era o fato de aprenderem de uma forma prazerosa, da forma que eles preferem, ou seja, surprise, surprise, é necessário se divertir durante o processo.

Isso quer dizer que o que é legal pra você não necessariamente é legal pra mim e vice-versa, então você precisa procurar a sua forma de aprender. Particularmente, estar sentado dentro de uma sala recebendo o mesmo conteúdo padronizado não funcionou pra mim. Contudo, pesquisar sobre tecnologia, falar sobre assuntos do meu interesse, fez todo sentido e ainda funciona muito bem.

Outro fato que me chamou atenção no vídeo foi a técnica usada pelo Irlandês Benny, pois ele se expunha ao novo idioma mesmo sem ter domínio do mesmo e para mim essa é a forma mais efetiva, pois é assim que aprendemos quando criança, repetindo, falando, errando e recebendo feedback.

Procure algo que goste de fazer e depois descubra como incluir um novo idioma nessa atividade.

Como sugestão, deixo duas alternativas que podem lhe ajudar a descobrir uma nova forma divertida de aprender.

Podcasts​

Se você já tem um nível intermediário, essa pode ser uma ótima ideia. Pessoalmente curto muito ouvir podcasts sobre vários temas, então a primeira coisa que fiz quando decidi começar a aprender espanhol foi procurar podcasts em espanhol, os quais escuto regularmente voltando do trabalho. Além disso, não perco a oportunidade de hablar com alguém que saiba espanhol, dessa forma consigo feedbacks do meu aprendizado.

Podcasts sugeridos:

• Español Espontaneo - podcast sobre temas variados, produzido por professores de espanhol que vivem nos estados unidos (ES)
• Binarios - podcast sobre tecnologia produzido por jornalista do el Mundo especializado em tecnologia (ES)
• Hidden Brain - comportamento humano e storytelling, um dos meus podcasts favoritos. (EN)
• Nerdcast Speak English - dicas de inglês e um papo descontraído (PT)

Grupo de estudo​

Participei de dois grupos de estudos de inglês organizados por amigos. Durante nossos encontros escolhíamos algum tema aleatório ou algum jogo de tabuleiro e nos forçávamos a discutir/jogar em inglês. O ponto positivo dessa abordagem é contar com o apoio do grupo onde todos interagem e aprendem juntos. Quem sabe mais ajuda quem sabe menos.

Agora que você já descobriu o segredo milenar dos trogloditas, digo, dos poliglotas, como você pode tornar seu aprendizado mais divertido?

via GIPHY