Uma polêmica do Java: Lombok
(Read the English version here!)
O ano era 2016, eu era estagiário em uma grande empresa que me deu uma oportunidade de ingressar e construir a minha carreira na área de TI. Trabalhando com um arquiteto de software, eu claramente pude me lembrar de quando ele me apresentou o Lombok, umas anotações mágicas que geram alguns códigos “muito comuns para nós desenvolvedores” por debaixo dos panos como: Builder, Getter e Setter, um construtor com todos os argumentos ou até mesmo um construtor vazio.
Uma série de artigos até agora dizem que Lombok é uma boa ideia, uma boa prática. Mas será mesmo que nós realmente precisamos utilizar Lombok ao invés de utilizar a ferramenta de auto-generate da própria IDE? O quê você acha de gerar os getters e os setters sem nem se preocupar se a sua classe pode algum dia ser imutável, ou analisar se realmente vale a pena que ela seja mutável? Lembremos que alguns devs não conhecem a anotação “@Value”.
Lombok é uma ferramenta preguiçosa para desenvolvedores preguiçosos, é o que realmente é. Ele não força você a pensar nos objetos de modelo porque você está abençoado com a anotação @Data. Faz com que você perca o controle sobre o seu próprio código com anotações mágicas que vão gerar código que você nem mesmo sabe se vai precisar. E eu não digo isso baseado em minha opinião, eu me dei a oportunidade de conversar com demais desenvolvedores a fim de coletar o máximo de informações possíveis. Então, você está economizando espaço no seu repositório GitHub?
Motivos do porquê alguns desenvolvedores não gostam de Lombok:
- Mais dependência da sua IDE: Não dizendo que, como desenvolvedor eu não sou dependente, claro que todos somos, mas depender do Lombok, será que é uma boa escolha? Sabendo o “benefício” que ele nos traz? Uma enorme geração de código desnecessário?
- Mais um passo no onboarding de Desenvolvimento: Não é apenas clonar o seu repositório e simplesmente trabalhar. Você precisa clonar o repositório e também configurar a sua IDE, se não seu código não vai compilar.
- É o famoso “vai na onda”: É tão comum ver a galera defender o Lombok com o argumento de que o Java é verboso. Então quer dizer que a preguiça é uma alternativa? Eu não sei de quê maneira é possível corrigir a verbosidade do Java utilizando o Lombok. O Java É, propriamente dito, uma linguagem verbosa, se você está tentando reduzir a verbosidade dele com Lombok, tem certeza de que escolheu a linguagem correta?
- Adicionar mais uma dependência: Justamente porque seria o mais fácil a se fazer, já que você é preguiçoso o suficiente para dar dois cliques com o botão do mouse e pedir para que a IDE gere o que você precise: Construtores, getters e setters.
- Programação-baseada-em-anotações: É simplesmente colocar a anotação “@Data” que tudo se resolve, dizem os Lombok-lovers. Você nunca ouviu algo do gênero: “Apenas coloque o @Data que ele vai gerar tudo para você”? Ou apenas um “Builder”? Use então “@Builder”.
- Geração de código não utilizado: Você não vai utilizar grande parte do que foi gerado pelo Lombok.
Não usar Lombok fará você trabalhar mais? Não com tanta certeza, a IDE te dá uma série de opções de otimizar o seu trabalho. Mas, mesmo que você trabalhe mais, saberá que sem Lombok, você possui controle do seu código, uma vez que nós não temos códigos inesperados, desnecessários gerados por debaixo dos panos.
Converse com a sua empresa, com seu gerente, com seu amigo, expresse seus argumentos e analise se o Lombok realmente fará com que seu código seja mais produtivo, ou se é apenas mais uma ferramenta popular que foi criada para ajudar, mas que ao invés disso, traz diversos problemas para a comunidade de código.
Graças a Deus nós não precisamos trabalhar com Lombok em Kotlin. ¯\_(ツ)_/¯
