Código Limpo por Robert C. Martin

O que é Código Limpo?

Código limpo refere-se ao código fácil de ler, entender e manter. Ele enfatiza não apenas a função do código, mas sua estrutura e clareza. Robert C. Martin afirma que "o Clean Code pode ser lido e aprimorado por um desenvolvedor que não seja seu criador". Esse princípio incentiva a escrita de código de uma forma intuitiva para os outros.

A importância do código limpo

Escrever código limpo leva a uma melhor manutenção e menos bugs. Ele promove a colaboração e reduz a curva de aprendizado para novos desenvolvedores. Ao se concentrar no código limpo, as equipes podem:

• Aumente a produtividade
• Reduza a dívida técnica
• Facilite a integração mais rápida

Nomes significativos

A escolha de nomes apropriados para variáveis, funções e classes é fundamental. Robert C. Martin enfatiza que os nomes devem ser descritivos e reveladores de intenção. Por exemplo:

• Use calculateTotalPrice em vez de ctp.
• Uma classe chamada Customer é melhor do que uma classe chamada C.

As funções devem fazer uma coisa

As funções devem ter uma única responsabilidade. Robert C. Martin aconselha que uma função deve ter um motivo para mudar, tornando-a mais fácil de entender e testar. Procure funções que sejam:

• Curto
• Focado em uma tarefa
• Encapsular lógica

Comente criteriosamente

Embora os comentários possam esclarecer o código, Robert C. Martin argumenta que o código deve ser autoexplicativo. Algumas dicas para comentários eficazes incluem:

• Evite comentários redundantes que afirmem o óbvio.
• Use comentários para explicar por que algo é feito, não o que é feito.
• Mantenha os comentários atualizados.

Desenvolvimento orientado a testes (TDD)

O Desenvolvimento Orientado a Testes incentiva a escrita de testes antes do código correspondente. Essa prática garante que seu código esteja funcionando conforme o esperado. De acordo com Martin, isso leva a:

• Melhor design de código
• Menos duplicação
• Confiança nas alterações de código

Refatorar com frequência

Revisitar e melhorar regularmente o código é vital para manter a limpeza. Robert C. Martin sugere que os desenvolvedores devem estar sempre em um estado de refatoração, aprimorando a estrutura e a legibilidade. Isso pode ser feito por:

• Removendo código duplicado
• Simplificando a lógica complexa
• Reorganizando o código para maior clareza

A regra dos escoteiros

Inspirada na frase "Deixe o acampamento mais limpo do que você o encontrou", a Regra dos Escoteiros promove a ideia de melhorar a base de código a cada mudança. Robert C. Martin destaca que toda vez que você toca em um pedaço de código, você deve se esforçar para torná-lo mais limpo.

Nomes reveladores de intenção

Os nomes devem transmitir a intenção da variável, função ou classe. Por exemplo, uma variável chamada customerAge indica claramente sua finalidade, enquanto c não. Quando um nome revela a intenção, minimiza a necessidade de comentários.

Evite a desinformação

Os nomes não devem induzir em erro. Por exemplo, nomear dados variáveis pode ser enganoso se ele realmente contiver um tipo específico de dados. Em vez disso, use nomes como customerData ou orderDetails para representar com precisão o conteúdo.

Faça distinções significativas

É crucial usar nomes que diferenciem conceitos semelhantes. Por exemplo, use currentUser e previousUser em vez de user1 e user2. Essa abordagem evita confusão e melhora a legibilidade do código.

Use nomes pronunciáveis

Os nomes devem ser fáceis de ler e pronunciar. Evite siglas enigmáticas como H2O ou construções semelhantes que exijam ginástica mental. Use nomes descritivos, como maximumHeight , para facilitar a comunicação sobre o código.

Usar nomes pesquisáveis

Os nomes devem ser familiares o suficiente para serem facilmente pesquisáveis. Por exemplo, em vez de usar nomes como x ou y, use índice ou posição. Isso torna mais fácil para alguém localizar elementos específicos no código.

Evite codificações

Não inclua informações de tipo ou outras codificações nos nomes. Por exemplo, uma variável chamada strUserName é desnecessariamente detalhada e menos significativa do que simplesmente usar userName. Isso mantém os nomes limpos e focados em seu propósito.

As funções devem ser pequenas

