Forem: faibo

A vantagem competitiva de um subdomínio principal não é necessariamente técnica

faibo — Sun, 22 Feb 2026 22:13:23 +0000

Eu sei, parece contraintuitivo. A gente passa anos estudando linguagens, frameworks, padrões de arquitetura, e aí vem alguém dizer que a técnica não é o diferencial?

Calma, não é isso.

A técnica é essencial, mas ela sozinha não sustenta a vantagem competitiva de um subdomínio core. E entender isso muda completamente a forma como você se posiciona, entrega valor e evolui dentro de um produto.

O que define um subdomínio principal

Khononov, separa subdomínios em três categorias: genéricos, de suporte e principais. Nos dois primeiros, a complexidade deve ser minimizada ao máximo, são áreas que não geram diferencial de mercado e, portanto, não justificam investimento pesado em modelagem ou abstração. Compre pronto, use uma lib, delegue. O custo de sofisticar algo que não diferencia o produto é alto demais para o retorno que traz.

Já o subdomínio principal é onde a mágica acontece. É ali que o produto se diferencia da concorrência, onde o modelo de negócio ganha forma no código, onde cada decisão técnica carrega um peso estratégico real. E é justamente por isso que a vantagem competitiva desse subdomínio vai além da técnica.

Se fosse só sobre código, bastaria contratar os melhores programadores do mercado e o problema estaria resolvido. Mas não é assim que funciona, e todo mundo que já trabalhou em um produto complexo sabe disso.

A complexidade certa nasce do problema, não do código

Existe uma diferença enorme entre complexidade essencial e complexidade acidental. A essencial é inerente ao problema que estamos resolvendo, ela existe porque o negócio é complexo, porque as regras são intrincadas, porque o mercado exige. A acidental é aquela que nós mesmos criamos: over-engineering, abstrações prematuras, padrões aplicados sem contexto.

O subdomínio principal precisa abraçar a complexidade essencial. Ela é bem-vinda ali. Mas precisa ser a complexidade certa, e a complexidade certa não nasce de uma decisão técnica brilhante. Nasce do entendimento profundo do problema.

Quantas vezes você já viu um sênior entregar uma solução tecnicamente impecável que não resolvia o problema real? Ou pior, que resolvia um problema que ninguém tinha? Esse é o sintoma clássico de quem domina a ferramenta mas não entende o terreno onde está pisando.

É como um cirurgião com a melhor técnica do mundo operando o órgão errado. A execução foi perfeita, mas o resultado é desastroso.

O especialista que muda o jogo

O profissional que domina o subdomínio principal consegue algo raro: antecipar necessidades que o próprio cliente ainda não enxergou. Ele questiona requisitos que parecem óbvios. Ele não pergunta "como vou implementar isso?" antes de perguntar "por que isso precisa existir?".

Esse é o ponto de inflexão.

Quando você entende profundamente o domínio, a conversa com o time de produto muda. Você deixa de ser um receptor de tarefas e passa a ser um co-criador da solução. Não porque você aprendeu um novo framework, mas porque você entende as dores, as restrições, as oportunidades que o negócio apresenta.

Eric Evans fala sobre isso quando menciona a linguagem ubíqua. Não se trata apenas de nomear classes e métodos com termos do negócio. Trata-se de pensar com os termos do negócio. Quando você internaliza a linguagem do domínio, suas decisões técnicas passam a ser orientadas pelo problema real, e não por preferências pessoais ou tendências do momento.

Na prática, isso se traduz em perguntas que poucos fazem:

Essa feature resolve uma dor real ou estamos apenas seguindo o roadmap no automático?
Esse nível de sofisticação técnica se paga dentro do ciclo de vida desse subdomínio?
Essa modelagem reflete como o negócio realmente opera ou como a gente acha que ele deveria operar?

São perguntas simples, mas que mudam drasticamente a qualidade do que é entregue.

O técnico como commodity

Pode parecer duro, mas o conhecimento técnico isolado está se tornando cada vez mais comoditizado. Isso não significa que ele não importa. Significa que ele é condição necessária, mas não suficiente.

Saber React, Node, Python, Go, qualquer stack, é o mínimo. É a barreira de entrada. O que diferencia é o que você faz com esse conhecimento quando colocado diante de um problema real de negócio.

Pense no seguinte: quantas pessoas você conhece que são excelentes tecnicamente mas não conseguem traduzir problemas de negócio em soluções? Ou que sabem tudo sobre arquitetura mas não entendem por que estão construindo aquilo?

A vantagem real está na intersecção. É quando você entende tanto do problema que a tecnologia se torna apenas a ferramenta, não o objetivo.

O impacto no dia a dia

Quando um dev domina o subdomínio principal, o impacto é visível em várias camadas:

Na qualidade das entregas, porque as soluções resolvem o problema certo.
Na velocidade do produto, porque se gasta menos tempo com retrabalho e features mal direcionadas.
Na comunicação com stakeholders, porque existe um vocabulário compartilhado que elimina ruído.
No posicionamento profissional, porque você deixa de ser a pessoa que executa e passa a ser a pessoa que direciona.

