Atualmente, o mercado exige que os desenvolvedores não “programem” simplesmente. Muitas empresas desejam profissionais que possuem domínio de boas práticas e noções de arquitetura – o famoso “código limpo”. Muitas vezes, podemos até pensar: “não… as empresas desejam apenas que o software funcione”. A curto prazo pode até ser real esta afirmação, mas quando falamos sobre médio e longo prazo, que é quando certos problemas começam a aparecer, é que os débitos técnicos (os trechos de código que foram mal escritos ou funcionalidades que não foram implementadas da maneira correta) voltam para nos assombrar.
Curso PHP - Orientação a Objetos - Parte 1
Conhecer o curso
O famoso “código limpo” (ou “clean code”) é um estilo de desenvolvimento que tem como foco a escrita de código claro, conciso e de fácil manutenção posterior. Profissionais que se atentam a essas práticas costumam ser vistos de maneira diferente quando seu código é analisado em uma entrevista de emprego. Ter o código limpo e bem escrito facilita a leitura e é importante para o aumento da qualidade do software. Se você não se preocupa com isso, fatalmente, até mesmo em um curto prazo, você mesmo pode não entender seu próprio código! A situação piora ainda mais quando um desenvolvedor vai tentar entender o código de outra pessoa, ainda mais se for em uma empresa que tenha alta rotatividade na equipe (o que é uma situação bem comum nas empresas de software aqui no Brasil). As consequências desse tipo de situação são claras: perde-se muito tempo com a manutenção do software, gerando muitas vezes até mesmo situações de retrabalho.
A adoção de práticas de “clean code” acaba auxiliando a resolver estes pontos. Porém, ainda podemos obter outros benefícios através da adoção destas práticas: mais do que garantir a qualidade do código e do software, a adoção de práticas de “código limpo” trazem também maior produtividade, por consequência direta ao fato de que um software com qualidade exige menos processos de manutenção e, quando esta é necessária, o esforço a ser realizado acaba se tornando muito menor do que o usual. Abaixo, descrevemos alguns tópicos comuns no que diz respeito ao “clean code”.
Escreva métodos curtos
Um método deve ser escrito de uma forma que qualquer pessoa que “bata o olho” entenda o que ele faz. Métodos demasiadamente extensos certamente não ajudam neste ponto. Alguns livros de arquitetura de software pregam que um método deve ter no máximo 15 linhas, embora até 25 linhas seja tolerável, caso seja muito necessário.
Utilize nomes de variáveis e métodos claros e bem definidos
Os nomes de variáveis e métodos devem ser precisos, claros e diretos, passando diretamente a ideia do que ele faz. Não tenha medo de escrever um nome grande caso seja necessário. Um nome bem descritivo irá possibilitar uma melhor compreensão e, posteriormente, uma melhor manutenção do código. Antes termos uma variável chamada valorTotalNotaFiscal do que valTot. A grande maioria das ferramentas de desenvolvimento hoje em dia oferecem a funcionalidade de autocomplete, o que invalida a justificativa de que “perdemos tempo ao digitar nomes de variáveis e métodos muito grandes” para não utilizarmos nomes mais diretos para nossas estruturas de código. Vale lembrar que nomes de métodos sempre deve ter nomes de verbos, já que são criados para executar algum procedimento. No caso de classes, deve-se usar substantivos no singular.
Separação clara de responsabilidades entre métodos e classes (Single Responsability Principle - SRP)
Um método deve desempenhar apenas uma tarefa. O Single Responsability Principle, ou Princípio da Responsabilidade Única, é um de cinco princípios para utilização de boas práticas de codificação chamados S.O.L.I.D. Este princípio define que cada estrutura de código, seja uma classe ou um método, deve possuir apenas uma única responsabilidade, ou seja: cada estrutura deve fazer uma única coisa. Tome cuidado também com a justificativa de uma classe. Os métodos existentes de uma classe devem estar alinhados com sua definição. Não adianta colocarmos um método chamado acelerar() dentro de uma classe chamada Mesa, sendo que quem acelera é um Carro.
Curso PHP - Fundamentos
Conhecer o cursoCuidado com a quantidade de parâmetros que os métodos recebem!
Quanto menos parâmetros um método receber, mais legível ele será. Sempre garanta que os parâmetros que um método recebe são de fato necessários. Quando uma quantidade muito grande de parâmetros for necessária, tente utilizar design patterns como o builder ou, pelo menos, agrupar esta quantidade de parâmetros em uma especificação de objeto a ser repassado como parâmetro único para o método.
Cuidado com o overpattern!
Design patterns são legais, desde que utilizados da maneira correta. Quando os design patterns são aplicados da maneira incorreta ou utilizados em conjunto de maneira complicada por pura “satisfação técnica pessoal”, estes acabam mais atrapalhando do que ajudando, já que a utilização de design patterns acaba por trazer uma certa complexidade ao código. Por isso, para evitarmos futuros débitos técnicos, é essencial que essa complexidade oriunda com a aplicação de um ou mais patterns seja devidamente justificada.
Para avaliar se você deve aplicar ou não um conjunto de design patterns, lembre-se sempre de um princípio chamado K.I.S.S. – Keep It Short and Simple, ou Mantenha Isso Pequeno e Simples (ainda existem algumas variações sob essa sigla). Sempre escreva suas estruturas de código da maneira mais direta e simples, aplicando simplesmente os patterns que são de fato necessários para a situação. Não crie débitos técnicos desnecessários por sofrer antecipadamente: escreva trechos de código claros e concisos que, quando necessário, possam ser modificados para estruturas e patterns mais complexos de maneira tranquila.
Entre um desenvolvedor que sai aplicando técnicas como DDD, CQRS, Event Sourcing e uma variedade de patterns gigantesca para um simples cadastro de uma entidade que nem tem relacionamentos e um desenvolvedor que utiliza patterns mais simples como o Repository e o Service Pattern, pode ter certeza que o mercado de maneira geral irá dar a preferência para o segundo desenvolvedor. E isso não o define com menos habilidades técnicas que o primeiro desenvolvedor – muito pelo contrário: o segundo desenvolvedor provavelmente possui um nível de maturidade maior que o permite calcular bem os benefícios de cada abordagem em diferentes situações.
Aconselho a leitura do nosso artigo sobre padrões de projeto que podem ajudar na criação de seu código.