As funções devem ser pequenas e focadas em uma única tarefa. Uma diretriz comum é garantir que uma função faça uma coisa e a faça bem. Isso torna a função mais fácil de entender, testar e reutilizar.

Nomes descritivos

Use nomes descritivos para funções. Um bom nome de função deve indicar o que a função faz, tornando mais fácil para outras pessoas (e para você) entender o código posteriormente. Evite nomes genéricos e, em vez disso, favoreça a clareza.

Evite efeitos colaterais

As funções devem evitar efeitos colaterais. Isso significa que eles não devem alterar o estado das variáveis globais ou alterar os argumentos de entrada. Os efeitos colaterais podem levar a um código difícil de depurar e entender.

Listas de argumentos consistentes

As funções devem ter um número consistente de argumentos. Se uma função geralmente requer números diferentes de argumentos, considere se ela pode ser dividida em funções menores ou se estruturas de dados adicionais são necessárias.

Tratamento de exceções sobre códigos de erro

Prefira usar exceções para lidar com erros em vez de retornar códigos de erro. As exceções fornecem uma maneira mais clara de indicar problemas e separar o tratamento de erros do fluxo de controle regular, levando a um código mais limpo e sustentável.

Objetivo dos comentários

Comentários bons vs ruins

• Explique por que uma decisão foi tomada.
• Esclareça algoritmos complexos.
• Indique as limitações ou restrições de uma solução.

• Comentários redundantes que repetem o código.
• Comentários desatualizados que não refletem mais o código.
• Comentários enganosos que podem confundir os leitores.

Práticas recomendadas de comentários

1. Use comentários com moderação e somente quando necessário.
2. Mantenha os comentários atualizados com as alterações no código.
3. Evite usar comentários como muleta para código confuso.
4. Escreva comentários que expliquem por que e não como.
5. Considere o público: Escreva comentários para futuros mantenedores.

Evitando código comentado

Entendendo a intenção

Legibilidade do código

Indentação

Comprimento da linha

Alinhamento horizontal

Alinhamento vertical

Comentando

Uso de espaço em branco

Prevenção de erros

Entendendo o encapsulamento

Os objetos ocultam seus dados por meio do encapsulamento, que é um princípio fundamental da Programação Orientada a Objetos (OOP). Ao encapsular dados, os objetos podem controlar o acesso aos seus estados internos e garantir que apenas operações válidas sejam executadas. Esse controle ajuda a manter a integridade dos dados e fornece uma interface clara para interagir com objetos.

Exposição de dados em estruturas

Em contraste com os objetos, as estruturas de dados expõem seus dados diretamente. Esse acesso aberto permite maior flexibilidade e facilidade de uso, mas pode levar a problemas se os dados forem modificados de forma inadequada. Ao projetar estruturas de dados, é vital considerar as implicações da exposição de dados internos e garantir que os usuários estejam cientes dos riscos e responsabilidades potenciais.

Impacto no design da classe

A distinção entre objetos e estruturas de dados afeta significativamente o design de classes e métodos. Ao projetar uma classe como um objeto, concentre-se no encapsulamento e na ocultação de dados. Por outro lado, ao trabalhar com estruturas de dados, priorize o desempenho e a simplicidade, bem como a forma como os dados serão acessados e manipulados.

Práticas recomendadas para objetos

Ao criar objetos, considere as seguintes práticas recomendadas:

• Encapsular comportamento: Em vez de expor dados diretamente, forneça métodos que manipulem esses dados de maneiras controladas.
• Mantenha os dados privados: Use campos privados e exponha apenas o que é necessário por meio de métodos públicos.
• Design para mudança: Crie interfaces que permitam modificações fáceis sem afetar o código externo que usa seu objeto.

Práticas recomendadas para estruturas de dados

Para projetar estruturas de dados eficazes, siga estas diretrizes:

• Minimize a exposição: Exponha apenas os dados necessários para os usuários e mantenha todo o resto como interno.
• Considere o desempenho: Otimize para as operações mais comuns e entenda as compensações de várias estruturas de dados.
• Uso do documento: Forneça documentação clara sobre como a estrutura de dados deve ser usada e quais invariantes são mantidas.

Noções básicas de tratamento de erros

O tratamento de erros é um aspecto crucial da escrita de código limpo. Ele garante que seu aplicativo possa lidar normalmente com situações inesperadas. Como enfatiza Robert C. Martin, a essência do tratamento limpo de erros é não permitir que o tratamento de erros obscureça a lógica de negócios.