Isso muda a dinâmica do time inteiro. Um dev que entende o domínio profundamente puxa o nível da conversa para cima, desafia premissas fracas e propõe alternativas que só quem vive o problema consegue enxergar.

Como cultivar isso

Não existe atalho. Entender um domínio profundamente exige tempo, curiosidade e, principalmente, disposição para sair da zona de conforto técnica.

Converse com quem opera o negócio.
Pergunte o porquê das regras que parecem arbitrárias.
Entenda a história por trás das decisões que moldaram o produto.
Questione requisitos antes de implementá-los.
Participe de reuniões que teoricamente "não são para devs".
Leia sobre o mercado em que o produto está inserido.

Parece simples, e é. Mas quase ninguém faz. A maioria prefere estudar o próximo framework do que entender por que o cliente cancela o plano no terceiro mês.

O mercado não paga pelo código mais bonito. Paga pela solução que resolve o problema certo, da maneira certa, no momento certo.

E isso, definitivamente, não se aprende só lendo livro técnico.

Referências bibliográficas

KHONONOV, Vlad. Aprenda Domain-Driven Design (2022). EVANS, Eric. Domain-Driven Design: Tackling Complexity in the Heart of Software (2003).

A sua inversão de dependência está alinhada ao negócio?

faibo — Wed, 21 Jan 2026 01:25:28 +0000

Provavelmente você já sentiu a satisfação de inverter a dependência daquela classe queridinha, imaginando os mil benefícios que isso trará para o projeto, os aplausos que irá ganhar e o selo de pessoa que sabe adicionar teorias avanças ao código, mas a pergunta que surge nesse momento é:

"Faz sentido para o negócio inverter essa dependência?"

Alguns devs devem, o trocadilho não foi proposital, estar se questionando sobre o quão absurda essa pergunta pode ser. Como assim o negócio tem a ver com uma simples inversão de dependência?! É nesse ponto que as coisas começam a melhorar, ou não.

Um dos momentos mais marcantes na vida de todo dev é quando conhecemos a beleza da arquitetura de software, especialmente quando aprendemos Arquitetura Limpa e, com ela, o famoso SOLID. Saímos do livro nos achando deuses, capazes de criar qualquer sistema do mundo com essas cinco boas práticas ensinadas pelo "Uncle Bob", mas, na verdade, apenas adicionamos mais um conhecimento ao nosso repertório.

Veja, não estou demonizando nada do que está no livro; mesmo discordando de muitos pontos, claramente é uma excelente abordagem para problemas reais que provavelmente enfrentaremos. Dito isso, falemos especificamente da letra D (Dependency Inversion Principle - DIP) do SOLID, que diz:

"Módulos de alto nível não devem depender de módulos de baixo nível; ambos devem depender de abstrações (interfaces ou classes abstratas), e abstrações não devem depender de detalhes (implementações concretas)."

De forma bem resumida: devemos fazer com que nossos objetos dependam de interfaces (contratos) e não diretamente de outros objetos. Quais as vantagens? Claramente desacoplamento, testabilidade, reutilização de código e modularidade mais eficiente. No papel isso é incrível, ter a facilidade de usar qualquer adaptador, manipulando interfaces e blindando-se de dificuldades técnicas, mas e quando as complicações surgem além do código?

O DIP carrega consigo alguns problemas que fogem do software e atingem diretamente o negócio. Um dos principais é a complexidade inicial adicionada em fases embrionárias do projeto, o que piora quando é aplicado em POCs e MVPs.

Outro problema menos latente, porém complicado, é a invariância do código. Você já pegou um projeto em que ao navegar entre métodos, foi jogado para uma interface e só?! Sei que no editor você pode apertar F12 e ir para a implementação, que muitas vezes está "flutuando no limbo" de classes e não diz muito sobre a comunicação entre elas, mas já parou para pensar quanto tempo se perde com isso? Esse custo cresce exponencialmente conforme o sistema aumenta.

Essa carga cognitiva desperdiçada pode cobrar seu preço em prazos curtos para implementar algo importante e isso afeta diretamente a velocidade com que o sistema evolui junto ao negócio. Dependendo da volatilidade do segmento no qual ele está inserido, o sistema precisa mudar tão rápido que até uma simples invariância pode interferir na vantagem competitiva que depende de timing.

Além da quantidade de código acrescentada, já que você precisará criar abstrações para cada dependência, outro ponto é a maturidade técnica do time. Existe uma curva de aprendizado considerável sobre a aplicabilidade do DIP, não digo exclusivamente sobre como colocar no código, mas sim, o porque de colocá-lo. Dependendo do estágio da aplicação, esse pode ser um preço que não se paga no curto ou médio prazo.

