6 minutos de leitura
Muitos desenvolvedores já ouviram falar sobre Clean Code, ou Código Limpo, e quando falamos sobre isso é comum associarmos à um código com fácil manutenção.
Mas, será que Clean Code é só sobre um código fácil de dar manutenção?
Autor(a)
Fique por dentro de conteúdos, insights e oportunidades do universo tech. Receba novidades e lançamentos direto no seu e-mail.
Se você já passou pela experiência de ter que adicionar algo relativamente simples em um código existente, e percebeu que essa "adição simples" impactaria em vários pontos do projeto, você sabe o que é um código difícil de dar manutenção. Sistemas legados não são exatamente o "sonho de um Desenvolvedor" e existe todo um traquejo para lidar com códigos de softwares assim, que podem dar muita, mas muita dor de cabeça. Mas não se preocupe, aqui está um guia para lidar com softwares legados. Tudo o que você precisa saber está aqui :)
Mas, se você nunca vivenciou isso, imagine ter que alterar um fragmento de código e essa alteração simplesmente quebrar todo o sistema. Definitivamente não seria legal.
E passar por isso faz a gente pensar que escrever um código totalmente novo é uma tarefa bem mais simples do que dar manutenção em código existente.
Mas, infelizmente, em nossas carreiras gastamos boa parte do tempo dando manutenção em código existente e, se não pensarmos direito no código que estamos escrevendo,vamos passar diversas vezes por situações semelhantes a essa.
Lembre-se sempre que todo código que escrevemos acaba se tornando um Passivo (uma dívida) para a empresa. E quanto menos nos preocuparmos com a manutenção do código maior é o valor desse Passivo.
Quando falamos de um código com fácil manutenção, estamos nos referindo à um código com baixo acoplamento, alta coesão, usando SOLID, imutabilidade (quando fizer sentido), aplicando Design Patterns, minimizando Side Effects, maximizando o uso de Funções Puras e várias outras coisas.
Tudo isso pode ser resumido em ter um bom Design de Código, uma parte muito importante em ter um código limpo.
E o que mais meu código precisa ter para ser considerado um código limpo?
Pare 1 minuto olhando para esse código e tente responder: o que ele faz?
@Service
public class MovieSessionService {
private MovieSessionRepository sessionRepository;
private UnavailabilityRepository unavailabilityRepository;
private Converter<MovieSessionDTO, MovieSession> converter;
public MovieSessionService(MovieSessionRepository sessionRepository, UnavailabilityRepository unavailabilityRepository, Converter<MovieSessionDTO, MovieSession> converter) {
.sessionRepository = sessionRepository;
.unavailabilityRepository = unavailabilityRepository;
.converter = converter;
}
Result<MovieSession> {
converter.convert(dto);
List<MovieSession> sessions = sessionRepository.listAllByTheaterId(dto.getTheaterId());
(sessions.stream().anyMatch(s -> s.getStart().equals(session.getStart()) && s.getEnd().equals(session.getEnd()))) {
Result.fail(SessionConflictException.class, session);
}
(sessions.stream().anyMatch(s -> session.getStart().isBefore(s.getStart()) || session.getStart().isAfter(s.getEnd()))) {
Result.fail(SessionConflictException.class, session);
}
List<Unavailability> unavailabilities = unavailabilityRepository.listAllByTheaterId(dto.getTheaterId());
(unavailabilities.stream().anyMatch(u -> u.getStart().equals(session.getStart()) && u.getEnd().equals(session.getEnd()))) {
Result.fail(UnavailablePeriodException.class, session);
}
(unavailabilities.stream().anyMatch(u -> session.getStart().isBefore(u.getStart()) || session.getStart().isAfter(u.getEnd()))) {
Result.fail(UnavailablePeriodException.class, session);
}
sessionRepository.save(session);
Result.success(session);
}
}
O que você achou dessa sequência de ifs ? E esse monte de expressões sendo avaliada dentro de cada if? Como poderíamos reduzir a quantidade de código duplicado ?
Perceba que fizemos um esforço tremendo para tentar entender o que esse código faz - e é possível que não tenhamos conseguido entendê-lo.
Esse código que acabei de mostrar tem a função de salvar uma sessão de cinema, desde que a sessão que estamos tentando salvar não tenha conflitos de horários com outras sessões existentes, ou com uma possível indisponibilidade na sala (por exemplo a sala estar indisponível por estar em manutenção).
Toda essa carga cognitiva que fizemos para tentar entender o código traz um cansaço físico e mental. Agora leve em consideração que passamos a maior parte do tempo lendo código.
Então, legibilidade conta muito na hora em que estamos escrevendo código.
Poderíamos refatorar o código para algo mais ou menos assim:
@Service
public class MovieSessionService {
private MovieSessionRepository sessionRepository;
UnavailabilityRepository unavailabilityRepository;
Converter<MovieSessionRequest, MovieSession> converter;
{
.sessionRepository = sessionRepository;
.unavailabilityRepository = unavailabilityRepository;
.converter = converter;
}
Result<MovieSession> {
converter.convert(movieSessionRequest);
Result<MovieSession> overlapResult = checkOverlapsWith(newMovieSession);
(overlapResult.isFail()) {
overlapResult;
}
sessionRepository.save(newMovieSession);
Result.success(newMovieSession);
}
Result<MovieSession> {
(hasOverlapsWithAnotherMovieSessionsBy(session)) {
Result.fail(SessionConflictException.class, session);
}
(hasOverlapsWithUnavailabilitiesBy(session)) {
Result.fail(SessionConflictException.class, session);
}
Result.success(session);
}
{
List<MovieSession> sessions = sessionRepository.listAllByTheater(session.getTheater());
hasOverlapsBetween(sessions, session);
}
{
List<Unavailability> unavailabilities = unavailabilityRepository.listAllByTheater(session.getTheater());
hasOverlapsBetween(unavailabilities, session);
}
{
session.getStart();
session.getEnd();
(periods.stream().anyMatch(period -> period.getStart().equals(startTime) && period.getEnd().equals(endTime))) {
;
}
periods.stream().anyMatch(period -> startTime.isBefore(period.getStart()) || startTime.isAfter(period.getEnd()));
}
}
O código agora parece um pouco mais organizado, com alguns nomes melhores para aumentar a semântica e sem boa parte da duplicidade, além de conseguirmos lê-lo de cima para baixo em um fluxo contínuo.
Podíamos continuar refatorando o código infinitamente, movendo as responsabilidades para as classes corretas e assim melhorando ainda mais o Design do Código e a manutenibilidade.
Dessa forma, temos muito menos esforço para ler e tentar entender o código.
Lembre-se: a legibilidade conta muito para um código limpo.
Porém, como podemos garantir que após essa alteração nosso código continua funcionando?
Sim, para garantir que nosso código continua funcionando precisamos escrever testes.
Testes fazem parte do jogo quando estamos desenvolvendo, e o fato de tê-los não elimina totalmente a possibilidade de termos um bug, mas minimiza bastante.
Com os testes conseguimos garantir que pelo menos os cenários previstos estão funcionando e extrapolar esses cenários é o que torna nossos testes mais eficientes.
Quanto mais níveis de testes (unitários, integração, aceitação, regressão e etc.) tivermos, mais segurança teremos na hora de aplicar uma refatoração.
A tarefa mais difícil na hora de se escrever um teste é saber o que devemos testar. E é justamente aí que temos que focar nossos esforços.
Testes são uma parte importante para todo o ciclo de vida de desenvolvimento E sim, um código limpo é um código testável.
Um código limpo é a composição de diversas características, como:
De uma forma bem resumida, um código limpo é um código testável, fácil de manter e de ler.
Na Alura, nós criamos uma formação em Orientação à Objetos pensando justamente nessas boas práticas.
Avalie este artigo
Persistência com Kotlin utilizando JDBC
Ler mais
Ambientes virtuais em Python
Ler mais
Implementando comparação profunda em JS de forma simples
Ler mais