Exceções vs. códigos de retorno

Prefira usar exceções em vez de códigos de retorno para tratamento de erros. As exceções fornecem uma maneira mais clara de gerenciar erros sem sobrecarregar a lógica de negócios. Usando exceções, você pode gerenciar o fluxo de controle de forma mais elegante e seu código se torna mais fácil de ler.

Exceções não verificadas

Quando possível, use exceções não verificadas para tratamento de erros. Exceções não verificadas não exigem que o chamador as manipule, reduzindo o código clichê. Isso permite que os desenvolvedores se concentrem na lógica de negócios essencial, em vez de no tratamento extensivo de erros.

Limpar hierarquias de exceção

Defina uma hierarquia de exceção clara em sua base de código. Isso torna mais fácil para os desenvolvedores entenderem os tipos de exceções que podem ser lançadas e o que elas representam. Uma hierarquia bem estruturada também facilita um melhor tratamento de exceções em métodos de nível superior.

Erros de registro

Ao lidar com erros, é vital registrar os erros adequadamente. O registro em log fornece insights sobre problemas e pode ajudar nos processos de depuração. Certifique-se de que seu mecanismo de log capture informações relevantes para ajudar a diagnosticar problemas sem sobrecarregar os logs com ruído.

Tratamento de erros no nível certo

Certifique-se de lidar com erros no nível apropriado de seu aplicativo. Em geral, você deve fazer isso o mais próximo possível da origem do erro, o que mantém as camadas superiores do aplicativo limpas e focadas em suas responsabilidades principais.

Limpar recursos

Sempre verifique se os recursos são limpos corretamente durante o tratamento de erros. Utilize o bloco finally para liberar quaisquer recursos, como identificadores de arquivo ou conexões de banco de dados, para evitar vazamentos de recursos em seu aplicativo.

Entendendo os limites

No domínio do desenvolvimento de software, os limites são críticos para gerenciar a complexidade. Os limites separam as preocupações, permitindo que os componentes interajam sem expor detalhes internos. Ao estabelecer limites claros, promovemos a modularidade e aprimoramos a manutenção do código.

Interfaces arquitetonicamente significativas

Para gerenciar limites com eficiência, use interfaces arquitetonicamente significativas. Essas interfaces encapsulam detalhes de implementação e fornecem um contrato claro para interação. Isso ajuda a evitar o acoplamento rígido entre os componentes, tornando os sistemas mais fáceis de entender e modificar.

Projetando para teste

Projete suas interfaces não apenas para funcionalidade, mas para testabilidade. Ao criar limites fáceis de simular ou fazer stub, você pode escrever testes focados que validam o comportamento sem depender de integrações complexas. Essa abordagem reduz a carga de testes e ajuda a detectar problemas antecipadamente.

Encapsulamento de detalhes

O encapsulamento é vital nos limites. Ao ocultar os detalhes de implementação atrás das interfaces, você impede que os clientes façam suposições sobre o funcionamento interno de um componente. Isso garante que as alterações na implementação não se espalhem inesperadamente pelo sistema.

O papel do código de terceiros

A integração de código de terceiros apresenta desafios específicos. Trate essas integrações como limites. Envolver o código de terceiros com suas próprias interfaces permite que você gerencie seu impacto, garantindo que alterações ou falhas em sistemas de terceiros não comprometam a integridade do seu aplicativo.

Práticas recomendadas para gerenciar limites

• Mantenha as interfaces pequenas e concisas.
• Evite expor quaisquer detalhes além do contrato necessário.
• Use nomes significativos que transmitam intenção para suas interfaces.
• O documento interage claramente para ajudar na compreensão.

A implementação dessas melhores práticas levará a um melhor gerenciamento de fronteiras e sistemas mais robustos.

Importância dos testes unitários

Os testes de unidade são parte integrante do código limpo. Eles desempenham um papel crítico para garantir que o software funcione corretamente e atenda às suas especificações de design. Como afirma Robert C. Martin, "os testes de unidade são uma rede de segurança, dando ao programador a liberdade de alterar seu código". Cada teste de unidade atua como uma verificação da exatidão do código, o que ajuda a evitar regressões à medida que a base de código evolui.

Características de bons testes de unidade

Bons testes de unidade devem possuir várias características principais:

• Rápido: Os testes devem ser executados rapidamente para incentivar a execução frequente.
• Independente: Cada teste deve operar isoladamente, garantindo que as falhas em um teste não afetem outros.
• Repetível: Os testes devem produzir o mesmo resultado quando executados no mesmo ambiente.
• Auto-validação: Os testes precisam ter um resultado claro de aprovação ou reprovação.
• Oportuno: Os testes devem ser escritos ao mesmo tempo que o código que eles validam.

Escrevendo testes de unidade eficazes

Ao escrever testes de unidade, é importante ter em mente as seguintes dicas:

1. Comece pequeno: Comece com testes simples e aumente a complexidade gradualmente.
2. Use nomes descritivos: Testes de nome claramente para transmitir seu propósito.
3. Evite dependências: Simular dependências para garantir que os testes permaneçam independentes.
4. Verifique os casos extremos: Inclua testes para possíveis casos extremos para reforçar a confiabilidade.
5. Refatore regularmente: Certifique-se de que os testes permaneçam limpos e compreensíveis, assim como o código de produção.

Manutenção de testes unitários

Manter testes de unidade é tão crucial quanto criá-los. À medida que os recursos evoluem, seus testes também devem evoluir. Revisar e atualizar regularmente os testes ajuda a:

• Garantindo a relevância: Os testes precisam estar alinhados com a lógica de negócios atual.
• Detecção de testes obsoletos: Remova os testes que não se aplicam mais.
• Melhorando a legibilidade: Refatore testes para maior clareza e facilidade de compreensão.
• Integrando feedback: Adapte os testes com base nas informações da equipe e nos resultados da execução de testes.

Turmas pequenas e coesas

As turmas devem ser pequenas e altamente coesas. Quando uma turma é muito grande, geralmente indica que ela está tentando fazer muito e viola o Princípio de Responsabilidade Única (SRP). Uma classe deve se concentrar em um aspecto da funcionalidade do aplicativo, facilitando a manutenção e a adaptação à medida que os requisitos mudam.

Princípio de Responsabilidade Única

De acordo com Robert C. Martin, uma classe deve ter um motivo para mudar. Isso significa que, se você estiver modificando uma classe por vários motivos, pode ser um sinal de que a classe está fazendo demais. Divida-o em turmas menores, cada uma com uma única responsabilidade. Essa simplificação leva a um código mais limpo e compreensível.

Organizando-se para a mudança

As aulas devem ser organizadas de forma a antecipar as mudanças. A intenção é minimizar o impacto das mudanças agrupando comportamentos e dados relacionados. Isso significa criar interfaces e classes abstratas quando apropriado para garantir que as implementações concretas possam evoluir sem interromper o restante do sistema.

Detalhes de encapsulamento

O encapsulamento é fundamental para manter os componentes internos de uma classe ocultos do lado de fora. Usando métodos privados, uma classe pode proteger seu estado interno e comportamento de interações não intencionais. Essa separação permite que os desenvolvedores alterem a implementação sem afetar outras partes do aplicativo, promovendo flexibilidade e capacidade de manutenção.

Nomenclatura de método

Ao definir métodos dentro de uma classe, procure uma nomenclatura descritiva que expresse claramente seu propósito. De acordo com o Código Limpo, os métodos devem dizer o que fazem, não como o fazem. Essa prática melhora a legibilidade e torna mais fácil para futuros desenvolvedores entenderem o código sem precisar se aprofundar nos detalhes da implementação.

Cartões de Colaborador de Responsabilidade de Classe (CRC)

O uso de cartões CRC pode ajudar a entender a interação entre as classes. Um cartão CRC define a responsabilidade de uma classe e seus colaboradores. Isso pode fornecer informações sobre o papel da classe no sistema e ajuda a identificar como agrupar responsabilidades relacionadas com eficiência. É uma técnica útil para manter as aulas focadas e coesas.

Entendendo os sistemas

Um sistema é um conjunto inter-relacionado de componentes que trabalham juntos para cumprir um objetivo comum. Em Código Limpo, Robert C. Martin enfatiza que é crucial manter nossos sistemas simples e gerenciáveis. A complexidade do código pode levar a problemas e complicações durante a manutenção.

Projetando sistemas com TDD

O TDD (Test-Driven Development) é uma prática fundamental recomendada por Martin ao projetar sistemas. Envolve escrever testes antes de escrever o código em si. Essa abordagem ajuda a garantir que o código seja testável e sustentável.