O software deve ser apenas um meio para resolver um problema de negócio. E não entenda a palavra "problema" como um mau funcionamento ou algo relacionado, mas sim, como o diferencial competitivo que dá sentido à existência do produto como um todo. O negócio é algo vivo; portanto nosso pensamento, desde a mais simples linha de código, deve ser orientado ao problema a ser compreendido, tratado e evoluído.

A ideia desse texto vai além dos trade-offs do DIP, trata-se de levantar questionamentos antes de aplicar padrões by the book. Para não ser apenas um dev que cospe código, mas também, uma peça chave na estratégica do negócio e em sua evolução, por isso considere estas reflexões:

Tamanho do projeto

Projetos para validar hipóteses devem ser os mais simples possíveis. Inserir código desnecessário nessa fase pode mais atrapalhar do que ajudar.

Seu projeto é grande o suficiente para que o DIP se pague no médio/longo prazo?
Ele requer esse nível de desacoplamento em fases embrionárias?

Tipo de domínio

"Domínios genéricos e de suporte devem ser encorajados a diminuir ao máximo sua complexidade." - Vlad Khononov

Khononov afirma isso pois, geralmente, apenas os domínios principais trazem vantagem competitiva de mercado e neles devem estar concentrados toda complexidade necessária. O custo da complexidade acidental em subdomínios de suporte é muito alto em relação aos ganhos.

Estou atuando em um domínio principal do negócio?

Conhecimento técnico do time

O time tem conhecimento concreto sobre DIP?
O time compreende os desafios que esse princípio traz?
O time se sente confortável em dar manutenção em códigos que utilizam DIP extensivamente?

Acoplamento

Nem toda classe precisa dessa abordagem. Se uma classe recebe em seu construtor uma utilitária que não será usada por mais ninguém (relação 1x1), ela é uma forte candidata a não ter inversão de dependência.

Essa classe tem, ou pode ter, uma relação 1xN?
Ela poderá receber múltiplos clientes/implementações?

Com isso, as decisões táticas ficam mais ricas. Cada escolha importa. Estar consciente de cada passo é a melhor forma de garantir que nós, e o produto, tenhamos diferencial competitivo.

A última reflexão é uma frase potente sobre engenharia de software:

"Evite absolutos".

Evite o "sempre" e o "nunca". Nenhum software é igual ao outro; não há bala de prata, mas sim um repertório de soluções para cenários específicos. Use-o com sabedoria.

Referências bibliográficas:
MARTIN, Robert Cecil. Arquitetura Limpa (2019)
KHONONOV, Vlad. Aprenda Domain-Driven Design (2022)

Clean Code no Cinema

faibo — Wed, 28 Jun 2023 13:01:18 +0000

Independente de quanta experiência você tenha, seja estudando, trabalhando ou até mesmo sendo hoje seu dia zero na programação, com quase 100% de certeza você já ouviu ou vai ouvir sobre Clean Code e quando esse momento chegar, sinta-se feliz.

Na minha humilde opinião, esse é o tema que consegue dividir com muita facilidade os bons dos maus programadores e programadoras; não que essa divisão seja uma necessidade prioritária ou de extrema importância, mas ela é essencial para quando você empacar nos estudos.

Nesse texto, não vou te ensinar sobre clean code e nem “como aplicar clean code agora mesmo no seu código em 5 passos”, mas sim explicar um pouco do que NÃO É clean code e sobre alguns mitos que vejo espalhados por aí.

Em 2021 era bem comum ver publicações no LinkedIn sobre kits que pessoas recebiam ao entrar em alguma empresa; entre mochilas, copos plásticos e mousepads, achava-se com bastante facilidade o livro Clean Code lançado em 2008 e escrito por Robert Cecil Martin - Uncle Bob.

Isso é algo interessante pois a gente pode se perguntar:

“Porque eu ganhei isso da empresa?”

E a resposta é bem simples - mas não simplória:

Eles querem que o seu código tenha qualidade.

E aqui surge o ponto principal de toda discussão em torno de Clean Code.

Qualidade!

Por mais que todo mundo saiba o que é qualidade, ninguém consegue defini-la com algum grau alto de certeza, até porque quando se fala de código, construção de software e usuários, a palavra “qualidade” passa por várias transformações e significados diferentes..

O que é qualidade em um software?

O programador ou programadora provavelmente dirá que é um código com boa legibilidade, já para gestores de projetos velocidade em manutenção e adição de novas features é a resposta correta, entre CEOs pode ser um software que tenha um baixo custo por bugs, mas para o cliente pode ser uma paleta de cores bonita ou uma aplicação que não trave.

Portanto, qualidade pode ser uma ou várias coisas ao mesmo tempo, e todos que comentam sobre ela, estão corretos - em seus respectivos espaços.

Um pouco confuso, não?! A partir disso, certezas sobre “qualidade” e “clean code” são fincadas na internet que acabam muito mais atrapalhando quem está começando do que trazendo respostas.

Por isso, separei 2 mitos que devem ser no mínimo tratados com ceticismo antes de comprar a camisa “Clean Code = código pequeno e rápido”.

