Top 7 diagrams as code tools for software architecture
Diagramming software architecture provides several benefits to how we communicate complexity. Clear system designs give engineering teams an enhanced understanding of the architecture and plan for future development whilst identifying potential issues.
Diagrams as code involve writing your model objects, relationships and diagrams using a markup language which can be checked into source control. These tools often include auto-layout capabilities for automatically drawing diagrams.
Structurizr builds upon “diagrams as code”, allowing you to create multiple diagrams from a single model using a number of tools and programming languages.
Free and open source with a paid web platform.
Best for technical people who want to use the C4 model with a DSL and check it into source control.
It includes features such as:
PlantUML is a tool that allows you to write diagrams such as sequence, object, component, usecase, class diagrams and more.
Free and open source.
Best for technical people who want the flexibility of creating many different diagram types and checking them into source control.
It includes features such as:
D2 from Terrastruct is a diagram scripting language that turns text into diagrams.
Free and open source with a paid web platform.
Best for developers who want to create flexible diagrams in code with auto-layout functionality.
It includes features such as:
Mermaid.js is an easy-to-use JavaScript-based diagramming and charting tool.
Free and open source.
Best for developers who want quickly create a range of diagram types and use GitHub to consume them.
It includes features such as:
Ilograph allows interactive diagrams to be drawn using YAML with auto layout, changing the view when you want to see different perspectives.
Free and paid.
Best for semi-technical people who want a web-based solution for visualizing diagrams written as code.
It includes features such as:
Diagrams allow you to draw cloud system architectures using Python code.
Free and open source.
Best for developers who want to draw diagrams using popular cloud provider icons and styles quickly.
It includes features such as:
Graphviz is a graph visualization software for representing structural information as diagrams.
Free and open source.
Best for developers trying to visualize large and complex graph-based information from code.
It includes features such as:
There are many diagrams as code tools to choose from, and it’s important to consider which is best suited for your use case.
Some key things to consider.
Fonte: https://medium.com/bytebytego-system-design-alliance/system-design-blueprint-the-ultimate-guide-e27b914bf8f1
Most of these courses also answer questions I have shared here.
Fonte: https://dev.to/somadevtoo/top-3-strategies-for-scaling-microservices-architecture-1m46
É muito comum que, ao desenvolver um software, alguns desafios acabem surgindo no meio do caminho. No entanto, conforme é possível adquirir experiência ao longo do tempo, torna-se mais fácil determinar quais problemas são mais recorrentes, mesmo que em projetos inteiramente diferentes. Por isso, o Design Patterns é indispensável.
Os padrões que podem ser identificados com a prática levam o nome de “Padrões de Projetos”. Ao nos familiarizarmos com eles, o desenvolvimento de determinados sistemas acaba se tornando muito mais fácil do que era esperado e a chance de acerto é ainda maior.
Com a aplicação do Design Patterns, fica ainda mais fácil conseguir alcançar resultados satisfatórios e que não tragam problemas a curto ou a longo prazo para o seu projeto. É por isso que, neste artigo, você poderá encontrar:
Dentro da área de desenvolvimento de software, os Design Patterns são padrões de projetos que podem ser vistos como uma solução geral, atribuindo maior segurança aos programadores e programadoras. Geralmente, eles são aplicados em alguns problemas específicos que ocorrem ao longo da montagem da estrutura de um software ainda em andamento.
É válido ressaltar que esse tipo de projeto não é aplicado em qualquer parte do código da programação e não pode ser utilizado com a famosa fórmula “Ctrl + c/ Ctrl + v”. Ele deve ser visto como um modelo a se seguir para que um determinado problema seja resolvido em alguma situação específica.
Os Design Patterns são a melhor maneira de solucionar problemas comuns por meio de uma pessoa programadora da área de TI, principalmente quando é necessário projetar as peças de um software em uma determinada aplicação ou sistema. Os padrões são capazes de implicar a orientação dos objetos constituintes do programa desenvolvido ou seu estado mutável.
Sabendo o que é Design Patterns, fica muito mais fácil para que a pessoa consiga sair de uma situação incômoda e passe a enxergar os seus projetos de desenvolvimento com muito mais flexibilidade e facilidade.
Entre os anos de 1977 e 1979, o arquiteto Christopher Alexander escreveu, em seus livros (Notes on the Synthesis of Form, The Timeless Way of Building e A Pattern Language), um padrão que precisa ter, dentro de um ideal, algumas características. São elas:
Retomando a história dos Design Patterns, no ano de 1987, dois programadores (Kent Beck e Ward Cunningham) dispuseram os primeiros padrões de projeto para a área voltada à ciência da computação. Dessa maneira, conseguiram apresentar alguns padrões capazes de construir as aplicações comerciais dentro da linguagem Smalltalk.
Ainda assim, a força dos padrões só chegou a ganhar popularidade no ano de 1995, quando o livro Design Patterns: Elements of Reusable Object-Oriented Software foi publicado. Os autores ficaram conhecidos como “Gangue dos Quatro” e, após esse incentivo, muitas outras obras foram lançadas a respeito.
Além das características que se aplicam aos padrões, Alexander também definiu alguns formatos para que a descrição de um padrão pudesse ter. Dessa maneira, foi possível facilitar o trabalho de muitas pessoas desenvolvedoras e, ainda por cima, permitir que elas tivessem mais sucesso nos trabalhos que desejavam iniciar.
Essas descrições tinham como base os seguintes conceitos:
Agora que já é possível saber o que é Design Patterns, está na hora de compreender como ele funciona na prática e como pode ser de grande ajuda na hora de compor um software. Ainda que possa parecer uma fórmula pronta, esses padrões estão mais para pequenas saídas para problemas corriqueiros no sistema.
Em boa parte dos casos, ele é visto como uma solução reutilizável para os problemas que aparecem no seu sistema, mas precisam estar dentro de um contexto único. Eles servem como um guia para o programador ou programadora, permitindo que o tempo não seja perdido em um determinado tópico, resolvendo-o o mais rápido possível.
Em resumo, eles são utilizados dentro do processo de criação de um software ou programa, visando melhorar a sua qualidade e, ainda por cima, fazer com que a pessoa responsável tenha muito mais tempo para focar em partes relevantes do seu projeto. Assim, é possível deixar de lado os pequenos erros que poderiam atrapalhar a funcionalidade.
De uma maneira geral, os Design Patterns servem como uma boa referência para aqueles e aquelas que estão começando agora ou, simplesmente, desejam ter mais facilidade na criação de seu trabalho. Podem ser usados a qualquer momento, desde que a pessoa compreenda bem onde encaixá-los e quando incluí-los.
O Gang Of Four Design Patterns foi criado por 4 autores, sendo eles Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides. Esse padrão de design foi apresentado, pela primeira vez, no livro “Design Patterns: Elements of Reusable Object-Oriented Software”, no ano de 1994. Por meio dele, é possível ter uma base de padrões do campo de design para objetos.
O padrão de design nada mais é do que aquela solução que, em algum momento, será reutilizada para resolver um problema que é comumente encontrado em um software. Dessa forma, sempre que for necessário, haverá um modelo disponibilizado para burlar algum empecilho na programação.
Os padrões de design Gang Of Four Design Patterns são seguidos por algumas categorias que, logo abaixo, serão definidas, facilitando a vida de quem programa. Sendo assim, aproveite para aprender um pouco mais e desenvolver maior desenvoltura acerca do tema.
O Creational Design Patterns, em tradução livre “Design Patterns de Criação” é um padrão de criação que precisa lidar com a criação de objetos. Sendo assim, será necessário encontrar maneiras de resolver os problemas de design decorrentes da criação de algum objeto.
De uma maneira geral, este padrão de Design Patterns tem como principal objetivo construir o objeto e sua referência. Além disso, o grupo se mostra inteiramente relevante para sustentar o princípio que é considerado essencial, referindo-se à programação de uma interface e não de suas implementações.
Neste padrão, é possível encontrar:
No design de estrutura, será necessário utilizar os padrões estruturais com o principal objetivo de facilitar a finalização do projeto. Por meio dele, será possível identificar uma maneira bem mais simples de realizar os relacionamentos entre entidades sem necessariamente se deparar com algum erro no meio do caminho.
Outro ponto importante, que pode ser facilmente observado por quem estuda sobre Design Patterns, é que essa categoria trata da relação direta entre os objetos e como eles interagem entre si, visando formar um objeto maior e mais complexo.
Este padrão é composto por:
Por fim, ainda há o Design Patterns de Comportamento, muito utilizado para definir padrões comportamentais. Por meio desse tipo de produção, é possível identificar padrões de comunicação que são comuns entre objetos e que podem ser capazes de dar continuidade aos padrões anteriormente estabelecidos.
Além disso, eles ainda são responsáveis por uma comunicação direta entre os objetos, principalmente no que diz respeito aos termos de responsabilidade e de algoritmo.
Neste padrão, estão inseridos:
É importante relatar que o conceito de padrão de um projeto foi criado por volta dos anos 70, pelo arquiteto Christopher Alexander, como já mencionado anteriormente. Por meio de seus conhecimentos acumulados em uma mesma obra, foi possível estabelecer alguns padrões a serem seguidos pelas pessoas programadoras.
Além do Design Patterns Gang Of Four, também é possível encontrar outros tipos como, por exemplo, o Car Connection, Positive Outdoor e o Connected Buildings. São tantos os modelos que, quando colocados lado a lado, é possível somar mais de 125 padrões. Por um lado, é benéfico para quem programa, já que podem ter mais opções na hora de resolver algum problema de software.
No entanto, quando qualquer tipo de padrão referido se relaciona com o GOF (Gang Of FOur), é válido lembrar que ele atende a um formato específico, sendo ele:
Para quem está iniciando no âmbito do Design Patterns, é importante levar em consideração que esse tipo de aplicação pode ser bastante desafiadora em seus princípios, além de apresentar um desenvolvimento de software um pouco mais complexo do que aquele que foi aprendido anteriormente. Sendo assim, é necessário estar atento a todos os detalhes.
Mesmo que não exista uma técnica muito simples para se inserir nesse mundo tecnológico dos códigos, é necessário ressaltar que algumas dicas podem ser suficientes para reduzir a carga de trabalho. Ainda assim, para quem deseja seguir nesse caminho, qualquer pequeno esforço é válido.
É muito comum que os iniciantes acreditem que todo aplicativo precisa usar padrões de um determinado projeto. No entanto, é importante lembrar que isso não é necessário. Ainda que os padrões sejam muito úteis para solucionar problemas conhecidos, é preciso entender que usá-los acrescenta certa complexidade ao trabalho.
Sendo assim, caso um programador ou programadora esteja escrevendo um projeto pequeno, levando em consideração um script que será usado em apenas uma situação não crítica, aplicar padrões de projeto pode acabar se tornando um verdadeiro exagero e, consequentemente, uma perda de tempo.
Mais um erro cometido por iniciantes quando o assunto é Design Patterns está diretamente relacionado com utilizar vários padrões dentro de um único projeto. Isso não só aumentará a complexidade do desenvolvimento do software como também poderá acrescentar alguns erros que, posteriormente, precisarão ser resolvidos.
Sendo assim, a melhor dica é tentar desenvolver o hábito de identificar determinados padrões que podem ser usados dentro de um mesmo sistema. Assim, será fácil perceber que será preciso usar mais alguns padrões do que outros. Por isso, alguns padrões se tornarão os seus favoritos e mais corriqueiros no projeto.
Para trabalhar com o Design Patterns, é necessário ter muita paciência. Cada passo dado representa uma nova experiência vivida. Por meio do GOF, será possível assimilar muitas coisas e, consequentemente, adquirir desenvoltura para conseguir finalizar os seus projetos sem, necessariamente, realizar tantas consultas a ele.
Ter em mente todos os padrões estabelecidos no Design Patterns pode acabar se mostrando um processo gradual e um tanto lento, além de ser contínuo. Por isso, é importante que, antes de mais nada, a pessoa possa se sentir à vontade com os padrões GOF para que, em seguida, comece a usar padrões do catálogo P do EAA.
Assim como tudo na vida, o aprendizado vem com o treinamento. É por isso que, se você deseja se aprofundar no Design Patterns, precisará reservar um bom tempo do seu dia para exercitar os códigos e padrões pré-estabelecidos. Lembrar padrões não acontecerá de uma hora para a outra.
Uma boa dica de exercício é começar a criar dicas práticas para os padrões utilizados em um projeto. Depois, basta anotá-las com a ajuda de alguma figura ou palavra-chave. Assim, ficará muito mais fácil memorizar os padrões e todos os conceitos que estão atrás dele.
Existem muitos profissionais que já estão formalmente acostumados com a utilização do Design Patterns. Sendo assim, é necessário buscá-los caso você também queira se especializar e sair da categoria de iniciante para especialista. Estudar o código escrito por alguém com experiência é um bom primeiro passo.
Dessa forma, será possível compreender como os desenvolvedores ou desenvolvedoras estão aplicando os padrões e como você conseguirá aprender por meio de técnicas individuais. Existem muitos fóruns na internet sobre o assunto e, também, alguns cursos que podem ser muito bem aproveitados pelos programadores com sede de conhecimento.
É importante lembrar, principalmente para as pessoas que estão iniciando, que os princípios e padrões SOLID não serão úteis, apenas, durante o desenvolvimento inicial de sua base de código. Isso porque elas poderão se mostrar inteiramente úteis ao estender ou manter uma base de código que já existe.
É por isso que, para quem está se aperfeiçoando no Design Patterns, seja por conta própria ou com a ajuda de especialistas, precisa utilizar a manutenção de códigos como um dos pilares da programação. Adote boas práticas e comece a realizar exercícios diariamente para que, enfim, seja possível se tornar um especialista na área.
Um dos principais motivos para estudar esse tipo de Design está na facilidade que ele oferece. Certo dia, algumas pessoas começaram a perceber que tinham os mesmos problemas durante o processo de programação. Por isso, desenvolveram alguns padrões que fossem capazes de reverter a situação para tornar o projeto mais assertivo.
Ainda que os padrões do Design Patterns GOF tenham sido escritos há algumas décadas, aprender cada vez mais sobre os softwares é extremamente importante. Isso porque os sistemas costumam funcionar como se, de fato, fossem organismos vivos. Por isso, para ser um bom programador ou uma boa programadora, é preciso acompanhar as transformações e se adaptar a elas.
É válido lembrar, também, que nem todos os padrões estabelecidos no GOF são bem aceitos dentro das comunidades de desenvolvimento. Por isso, abusar no uso de padrões dentro de um mesmo projeto pode acabar complicando ainda mais a situação. A supervalorização de qualquer coisa deixa a sua manutenção complexa.
Existem muitos benefícios que rondam a utilização dos Design Patterns, mas um deles, com toda a certeza, é o mais relevante: a agilidade. Para quem está desenvolvendo um projeto, códigos que possam ajudar a solucionar um problema rapidamente podem ser muito bem-vindos a qualquer momento.
Além disso, esses padrões determinados são ótimos para ajudar a organizar e manter os projetos em ordem. Eles se baseiam diretamente em um baixo acoplamento entre classes, além de levar em consideração a padronização estabelecida em um código. Cada dia mais surgem técnicas facilitadas para auxiliar o programador.
Depois de compreender melhor o que é Design Patterns, como ele funciona e porque é necessário aprender, é possível observar que esse padrão foi criado para facilitar a vida dos programadores e programadoras. Sendo assim, torna-se indispensável buscar conhecimento acerca da área para solucionar os problemas dos projetos de forma simples, assertiva e ágil.
Os princípios S.O.L.I.D. são um conjunto de diretrizes para o design de software orientado a objetos que ajudam a fazer sistemas mais compreensíveis, flexíveis e mantíveis. Criados e popularizados por Robert C. Martin (também conhecido como “Uncle Bob”), esses princípios têm como objetivo melhorar a legibilidade do código, facilitar a manutenção e permitir que o software evolua com menos riscos de introduzir bugs. Este eBook explora cada um dos princípios com detalhes, auxiliando desenvolvedores a aplicá-los efetivamente em projetos sem recorrer a exemplos de código.
O Princípio da Responsabilidade Única estabelece que uma classe deve ter uma, e somente uma, razão para mudar. Isso significa que cada classe deve ser responsável por uma única parte da funcionalidade fornecida pelo software. A ideia central é que acoplar múltiplas responsabilidades em uma única classe aumenta o risco de alterações em uma área afetarem outras, levando a bugs e dificuldades na manutenção.
O Princípio do Aberto/Fechado declara que o software deve ser aberto para extensão, mas fechado para modificação. Isso significa que a funcionalidade de uma classe deve ser estendida sem alterar seu código existente, promovendo a criação de sistemas que podem crescer com o tempo sem sacrificar estabilidade.
Segundo o Princípio da Substituição de Liskov, objetos de uma classe devem poder ser substituídos por objetos de suas subclasses, sem alterar a correção do programa. Este princípio assegura que uma classe derivada pode ser usada no lugar de sua classe base sem comprometer a funcionalidade.
O Princípio da Segregação de Interface sugere que os clientes não devem ser forçados a depender de interfaces que não utilizam. Isso implica que é melhor criar interfaces mais específicas e focadas, ao invés de usar interfaces “gordas” e genéricas.
O Princípio da Inversão de Dependência afirma que módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender de abstrações, que não devem depender de detalhes. Este princípio incentiva o uso de interfaces ou classes abstratas para desacoplar componentes do sistema.
Os princípios S.O.L.I.D. são fundamentais para a construção de software robusto, escalável e fácil de manter. Ao aplicar esses princípios, os desenvolvedores podem criar sistemas mais modulares e adaptáveis às mudanças, garantindo que os investimentos em software sejam protegidos ao longo do tempo. Em um cenário de desenvolvimento contínuo, onde mudanças e requisitos novos são constantes, compreender e aplicar S.O.L.I.D. é essencial para garantir a longevidade e o sucesso dos projetos de software.
Para aprofundar seu conhecimento e aplicar eficazmente os princípios S.O.L.I.D., considere as seguintes ações:
Espero que este eBook sirva como um guia útil e inspirador em sua jornada no desenvolvimento de software de alta qualidade!
Livro: “Design Patterns: Elements of Reusable Object-Oriented Software” Autores: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides Publicado em 1994
Os padrões de design visam tornar o código mais flexível, reutilizável e manutenível, resolvendo problemas recorrentes no desenvolvimento de software orientado a objetos.
𝟭. 𝗦𝗰𝗮𝗹𝗮𝗯𝗹𝗲 𝗗𝗮𝘁𝗮 𝗦𝘁𝗼𝗿𝗮𝗴𝗲
• Relational vs. NoSQL: Know when to use SQL vs. NoSQL databases.
• Partitioning: Vertical and horizontal partitioning (sharding). Understand trade-offs.
• Indexing: Covering indexes, primary vs. secondary indexes.
• Consistency Models: Strong, eventual, causal.
𝟐. 𝐂𝐚𝐜𝐡𝐢𝐧𝐠
• Client-side vs. Server-side Cache: Understand where caching should happen.
• Caching Strategies: Write-through, write-back, write-around.
• Distributed Cache: Redis, Memcached.
• Cache Eviction Policies: LRU, LFU, etc.
𝟑. 𝐋𝐨𝐚𝐝 𝐁𝐚𝐥𝐚𝐧𝐜𝐢𝐧𝐠
• Horizontal Scaling: Why and how to horizontally scale services.
• Load Balancing Techniques: Round-robin, consistent hashing.
• Reverse Proxy: Understand how to use Nginx, HAProxy.
𝟒. 𝐀𝐬𝐲𝐧𝐜𝐡𝐫𝐨𝐧𝐨𝐮𝐬 𝐏𝐫𝐨𝐜𝐞𝐬𝐬𝐢𝐧𝐠
• Message Brokers: Kafka, RabbitMQ. When to use queues vs. streams.
• Event-Driven Architecture: Benefits of decoupling and event sourcing.
• Task Queues: For delayed jobs or retries.
𝟓. 𝐃𝐚𝐭𝐚𝐛𝐚𝐬𝐞 𝐑𝐞𝐚𝐝 𝐚𝐧𝐝 𝐖𝐫𝐢𝐭𝐞 𝐒𝐜𝐚𝐥𝐢𝐧𝐠
• Read Scaling: Master replication, read replicas.
• Write Scaling: Challenges with partitioning for writes, leader-election.
• CAP Theorem: Consistency, Availability, or Partition tolerance may be compromised.
𝟲. 𝗗𝗶𝘀𝘁𝗿𝗶𝗯𝘂𝘁𝗲𝗱 𝗦𝘆𝘀𝘁𝗲𝗺𝘀 𝗖𝗼𝗻𝗰𝗲𝗽𝘁𝘀
• Consensus Algorithms: Paxos, Raft.
• Conflict Resolution: Last Write Wins, CRDTs, vector clocks for data reconciliation.
𝟳. 𝗥𝗲𝗹𝗶𝗮𝗯𝗶𝗹𝗶𝘁𝘆 𝗮𝗻𝗱 𝗙𝗮𝗶𝗹𝗼𝘃𝗲𝗿
• Redundancy: Active-passive vs. active-active configurations.
• Health Checks.
• Retries and Circuit Breakers: How to protect systems from cascading failures.
𝟴. 𝗖𝗗𝗡𝘀 (𝗖𝗼𝗻𝘁𝗲𝗻𝘁 𝗗𝗲𝗹𝗶𝘃𝗲𝗿𝘆 𝗡𝗲𝘁𝘄𝗼𝗿𝗸𝘀)
• Static Content Delivery: Why use a CDN, how does it work?
• Caching at the Edge: How CDNs improve latency for end users.
𝟵. 𝗔𝗣𝗜 𝗗𝗲𝘀𝗶𝗴𝗻 𝗮𝗻𝗱 𝗥𝗮𝘁𝗲 𝗠𝗮𝗻𝗮𝗴𝗲𝗺𝗲𝗻𝘁
• REST vs. GraphQL: Difference and practical use-cases for each.
• Pagination and Filtering: Strategies for efficiently fetching data.
• API Versioning: Best practices for evolving APIs.
• Throttle Requests: Why rate limiting is essential, algorithms like token bucket, leaky bucket.
𝟭𝟬. 𝗦𝗲𝗮𝗿𝗰𝗵 𝗦𝘆𝘀𝘁𝗲𝗺𝘀
• Indexing: Building and maintaining indexes for fast search.
• Full-Text Search Engines: ElasticSearch, Azure AI Search.
• Ranking and Relevance: Basic understanding of how scoring works.
𝟭𝟭. 𝗠𝗼𝗻𝗶𝘁𝗼𝗿𝗶𝗻𝗴 𝗮𝗻𝗱 𝗢𝗯𝘀𝗲𝗿𝘃𝗮𝗯𝗶𝗹𝗶𝘁𝘆 𝗮𝗻𝗱 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆
• Metrics Collection: Prometheus, Grafana.
• Distributed Tracing: OpenTelemetry, Sentry.
• Centralized Logging.
• Authentication and Authorization: OAuth, JWT.
• Encryption: Data in transit vs. data at rest.
If you master these 11 areas, you’ll be ready for most system design interviews thrown at you.
No livro do Uncle Bob foram listadas algumas boas práticas para se obter um código limpo. Os principais são:
A definição de nome é essencial para o bom entendimento de um código. Aqui, não importa o tipo de nome, seja ele:
Ao definir um nome, é preciso ter em mente 2 pontos principais:
Há um princípio do escotismo que diz que, uma vez que você sai da área em que está acampando, você deve deixá-la mais limpa do que quando a encontrou.
Trazendo a regra para o mundo da programação, a regra significa deixar o código mais limpo do que estava antes de mexer nele.
O ser humano é acostumado a pensar de forma narrativa , portanto, o código funciona da mesma forma. Logo, ele é uma história e, como os programadores são seus autores, precisam se preocupar na maneira com que ela será contada.
Em resumo, para estruturar um código limpo, é necessário criar funções simples, claras e pequenas. Existem 2 regras para criar a narrativa via código:
Não confunda com os termos “nome” e “função”. Como dissemos no primeiro princípio, nomes grandes não são um problema. Já as funções precisam ser as menores possíveis.
Esse princípio pode ser traduzido como “não repita a si mesmo”. Essa expressão foi descrita pela primeira vez em um livro chamado The Pragmatic Programmer e se aplica a diversas áreas de desenvolvimento, como:
O DRY diz que cada pedaço do conhecimento de um sistema deve ter uma representação única e ser totalmente livre de ambiguidades. Em outras palavras, define que não pode existir duas partes do programa que desempenhem a mesma função.
Esse princípio afirma que comentários podem ser feitos, porém, se forem realmente necessários. Segundo Uncle Bob, os comentários mentem. E isso tem uma explicação lógica.
O que ocorre é que, enquanto os códigos são constantemente modificados, os comentários não. Eles são esquecidos e, portanto, deixam de retratar a funcionalidade real dos códigos.
Logo, se for para comentar, que seja somente o necessário e que seja revisado juntamente com o código que o acompanha.
Tem uma frase do autor Michael Feathers, muito conhecido na área de desenvolvimento, que diz que as coisas podem dar errado, mas, quando isso ocorre, os programadores são os responsáveis por garantir que o código continuará fazendo o que precisa.
Ou seja: saber tratar as exceções de forma correta é um grande e importante passo para um programador em desenvolvimento.
Testar, na área de programação, é uma etapa muito importante. Afinal, um código só é considerado limpo após ser validado através de testes – que também devem ser limpos.
Por isso, ele deve seguir algumas regras, como:
O Clean Code é um conceito que veio para ficar. Afinal, seus princípios solucionam com eficácia um dos principais problemas que grande parte dos projetos de sistemas enfrentam: a manutenção.