• Escreva um teste que falhe inicialmente.
• Escreva o código mais simples para passar no teste.
• Refatore o código, garantindo que os testes ainda sejam aprovados.

Arquitetura do sistema Keeeping limpa

A arquitetura do sistema limpo é vital para a sustentabilidade a longo prazo. Martin aconselha manter a estrutura clara e organizada, onde os componentes sejam facilmente compreendidos. Ele afirma: 'Um sistema é tão bom quanto sua estrutura'. Isso enfatiza a importância de uma base sólida.

Separando a construção do uso

No Clean Code, é importante separar a construção de um sistema de seu uso. Essa separação permite um código mais flexível, que pode se adaptar ao longo do tempo. Ao criar interfaces e abstrações, os desenvolvedores podem alterar a implementação de construções sem afetar seu uso.

Implementando a injeção de dependência

A Injeção de Dependência (DI) é um padrão de design defendido por Martin para aumentar a flexibilidade nos sistemas. A DI envolve fornecer dependências às classes em vez de permitir que elas criem suas próprias. Essa abordagem promove o acoplamento flexível, tornando o sistema mais fácil de gerenciar, testar e estender.

Dicas e truques para o design do sistema

Aqui estão algumas dicas e truques a serem lembrados ao projetar sistemas:

• Comece com requisitos simples e claros.
• Garanta o design modular para facilitar a mudança.
• Documente os componentes do sistema e suas interações.
• Revise e refatore regularmente para maior clareza.

Seguir essas diretrizes ajudará na criação de sistemas robustos e sustentáveis.

Entendendo a emergência

Quatro regras de design simples

• Execute todos os testes: Certifique-se de que seu código passe em todos os testes antes de fazer mais alterações.
• Não contém duplicação: Procure evitar a duplicação de código, pois isso dificulta o surgimento de clareza.
• Expresse a intenção: O código deve expressar claramente seu propósito, o que facilita a extensão e a modificação.
• Minimize o número de classes e métodos: Mantenha seu design simples e evite complicá-lo demais com componentes excessivos.

Abraçando a emergência no design

Exemplo de emergência no mundo real

Noções básicas sobre simultaneidade

Simultaneidade refere-se à capacidade de um sistema de lidar com várias tarefas ao mesmo tempo. No entanto, ele introduz complexidade adicional ao seu código, tornando-o fundamental para abordar com cautela. Como enfatiza Robert C. Martin, 'A simultaneidade introduz complexidade adicional'. Portanto, considere usar threads com moderação para evitar possíveis armadilhas.

Preservar invariantes

Ao lidar com código simultâneo, é vital preservar invariáveis — condições que se mantêm verdadeiras durante a execução de um programa. Martin aconselha a 'preservar invariantes' para garantir que seu sistema permaneça em um estado válido. Isso pode ser desafiador em ambientes multithread e requer um design cuidadoso para manter a consistência do estado.

Regiões sincronizadas

Manter as regiões sincronizadas pequenas é crucial na programação simultânea. Robert C. Martin observa: 'mantenha as regiões sincronizadas pequenas'. Essa prática minimiza o tempo que vários threads gastam aguardando bloqueios, melhorando assim o desempenho e reduzindo a chance de deadlocks.

Protegendo recursos

Em um ambiente simultâneo, proteger os recursos contra acesso simultâneo é essencial para manter a integridade dos dados. Martin aconselha a 'proteger os recursos' de forma eficaz. Isso pode envolver o uso de mutexes, bloqueios ou outros mecanismos de sincronização para garantir que apenas um thread possa acessar um recurso por vez, evitando assim condições de corrida.

Entendendo o refinamento sucessivo

A importância da legibilidade

Etapas do processo de refinamento

1. Comece com uma implementação básica.
2. Identifique áreas que precisam ser melhoradas.
3. Refatorar o código aprimorando sua estrutura e clareza.
4. Teste o código modificado para garantir que a funcionalidade permaneça intacta.
5. Itere o processo, refinando ainda mais conforme necessário.

Técnicas de refatoração

• Método de extração: Mova partes do código para novos métodos para melhorar a clareza.
• Renomear variáveis: Escolha nomes descritivos que transmitam melhor a finalidade dos dados.
• Remover código morto: Elimine segmentos de código que nunca são executados.

Mentalidade de Melhoria Contínua

Noções básicas sobre executores de teste