Querida, encolhi as crianças (1989)

No finalzinho dos anos 80 o diretor Joe Johnson deu vida a um dos meus filmes preferidos que por muito tempo foi reprisado na tv aberta.

Um cientista, que não tinha muita coisa para fazer, resolveu testar um dos seus mais novos experimentos em seus dois filhos e como resultado, as crianças encolheram; e ao longo do filme você acompanha a jornada dessa família para trazer tudo de volta à normalidade.

Mas o que isso tem a ver com Clean Code?

Nas rodas de conversa sobre software é bem comum você ouvir coisas do tipo:

“Clean Code é código pequeno”
“Clean Code é só trocar os ifs e os laços por algum método mais moderno”
“Se você reduziu 30 linhas do seu código, então ele está limpo”

Mas a verdade é que esses pontos estão muito mais errados do que certos, pois a redução de código é bem mais uma consequência de um código limpo do que de fato a definição própria dele.

Qualidade de código - falando exclusivamente da área de desenvolvimento - está diretamente ligada à legibilidade do código, ou seja, o quão fácil é para você e outras pessoas lerem e entenderem aquilo que foi escrito.

Vá por mim, o computador após receber as instruções binárias está pouco se lixando para a beleza do seu código, ele apenas vai executar o que lhe foi solicitado, portanto, você não escreve códigos para computadores, mas sim para outras pessoas, então é sua responsabilidade saber escrever um bom código.

Da uma olhada nesses códigos e me diga qual dos dois está mais legível:

Primeiro código:

for (let i = 0; i < 7; i++){
// Faça algo
}

Segundo código:

const diasDaSemana = 7;
for (let i = 0; i < diasDaSemana; i++){
// Faça algo
}

Olhando rápido, não parece ter diferença, certo? Até porque é um simples laço que deve executar algo até que a variável controladora de loops se torne falsa.

Agora faça um exercício de imaginação: você acabou de chegar em uma empresa nova, acabou de puxar o código para o seu computador e se depara com esse laço.

Observando o primeiro código provavelmente você vai parar alguns segundos e se perguntar, “Mas que diabos significa esse 7 aqui?” .

Você vai gastar um certo tempo tentando adivinhar seu significado, ou se ele está aí apenas por acaso - e muito provavelmente essa nunca vai ser uma opção válida. Em quanto tempo você finalmente entenderia que esse número simboliza os dias da semana?

Já no segundo código essa informação está extremamente explícita, um pouco maior - mesmo que seja apenas uma linha - e muito mais legível.

Agora passo para você a pergunta, qual dos dois códigos tem mais qualidade para desenvolvedores?

O tempo ganho nessa simples situação poderia ser convertido em adição de novas features, manutenção de outras partes do código, maior entendimento na resolução de bugs e um CPB (custo por bug) muito mais barato.

Portanto, um código limpo não significa diminuição de código.

Velozes e furiosos (2001)

Tenho um tio que não gosta de nenhum tipo de filme e ele afirma isso em cima de um argumento muito válido - para ele.

“Nada que passa nesses filmes é verdade, é tudo mentira, onde já se viu um cara pular de um avião e não morrer?!”

E o mais bizarro de tudo isso é que ele tem razão.

Nós assistimos filmes sabendo que tudo ali é ficção e mesmo assim relevamos isso sem muitos problemas, parece até que nos deixamos ser “enganados”. E não há nenhum problema disso, ou vai me falar que você não tem aquela franquia mentirosa que leva no coração?

A minha é “Velozes e Furiosos”, mesmo sabendo que todos os filmes que vieram depois do segundo, são bem ruins.

Trazendo isso pro mundo dos códigos, esse é outro mito bastante parecido com o que comentei acima sobre tamanho. Já vi pessoas atribuindo Clean Code a código mais rápido - e mais furioso. Utilizando esse argumento para afirmar que um código limpo é um código com mais performance.

Clean Code não é sinônimo de alta performance em código, mas alta performance pode ser consequência de um código limpo.

Performance de software é um assunto extremamente interessante, mas precisa de um texto único para ele, mas hoje vou me limitar apenas ao paralelo dele com qualidade de código.

Performance geralmente é atrelado a velocidade, mas será que de fato essa é a principal métrica?! Provavelmente não.

E aqui entramos em uma questão já conversada aqui. Performance é outro conceito que varia de qual área está falando sobre ele. Para um desenvolvedor ou desenvolvedora pode estar relacionado ao tempo que um algoritmo executa, para a gerência de produtos, pode ser sobre a facilidade em se implementar features novas, para o usuário final pode estar ligado a quantidade de requisições processadas durante o acesso e etc.

Portanto - falando de qualidade de código -, Clean Code é uma melhora na legibilidade do código que pode trazer performance, não o contrário.

Vamos a outro exemplo:

Primeiro código:

const arrayInteressante = [1, 2, 3, 4, 5];

for (let i = 0; i < arrayInteressante.length; i++){
// Faça algo
}

Segundo código:

const arrayInteressante = [1, 2, 3, 4, 5];

for (
   let i = 0,
   tamanhoDoArray = arrayInteressante.length;
   i < tamanhoDoArray;
   i++
    ) {
// Faça algo
      }

Esse exemplo é ótimo para falar sobre contexto. Imagine que na sua equipe, por algum motivo, existem desenvolvedores que acabaram de migrar de área, ou de paradigma ou de linguagem e não estão tão familiarizados com certos métodos, como por exemplo o “length”.

Por mais que uma estrutura de laço possa ser familiar a desenvolvedores, o método talvez não, e por isso pode causar uma certa demora na leitura do código. No primeiro código temos um laço simples que executará algo enquanto a variável de controle for maior que o comprimento do array referenciado.

No segundo exemplo, temos o mesmo laço, porém agora foi inserida mais uma variável - tamanhoDoArray - na área de controle, apenas para deixar mais explícito que a condição se trata do tamanho da array, e isso trouxe um ganho de performance para o código, onde antes o laço precisaria checar o tamanho do array a cada iteração, agora ele acessa esse valor da variável uma única vez e itera de maneira mais rápida.

Um código maior que o primeiro, porém com mais legibilidade e por consequência, mais performance.

Esse é um bom exemplo de Clean Code.

Misery - louca obsessão (1990)

Portanto, quando ouvir ou ler sobre Clean Code lembre-se sempre de legibilidade. Quanto mais fácil para ler e entender seu código, mais limpo ele estará.

Comecei esse texto falando sobre o quanto ele serve para criar uma diferença entre bons e maus desenvolvedores, aqui reafirmo que essa não é uma necessidade importante ou muito menos algum parâmetro de avaliação pessoal, mas serve como forma de você começar a perceber sua evolução.

No final das contas, aprender uma linguagem, framework, biblioteca ou qualquer outra coisa se torna um processo mais fácil, pois é algo que você irá fazer ao longo da sua carreira, entretanto ter um código limpo está muito mais relacionado a pensar no outro - que pode ser você mesmo - do que decorar um punhado de métodos em uma documentação.

E para concluir, trate legibilidade de código, com a mesma paixão que Annie trata os textos de Paul em Misery - mas nem tanto.

Clean code, de Avril Lavigne a batatas

faibo — Tue, 28 Feb 2023 12:56:35 +0000

Oi, me chamo Fábio e assim como você sou uma pessoa que desenvolve softwares.

O que?! Você não desenvolve?!

Claro que sim, não é porque talvez você ainda não esteja recebendo por isso que não seja, mas se você veio atrás desse assunto é porque você, sim! já é uma pessoa desenvolvedora.

Pode achar que estou escrevendo isso de forma genérica, pra um monte de gente, mas queria te certificar de uma coisa, eu estou escrevendo esse texto para duas pessoas:

Para mim e para você.

Eu lembro perfeitamente no dia que ouvi alguém falando sobre “Clean Code”. Não fazia ideia do que era, pesquisei e pesquisei até encontrar certos materiais que mais me confundiam do que me ajudavam, mas de uma coisa eu tinha certeza, esse assunto seria - e é - extremamente importante pra mim.

E por isso queria fazer um contrato com você agora. Até o final do texto eu vou te ensinar algumas coisas e você vai ser capaz de:

Entender o que é Clean Code
Saber um pouco da história - sim, é importante também.
Saber quando e porque usar.
Como isso vai mudar sua carreira para sempre.
Fazer arte.
Limpar seu quarto.

Em troca eu só peço uma coisa:

Que você chegue ao final desse texto e responda a pergunta do último parágrafo.

Estamos entendidos?

Eu sei o que você veio fazer aqui

Como disse acima, eu sei que você veio parar aqui pelo mesmo propósito que eu tive em procurar sobre o assunto, e a boa notícia, é que você não apenas programa, mas sim desenvolve.

Você se importa com a qualidade do que você entrega, e aqui queria parar um pouco sua leitura para te fazer uma pergunta safada:

*Você sabe o que entrega além do código? *

Não precisa responder agora porque vamos descobrir ao decorrer do texto.

Existe uma diferença muito grande entre quem programa e quem desenvolve. Um programador ou programadora na maioria das vezes é apenas o ser vivo entre a cadeira e o computador que digita o código para o computador executar da forma que lhe foi solicitado.

E só…

Pra mim isso é um saco. Receber instruções de outras pessoas para colocar instruções em computadores. Quem é a máquina no final desse ciclo?

Do outro lado da rua está a pessoa que desenvolve.

Ela não apenas passa as instruções para o computador, mas como também pensa sobre o que está fazendo, para quem está fazendo e, além disso, como está fazendo.

Para ser um programador ou programadora você só precisa de um computador.

Para ser um desenvolvedor ou desenvolvedora, você precisa ter coração - e um código limpo.

Cheira tão mal assim?

Imagine a cena.

