2 min de leitura ·

CLEAN CODE - A verdade absoluta? 😲🤔

Sim, clean code. Com certeza você já ouviu sobre isso dezenas, não, centenas. Ok, milhares de vezes e provavelmente hoje aplica várias das excelentes bases do nosso queridíssimo Robert C. Martin nos seus projetos pessoais e profissionais. Eu também. Posso dizer que muitos dos conceitos de código limpo fizeram e fazem total diferença na minha carreira como desenvolvedor e na qualidade do meu código.

Minhas 3 regras favoritas são:

Definir corretamente a responsabilidade do código e sua aplicabilidade. Levando em conta as regras de negócio (porque para o Business o que vale é o resultado) e as melhores práticas de estruturação.
Variáveis e funções com nomenclatura dissertativa e objetiva (acredite, você vai agradecer por isso quando for refatorar alguns anos depois).
Evite comentários em código. Se precisa comentar, é porque poderia ser mais claro (há excessões, não deveria, mas há).

Porém, estamos em 2023 e a evolução da tecnologia tem sido cada vez mais recorrente. Temos frameworks, serviços para quase todas as finalidades, plataformas de low-code, inteligência artificial e aprendizagem de máquina...poderíamos passar o dia todo aqui.
Partindo desse princípio, até onde os conceitos do Clean Code devem ser aplicados hoje em dia? E se você os utiliza, cite aqui alguns dos que fazem parte do seu flow de desenvolvimento e das estratégias do seu time. Imagine esse conteúdo sendo acessado não apenas por sêniores e plenos. Mas também por júniores e entusiastas que ainda tem dificuldade para compreender todas essas técnicas e o quanto cada regra é relevante para o mercado e para o profissional.

“Clean code is not written by following a set of rules. You don’t become a software craftsman by learning a list of heuristics. Professionalism and craftsmanship come from values that drive disciplines.”

Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship 🧙‍♂

Luk

2 anos atrás

O que eu mais utilizo é o método de extração, sempre transformando o código em métodos menores. Ajuda bastante na leitura desde que você dê bons nomes e use os parâmetros de forma consciente nos métodos, além de também contribuir para que não haja grandes blocos de indentações.

Também concordo com opinião do Tio Bob em relação aos comentários, mas gosto de deixar os métodos públicos das classes sempre documentados.

Neevs

Autor

2 anos atrás

O método da extração é lindo cara, realmente muda vidas. Tenho aplicado um processo de refatoração em alguns componentes e diminuir as responsabilidades de cada um deles está ajudando muito na reusabilidade e na manutenabilidade. Altamente recomendado!

Sobre os comentários, você está errado. Remova todos eles. 😡🤣 Brincadeira, óbvio. Sim...alguns comentários são necessários e a forma que está utilizando eles faz todo sentido. Mas eu consideraria (não sei se foi o que quis dizer, se eu estiver enganado, desculpe) deixar não em comentários no código. Mas criar uma wiki, por exemplo e agregá-los lá. Obrigado por ter comentado!

Luk

2 anos atrás

Como seria essa wiki, tens exemplos?
A forma que eu faço é esta: https://imgur.com/a/klcZsjt

O IOSNumericFieldDoneWidget, pode não estar sendo visto, mas só de por o mouse e ter acesso a essa breve documentação, já podemos ter uma noção de seu comportamento.

Neevs

Autor

2 anos atrás

Infelizmente não tenho em mãos nenhum exemplo público. Mas não é difícil explicar! É bem similar a um readme.md, porém o foco é direcionado. Num readme você aborda tudo. Os contribuidores, tecnologias, clientes...já a wiki foca em questões e/ou títulos objetivos:

"Como requisitar uma API de usuários"
"Procedure para alterar os preços de produtos sazonais"
"Regras para alteração do contexto da aplicação"
"Estruturação das tabelas de conteúdos favoritados"

Uma boa WiKi pode se tornar um guia não apenas para os atuais desenvolvedores, mas para futuras agregações no time de desenvolvimento. É praticamente um tabnews internalizado 🤓.
E claro, de acordo com os relacionamentos dos conteúdos da wiki, é possível criar wikis direcionadas, que foquem apenas em Banco de Dados, Front e Back...e por aí vai, mas claro, precisa ter controle. De nada adianta encher lá de conteúdo "fútil" como por exemplo:

"Como criar uma variável"
"Alterar padding do botão"

É muito possível que existam outros formatos. Mas hoje é este que usamos e funciona bem. Isso não exime documentações, ok? Nada anula a necessidade de uma boa documentação. Mas pesquisar num conteúdo direcionado, objetivo e personalizado (porque não são regras gerais, mas sim regras próprias para cada projeto e muitas vezes, regras de negócio). E você pode hospedar onde preferir...um documento compartilhado no OneDrive ou internamente numa cloud como Azure ou AWS.