Depois de uma pausa, vamos voltar a falar de temas de Desenvolvimento de Sistemas, uma das áreas mais técnicas de Tecnologia da Informação (TI). Como você já deve imaginar, de acordo com o título do artigo, o tema escolhido para a retomada é Clean Code.
Embora Clean Code não seja efetivamente uma novidade no mundo da tecnologia, as bancas ainda não estão cobrando o assunto com grande intensidade. O que isso significa então? Não devo ler o artigo?
Claro que não, concurseiro. É justamente o contrário. Você deve conhecer o assunto porque o seu concorrente está preocupado com outras coisas. Aliás, sabia que Clean Code foi exigido na primeira prova prática de TI? Sendo assim, fique esperto e veja o que teremos pela frente:
O artigo é direcionado aos concurseiros da área de TI. A fim de entender os conceitos, é importante que você tenha noções de programação. Contudo, se ainda não tiver, recomendamos que busque o material do Estratégia e volte ao artigo quanto estiver preparado.
Mais uma vez, o artigo foi elaborado cuidadosamente em formato reduzido, a fim de que você tenha bastante conteúdo de Clean Code com pouquíssimo tempo de leitura. Bom, chega de papo, porque é hora de começar.
Tempo de leitura aproximada: 5 a 10 minutos
Assim como o próprio nome diz, Clean Code é um conjunto de boas práticas de desenvolvimento para escrever um código limpo. Em outras palavras, o programa precisa ser simples, legível e fácil de dar manutenção por outros desenvolvedores.
Momento Curiosidade: A teoria é inspirada no livro de Robert Martin, denominado Código Limpo: Habilidades Práticas do Agile Software (Clean Code: A Handbook of Agile Software Craftsmanship, na versão original). O livro é clássico, um best-seller em vários países, incluindo EUA e Brasil.
No livro, as boas práticas são apresentadas sob a forma de regras. Embora consideramos que a publicação não seja muito clara nesse aspecto, é possível agrupar as regras em categorias. Agora a pergunta que não quer calar: é necessário saber tudo para a prova?
Concurseiro, a resposta é não. De fato, nem tudo cai nas provas. O universo dos concursos explora Clean Code de forma mais reduzida, sem categorização. Fique calmo.
Porém, como diz o ditado, o seguro morreu de velho. Optamos por trazer uma listagem de regras, para você ter ciência dos tópicos e não ser surpreendido na prova, mas vamos aprofundar apenas as regras que as bancas mais cobram. Fique conosco, pois vamos explicar ao longo do artigo.
Primeiramente, as regras de Clean Code são agrupadas em regras gerais, regras de design, regras de entendimento, regras de nomenclatura, regras de funções, regras de comentários, regras de estrutura de código-fonte, regras de objetos e estruturas, regras de testes e regras de code smells.
Você Sabia? Talvez o conceito de code smells seja novo para a maioria dos leitores. De forma simples, code smells são problemas potenciais no software que prejudicam a aplicação das regras do Clean Code.
Veja com atenção a lista abaixo, pois ela é um compilado das principais regras do Clean Code. Olhe mais atentamente ainda as marcadas com cor amarela. Nós vamos explicar mais a frente o porquê da marcação.
| Grupo | Regra |
|---|---|
| Regras Gerais | Siga as convenções padrões. |
| KISS – Keep It Simple Stupid (mantenha isso estupidamente simples). | |
| DRY – Don’t Repeat Yourself (não repita/duplique informações). | |
| Regra do escoteiro (mantenha o acampamento mais limpo do que quando você o encontrou). | |
| Sempre encontre a causa-raiz. | |
| Regras de Design | Mantenha dados de configuração em altos níveis. |
| Prefira polimorfismo a if/else ou switch/case. | |
| Separe código multi-threading. | |
| Utilize async como sufixo. | |
| Evite o excesso de configurações. | |
| Use injeção de dependência. | |
| Lei de Demeter (uma classe só deve ter ciência de suas dependências diretas). | |
| Regras de Entendimento | Seja consistente. |
| Utilize variáveis explicativas. | |
| Encapsule condições de contorno. | |
| Prefira objetos de valor a tipos primitivos. | |
| Evite dependências lógicas. | |
| Evite condicionais negativas. | |
| Regras de Nomenclatura | Escolha nomes descritivos e não ambíguos. |
| Faça distinções significativas. | |
| Utilize nomes pronunciáveis. | |
| Utilize nomes que permitam busca. | |
| Substitua números mágicos por constantes nomeadas. | |
| Evite encoding. | |
| Regras de Funções | Mantenha o escopo pequeno. |
| Faça uma coisa só. | |
| Utilize nomes descritivos. | |
| Prefira poucos parâmetros. | |
| Evite efeitos colaterais. | |
| Não utilize parâmetros de flag para decisões. |
| Grupo | Regra |
|---|---|
| Regras de Comentários | Sempre tente se explicar no código. |
| Não seja redundante. | |
| Nunca feche os comentários. | |
| Não comente código que não será mais usado. | |
| Utilize para explicação da intenção. | |
| Utilize para clarificar o código. | |
| Use para alertar consequências. | |
| Regras de Estrutura de Código-Fonte | Separe os conceitos verticalmente. |
| Declare variáveis mais próximas do seu uso. | |
| Funções dependentes devem estar próximas. | |
| Funções similares devem estar próximas. | |
| Declare as funções de cima para baixo. | |
| Mantenha curtas linhas. | |
| Não utilize alinhamento horizontal. | |
| Utilize espaço em branco para associar e desassociar, dependendo da relação. | |
| Não quebre a indentação. | |
| Regras de Objetos e Estruturas | Esconda estruturas internas. |
| Prefira estruturas de dados. | |
| Evite estruturas híbridas (metade objeto e metade dados). | |
| Mantenha o escopo pequeno. | |
| Faça uma coisa só. | |
| Considere um número pequeno de variáveis de instância. | |
| As classes base não devem saber nada sobre suas derivadas. | |
| É melhor ter muitos métodos com sobrecarga do que tomadas de decisão em métodos (seleções de comportamento). | |
| Prefira métodos não estáticos a estáticos. | |
| Regras de Testes | Utilize um assert por teste. |
| FIRST – Fast, Independent, Repeatable, Self-Validating and Timely (testes devem ser rápidos, independentes, repetíveis, autovalidados e oportunos). | |
| Regras de Code Smells | Característica da rigidez (software difícil de ser modificado). |
| Característica da fragilidade (uma mudança impacta em vários pontos). | |
| Característica de imobilidade (reuso envolve alto risco e esforço). | |
| Complexidade desnecessária. | |
| Repetição desnecessária. | |
| Característica da opacidade (código difícil de entender). |
Para este artigo, fizemos uma pesquisa das regras comuns nas questões dos últimos anos sobre Clean Code. As 14 regras destacadas de amarelo são as que mais apareceram nas questões pesquisadas (vamos denominá-las regras quentes, para que você fique íntimo delas).
Agora nós vamos aprofundar as regras quentes do Clean Code, pois isso é o que interessa para acertar as questões. Respeitando o nosso compromisso de fazer um artigo rápido para você, preparamos dois resumos esquematizados com cada uma delas.
Sendo assim, recomendamos que você estude a lista de regras, mas foque nas explicações aprofundadas sobre as regras quentes que virão a seguir. Bom, vamos deixá-lo agora sozinho por alguns instantes com os resumos e a gente volta a conversar na conclusão.
Em suma, o artigo apresentou um resumo dos principais aspectos do Clean Code que são cobrados nas provas de concurso público. Logo após a leitura desta publicação, você pode aprofundar o conteúdo com o material do Estratégia Concursos e fazer muitas questões.
Lembramos que o Estratégia oferece cursos em pdf, videoaulas e áudios para você ouvir onde quiser. Há diversas formas de avançar na sua preparação. Descubra tudo no link http://www.estrategiaconcursos.com.br/cursos/.
Porém, nem só de conteúdo vive o concurseiro. Você precisa fazer questões a fim de treinar o aprendizado e medir o seu desempenho. O acesso ao Sistema de Questões do Estratégia é feito pelo link: https://concursos.estrategia.com/.
Por fim, a nossa última mensagem de hoje é: não desista! Dê o seu melhor e busque o autocontrole, porque a aprovação para o concurso que você sonha chegará no momento certo. Você é um vencedor!
Bons estudos e até a próxima!
Cristiane Selem Ferreira Neves é Bacharel em Ciência da Computação e Mestre em Sistemas de Informação pela Universidade Federal do Rio de Janeiro (UFRJ), além de possuir a certificação Project Management Professional pelo Project Management Institute (PMI). Já foi aprovada nos seguintes concursos: ITERJ (2012), DATAPREV (2012), VALEC (2012), Rioprevidência (2012/2013), TJ-RJ (2022), TCE-RJ (2022) e CGE-SC (2022/2023). Atualmente exerce o cargo efetivo de Auditora de Controle Externo – Tecnologia da Informação no TCE-RJ, além de ser produtora de conteúdo dos Blogs do Estratégia Concursos, OAB e Carreiras Jurídicas.