Você abre sua IDE, baixa o código no qual vai trabalhar, depois de alguns minutos lendo aquele código, algo começa a embrulhar no seu estômago, coceiras aparecem pelo corpo e você começa a perceber que um meteoro não seria tão ruim para a humanidade.

Esse é um dos efeitos colaterais em se trabalhar com um código ruim. Raiva, angústia, vontade de quebrar algo e proferir uma quantidade enorme de palavrões por minuto, e é bom você saber dessa métrica a seguir.

“Um código bom - ou limpo - é inversamente proporcional à quantidade de palavrões por minuto que uma pessoa solta ao ler tal código.”

Provavelmente você já ouviu a expressão “Isso está cheirando mal!”. É exatamente o que você deveria falar quando começa a ler um código ruim e talvez - opinião minha - o termo “code smells” tenha alguma origem nessa expressão.

Portanto, a partir de agora, sempre que você ouvir ou ler essa expressão, saiba que estão se referindo a código ruim.

E essa é uma das habilidades que você precisa desenvolver a partir de hoje. Não só ler ou escrever códigos, mas sim sentir o cheiro deles para - agora sim - conseguir limpá-los da melhor maneira.

Então estamos claros? O clean code é uma forma de - literalmente - limpar um código para que ele seja mais “cheiroso” para os outros desenvolvedores, ou você do futuro.

Guarde essa informação, pois vamos falar um pouco mais dela à frente.

Ok, Fábio, mas de onde surgiu isso?

Sem muitos rodeios, o principal símbolo do Clean Code é um livro lançado em 2008 que leva esse nome, e nele você conhece uma relação de boas práticas na hora de criar códigos e - o principal - o motivo para fazê-lo.

Antes de continuar o texto queria roubar um pouquinho da sua atenção para esse ponto. Se você não pretende comprar livros de tecnologia, sugiro fortemente rever esse pensamento.

Livros de tecnologia são ótimos! Entretanto sofrem de um problema que eu e você sofremos, eles envelhecem.

Assim como nós, a tecnologia é viva. O que você aprendeu hoje, provavelmente já terá uma versão atualizada amanhã, e no final das contas o que sobra para absorvermos é a experiência e o repertório que elas nos dão.

Alguns livros envelhecem muito mal, ao ponto de estarem defasados em questão de meses e outros parecem ter genes da Avril Lavigne.

O Clean Code parece estar no meio dessa escala Lavignesca. Ele foi criado em um determinado momento da história sob circunstância quase exclusivas daquele cenário e tempo, mas como disse acima, você deve absorver, não só as dicas, mas a experiência e forma de pensar na hora de resolver problemas - isso nunca envelhece.