O coração do JUnit é seu executor de testes, que é responsável pela execução dos testes. Um executor de teste interpreta as anotações em classes e métodos de teste, iniciando os testes de maneira estruturada. Esse processo de execução é crucial, pois permite que os desenvolvedores criem testes repetíveis e previsíveis. O JUnit fornece vários executores integrados, cada um com funcionalidades exclusivas. Corredores personalizados também podem ser criados para atender a necessidades específicas de teste.

Luminárias e sua importância

Os fixtures desempenham um papel fundamental no teste JUnit, pois configuram o contexto necessário antes da execução de um teste. Um fixture normalmente consiste em código de inicialização e um processo de desmontagem. Ao usar acessórios, os testes podem ser executados isoladamente, garantindo que cada um seja preparado em um estado limpo. Como Robert C. Martin aconselha: "A melhor maneira de testar é garantir que todos os testes sejam executados independentemente uns dos outros". Essa filosofia reforça a eficácia dos acessórios na manutenção da integridade do teste.

Ciclo de vida da execução do teste

O JUnit segue um ciclo de vida definido para a execução do teste, que consiste em vários estágios:

1. Inicialização: A classe de teste é instanciada.
2. Configuração: O aparelho é preparado, executando qualquer código de configuração.
3. Execução do teste: Os métodos de teste reais são executados.
4. Subdivisão: Todas as operações de limpeza são executadas.
5. Relatório de resultados: Os resultados são capturados e relatados.

Entender esse ciclo de vida permite que os desenvolvedores escrevam testes mais eficazes e organizados que aderem aos princípios do código limpo.

Escrevendo testes eficazes

Ao criar testes com o JUnit, siga as práticas recomendadas para aumentar a clareza e a capacidade de manutenção. Os testes eficazes são:

• Descritivo: Use nomes significativos para transmitir o propósito do teste.
• Isolado: Certifique-se de que os testes não dependam uns dos outros para execução.
• Rápido: Mantenha os testes em execução rapidamente para facilitar a execução frequente.

Seguindo esses princípios, os desenvolvedores podem obter testes limpos e eficazes que se alinham com a filosofia Clean Code de Robert C. Martin.

Noções básicas sobre SerialDate

SerialDate geralmente é uma classe projetada para lidar com operações de data. Sua estrutura, no entanto, pode levar a métodos complexos e complicados que reduzem a clareza e a capacidade de manutenção. Durante o processo de refatoração, é essencial identificar as principais funcionalidades da classe e simplificá-las, tornando o código mais claro e eficiente, conforme aconselhado por Robert C. Martin.

Identificando código problemático

Antes de iniciar a refatoração, é vital analisar SerialDate em busca de sinais de cheiros de código.

• Métodos longos.
• Código duplicado.
• Condicionais complexas.
• Convenções de nomenclatura ruins.

Métodos de extração

Uma estratégia de refatoração eficaz é a extração de métodos. Ao dividir métodos grandes em métodos menores e bem nomeados, aumentamos a legibilidade do código. Por exemplo, se a classe SerialDate tiver um método que executa a validação e a formatação de data, dividi-los em validateDate() e formatDate() permite que cada um sirva a um único propósito, esclarecendo assim a intenção.

Usando nomes significativos

Renomear classes, métodos e variáveis para refletir sua finalidade pode melhorar significativamente a clareza do código. Em SerialDate, alterar nomes como getDateInfo() para retrieveDateDetails() transmite um significado mais claro do que o método faz. Convenções de nomenclatura claras reduzem a carga cognitiva de qualquer pessoa que leia o código, um princípio enfatizado por Martin.

Removendo código duplicado

O código duplicado é uma grande bandeira vermelha em qualquer base de código. Em SerialDate, se cálculos de data semelhantes forem executados em vários locais, considere centralizá-los em um único método de utilitário. Essa prática não apenas reduz o tamanho do código, mas também facilita as atualizações futuras – altere a lógica em um lugar em vez de várias.

Teste de unidade após a refatoração

A refatoração deve sempre seguir uma estratégia robusta de teste de unidade para garantir que a funcionalidade permaneça intacta. Assim como Martin sugere, escreva testes para quaisquer modificações feitas na classe SerialDate , validando se as funções do usuário final se comportam conforme o esperado antes e depois das alterações. Esse compromisso com o desenvolvimento orientado a testes dá suporte à manutenção sustentável do código.