De maneira bem resumida, o livro foi “escrito” por Robert Cecil Martin, ou Uncle Bob (“tio bob") como geralmente é chamado. A palavra escrito não está entre aspas de à toa, apesar de levar a autoria da obra, Martin teve ajuda de outras grandes pessoas do mundo da tecnologia para nos trazer essa belezura de livro.

Apesar de algumas polêmicas, Martin é importante para alguns pontos que vamos conversar hoje. Além de ser autor de ótimos livros de tecnologia como o Clean Architecture, Clean Agile, Clean Coder e o próprio Clean Code; o tio Bob levantava algo que eu defendo muito sobre escrever código.

Somos artistas!

Mas vamos falar disso mais tarde.

O Clean Code é fácil de ser encontrado na internet, com preços bem acessíveis, desde mídias físicas a digitais. Aqui afirmo que ele é uma leitura obrigatória, mas não é uma leitura urgente e nem aquela que você precisa ler da noite para o dia.

Da primeira vez que eu li, se entendi 40% foi muito, depois da segunda leitura consegui entender um pouco mais, e a cada nova leitura me surpreendo com algo novo. Então se posso sugerir uma forma de ler ele, leia no tempo do seu conhecimento.

Clean Code e batatas

O livro foi escrito para trazer técnicas, um quanto filosóficas, sobre como deixar um código mais limpo, assim como também, utilizar tais técnicas para economia de dinheiro, tempo e uma melhor saúde mental.

Ele traz uma relação de grandes problemas que Martin descreve ter tido ao longo de seus anos atuando como desenvolvedor. Em algumas entrevistas ele comenta que já trabalha com códigos desde os anos 70, limpando, escrevendo, debugando e - principalmente - lendo código dos outros.

E aqui quero já deixar uma coisa clara, se você gosta de Javascript assim como eu, saiba que no livro a maioria dos exemplos são em Java, mas nada que atrapalhe a sua compreensão.

Esse talvez seja o ponto que mais divide a opinião dos leitores. Martin escreve sobre um contexto vivido por ele há alguns anos, onde tecnologias eram diferentes, editores de códigos eram diferentes e até mesmo a linguagem que ele usava, é diferente da que se usa hoje.

Por exemplo, no livro ele comenta sobre alguns problemas de indentação, de como isso prejudicava a leitura e por não ter um padrão, os desenvolvedores faziam da maneira que lhes dava na cabeça.

E hoje apertando duas teclas, em qualquer editor de código, esse problema se resolve em um segundo.

Isso pode parecer um tanto quanto inútil nos dias de hoje, mas a lição que você deve tirar disso não é sobre a facilidade ou a maravilha de se viver com tecnologias que resolvam isso de maneira simples, mas sim:

Como isso era um problema
O que impactava para os desenvolvedores
Qual o pensamento por trás da resolução

Eu tenho certeza que se você olhar por essa ótica, conseguirá encontrar problemas parecidos e usar soluções quase idênticas.

Fábio, e as batatas?

Coincidência ou não, o Código Limpo foi publicamente lançado em 2008, no mesmo ano para o qual foi eleito - pela ONU - o ano internacional da batata.

Não acredita em mim? Então vai rapidinho no Google e depois volta pra cá.

E aproveitando o papo, você sabia que limpeza e batata tem tudo em comum?

Batatas possuem ácido oxálico, sendo um componente químico letal em grandes doses, porém em pequenas é excelente para fabricação de tintas, corantes e melhor ainda para eliminar gordura e ferrugem.

Talvez seja esse o motivo para a ONU escolher o ano da batata o mesmo ano do lançamento do Clean Code?!

Clean Code e carreira

Eu já enchi o saco de muita gente nessa vida, não ao ponto de ser insuportável, mas sim em perguntar a mesma coisa para pessoas diferentes.

No últimos anos, uma das perguntas que sempre gostei de ouvir respostas diferentes foi:

Como um ou uma jr pode virar pleno ou plena?

Tive respostas curtas, longas, diretas, enigmáticas e até bem filosóficas, mas houve um tema específico que se repetia em 99% delas.

Código Limpo.

Ter um código limpo não é um mero capricho, ou algo para mostrar a seus superiores como você consegue resolver uma cadeia imensa de ifs utilizando switch.

Vai muito além disso, podendo passar por temas como qualidade de código, economia, base forte de programação entre outros, mas o aspecto crucial de escrever um código limpo é a empatia.

Queria que você guardasse no coração essa palavra.

Escrever um código limpo é se importar com quem vai lê-lo.

Não ache que o computador vai se importar com o seu código, isso é bobagem. Os computadores querem saber se funciona ou não. Você pode gastar 900 linhas para rodar um simples for, eles não vão ligar para o jeito que você escreveu.

Apesar de serem uma parte do nosso público, queria que a partir de agora você prometesse para mim e para você que escreverá códigos primeiramente para outras pessoas e depois para computadores.

E você se inclui nesse grupo de pessoas também.

Ou está achando que nunca mais vai tocar naquele código que escreveu meses ou anos atrás?!

Essa é uma das melhores habilidades de uma pessoa que desenvolve software, a percepção e a preocupação de quem vai pegar seu código depois de você.

Não veja - ou veja - como romantismo tecnológico, mas eu sei que um dia você vai me agradecer por levar isso a sério.

Não só por saber que está ajudando outra pessoa, mas por ter reconhecimento disso em sua carreira.

Vão cobrar de um jr que ele apenas faça o código rodar.

Vão cobrar de um pleno que ele faça rodar e que esteja limpo.

Você quer ser jr por quanto tempo?!

O Show vai começar

Ontem a noite eu vi o filme do Elvis, apesar de não ter escutado muito suas músicas, o que a história despertou em mim foi surreal.

Imagine o Elvis, que se dedicou aos montes para fazer algo que gostava. Noites em claro treinando, treinando e treinando. Aperfeiçoando cada vez o sua habilidade, e no final, recebia dinheiro e aplausos de todos.

Um grande artista!

Quantas desenvolvedoras e desenvolvedoras não tem histórias parecidas com a do Elvis?! Não no sentido literal de sua história de vida, mas falo sobre a dedicação em se fazer aquilo que se propõe e gosta.

Tenho amigos e amigas que dedicam horas de estudo e prática todos os dias em desenvolvimento de software, trazendo paixão em cada linha de código e se importando em dar uma experiência agradável para quem vai usufruir dessa habilidade.

O que os diferencia de artistas?!

Nada!

Ambos dedicam sua vida e habilidades para entregar uma boa experiência a alguém. A maior diferença é que na programação a arte é compartilhada, criada sob muitas mãos e o melhor de tudo, traz uma experiência não só para o público final, mas para nós mesmos quanto artistas.

Parece muito romântico mais uma vez, não é?!

Mas me permita fugir um pouco do assunto para te mostrar algo bem legal.

Quando um artista faz algo que todos conseguem perceber que de fato aquilo é arte? Que aquilo foi muito bem feito?

Todos vão à loucura, suspiram, gritam, batem palma, assobiam ou demonstram sua satisfação de alguma forma.

Em 2018 Dan Abramov, um desenvolvedor assim como eu e você, palestrou durante alguns minutos na React Conf. Durante a palestra ele fez uma demonstração de um código, que não só trazia melhorias para a ferramenta, mas sim a deixava mais limpa.

Dá pra ver claramente seu nervosismo durante a apresentação, mas quando tudo dá certo sabe o que acontece?

Não vou estragar sua experiência, clique no link aqui embaixo e pule para o minuto 22:25.

Dan é um artista, assim como eu e você.

E sabe o que ele mostrou nesse vídeo?

Limpeza de código.

Meia no chão e toalha na cama

Eu sei que nesse ponto eu posso ter decepcionado você. Deve estar se perguntando “onde está o código que vai mudar minha carreira?”, ou como acabar com aquele aninhamento de ifs ou o famoso callback hell.

E aqui quero fazer um mea culpa; de fato não vou te mostrar isso hoje, mas vou te ensinar algo melhor.

A arrumar seu quarto!

O primeiro ponto é:

Preste atenção nas coisas que entram no seu quarto.
Nós dois sabemos que se algo entra no quarto, seja uma sacola, chiclete, garrafa ou copo, isso só vai sair depois de uns bons dias e provavelmente haverá coisas que ficarão para sempre.

Então para evitar isso, comece a perceber as coisas que você leva para dentro do quarto.

Se você pode fazer algo em outro lugar, como beber um copo de água na cozinha, ou deixar os sapatos na entrada da casa, o faça.

Deixe lá, não precisa trazer para dentro do quarto, ou crie algo que impeça que essas coisas entrem no quarto.

Arrume uma coisa de cada vez
Não comece retirando os papéis do chão no mesmo momento em que dobra seu lençol ou tira a toalha de cima da cadeira.

Se proponha a limpar algo, faça, termine e vá limpar outra coisa.

Isso faz com que você não se perca na hora de concluir algo, ou muito menos na responsabilidade que você tem naquele momento.

Por mais que seja simples, se você precisa apenas tirar a meia do chão, comece e termine essa única tarefa antes de ir para outra.

Cuidado com o que você tira no final da limpeza
Não saber organizar a limpeza do seu quarto pode trazer dores de cabeça bem chatas.

Imagine que durante a limpeza, você trouxe a vassoura para o quarto, deixou ali no canto, pegou um bolo de roupa suja que estava na cama e levou para máquina de lavar. Depois de uns bons dias percebeu que no meio das roupas havia um pedaço de papel importante.

Ou para piorar, você talvez nem se lembre ou saiba que algo de valor foi junto com as roupas.

Já perdi uns bons reais assim dentro de calças e bermudas.

Portanto, preste bastante atenção com o que você leva para fora do quarto, pois nunca se sabe se algo de valor - ou constrangedor - foi para fora.

Para finalizar vamos relembrar:

Preste atenção em tudo que entra no seu quarto.
Arrume uma coisa de cada vez.
Cuidado com o que você tira do seu quarto.

Agora que você já sabe arrumar seu quarto, vamos arrumar seu código?!

Imagine que seu quarto é uma função que precisa somar 2 números.

 function SomarDoisNumeros(primeiroNumero, segundoNumero) {
 // aqui é o seu quarto
 }

O primeiro passo é se preocupar com o que entra na nossa função, assim como as coisas que entram no seu quarto.

Se eu preciso somar dois números, não existe motivo para eu deixar outros tipos de dados entrarem na função, por isso o melhor a se fazer é prevenir que isso aconteça.

function SomarDoisNumeros(primeiroNumero, segundoNumero) {
 if(typeof primeiroNumero !== "number" && typeof segundoNumero !== "number" return;
 // aqui é o seu quarto
}

Se os tipos de dados que chegarem a função forem diferentes de número, o fluxo acaba ali mesmo.

Agora devemos fazer uma única coisa de cada vez, ter apenas uma responsabilidade por tarefa.

function SomarDoisNumeros(primeiroNumero, segundoNumero) {
 if(typeof primeiroNumero !== "number" && typeof segundoNumero !== "number" return;

 const resultadoDaSoma = primeiroNumero + segundoNumero
 // aqui é o seu quarto
}

A função apenas soma e nada mais.

E por último, tenhamos certeza do que está saindo da nossa função - ou do nosso quarto depois da limpeza.

function SomarDoisNumeros(primeiroNumero, segundoNumero) {
 if(typeof primeiroNumero !== "number" && typeof segundoNumero !== "number" return;

 const resultadoDaSoma = primeiroNumero + segundoNumero

 return resultadoDaSoma;
}

Assim como seu quarto, esse código agora está limpo e o mais importante, ele está totalmente legível para outras pessoas.

Você está me devendo!

Lembra que lá no início nós fizemos um acordo?!

Eu iria te ensinar umas coisas e você me responderia uma pergunta.

Então, depois de conversamos sobre a necessidade de limpar um código, sobre como você - SIM - produz arte, sobre carreira, limpeza de quarto e sobre a importância de se preocupar genuinamente com a outra pessoa que irá pegar seu código:

Você quer ser uma pessoa que só programa ou que desenvolve?

Até a próxima 👋