feat(article): 📝 final review

content/blog/a-invencao-do-zero-arquitetural/index.mdx

@@ -1,186 +1,186 @@
 ---
-title: "A invenção do zero (arquitetural)"
+title: "A Invenção do Zero (Arquitetural)"
 date: "2024-01-30"
-description: "'Big Ball of mud' e os problemas da ausência de um estilo arquitetural"
+description: "'Big Ball of Mud' e os problemas da ausência de um estilo arquitetural"
 featuredImage: feature.jpg
 ---
 
-## Os homens que calculavam
+## Os Homens que Calculavam
 
 A contribuição dos árabes para a Matemática foi de grande importância e
 influência ao longo da história. Durante a Idade Média, enquanto a Europa
 estava em um período de estagnação em relação ao desenvolvimento matemático, os
 árabes tiveram um papel fundamental na preservação, tradução e expansão do
-conhecimento matemático greco-romano, bem como na introdução de novos conceitos
-e técnicas matemáticas.
+conhecimento matemático greco-romano, além de introduzir novos conceitos e
+técnicas matemáticas.
 
 Para entendermos a abrangência dessa contribuição basta entendermos a
-etimologia de algumas palavras. A palavra "_al_" no idioma árabe é conhecida
-como o artigo definido, equivalente ao "o" ou "a" em português. Quando os
-árabes dominaram partes da Península Ibérica, eles trouxeram consigo sua língua
-e cultura. Muitas palavras árabes foram gradualmente incorporadas ao português,
-especialmente no vocabulário relacionado ao campo da agricultura, comércio,
-ciência e tecnologia. Um livro muito interessante que conta a relação da
-cultura árabe com a Matemática é _O Homem que Calculava_[^1] de Malba Tahan,
-pseudônimo do escritor brasileiro _Júlio César de Melo e Sousa_.
-
-![Capa do Livro O Homem que Calculava de Malba
-Tahan](./capa-o-homem-que-calculava.webp)
-
-Dessa forma, palavras como "algoritmo", "álgebra" e "algarismo" mantiveram o
-prefixo "_al_" para preservar a sua identidade. E justamente uma das maiores
-contribuições árabes foi a introdução dos algarismos no sistema decimal. Esses
-algarismos hoje são amplamente usados em todo o mundo e formam a base de nosso
-atual sistema numérico. Dentre os algarismos propostos pelo árabes, teve um em
-especial que teve um papel especial, aquele ao qual damos o nome de _zero_.
-
-## A invenção do zero
+etimologia de palavras que utilizamos cotidianamente. A palavra "_al_" no
+idioma árabe é um artigo definido, equivalente ao "o" ou "a" no português.
+Quando os árabes dominaram partes da Península Ibérica, eles trouxeram consigo
+sua língua e cultura. Muitas palavras árabes foram gradualmente incorporadas ao
+português, especialmente no vocabulário relacionado aos campos da agricultura,
+comércio, ciência e tecnologia. Dessa forma, palavras como "_algoritmo_",
+"_álgebra_" e "_algarismo_" mantiveram o prefixo "al" para preservar sua
+identidade. Um livro muito interessante que conta a relação da cultura árabe
+com a Matemática é _O Homem que Calculava_[^1] de Malba Tahan, pseudônimo do
+escritor brasileiro _Júlio César de Melo e Sousa_.
+
+![Capa do Livro O Homem que Calculava de Malba Tahan](./capa-o-homem-que-calculava.webp)
+
+Uma das maiores contribuições árabes no campo da matemática foi a introdução
+dos algarismos no sistema decimal. Esses algarismos hoje são amplamente usados
+em todo o mundo e formam a base do nosso atual sistema numérico. Dentre os
+algarismos propostos pelos árabes, um em especial teve um papel fundamental,
+aquele ao qual damos o nome de "zero".
+
+## A Invenção do Zero
 
 #### Na Matemática
 
-A invenção do número zero representa um marco fundamental na história da
-matemática e um dos avanços mais significativos da humanidade. Embora seja
-difícil identificar o exato momento em que o zero foi inventado, sabemos que
-essa ideia revolucionária começou a ser desenvolvida por civilizações antigas,
-como os maias, babilônios e hindus.
+A invenção do zero representa um marco fundamental na história da matemática e
+um dos avanços mais significativos da humanidade. Embora seja difícil
+identificar o exato momento em que o zero foi inventado, sabemos que essa ideia
+revolucionária começou a ser desenvolvida por civilizações antigas, como os
+maias, babilônios e hindus.
 
 Apesar de não existir um consenso sobre a origem do conceito de zero, alguns
-historiados definem que foi na Índia, por volta do século V d.C., que o conceito
-de zero começou a ser formalizado e utilizado com mais frequência. Os
-matemáticos indianos perceberam que ao adicionar um símbolo para representar uma
-quantidade vazia ou a ausência de algo, era possível transformar completamente a
-forma como os números eram manipulados. 
-
-A importância do zero na matemática foi notada pelos árabes, que depois de sua
-expansão pelo Oriente, trouxeram esse conceito para o Ocidente. Foi na cultura
-árabe que o termo _al-zéro_ surgiu, que posteriormente se transformou na
-palavra “zero” que usamos hoje.
+historiadores definem que foi na Índia, por volta do século V d.C., que o
+conceito começou a ser formalizado e utilizado com mais frequência. Os
+matemáticos indianos perceberam que ao adicionar um símbolo para representar
+uma quantidade vazia ou a ausência de algo, era possível transformar
+completamente a forma como os números eram manipulados. 
+
+Não obstante a sua origem no subcontinente indiano, a importância do zero na
+matemática foi difundida pelos árabes, que depois de sua expansão pelo Oriente,
+trouxeram esse conceito para o Ocidente. Foi na cultura árabe que o termo
+_al-zéro_ surgiu, que posteriormente se transformou na palavra “_zero_” que
+usamos hoje.
 
 A incorporação do número zero na matemática permitiu um grande avanço nas
 operações numéricas. Antes da sua invenção, lidar com quantidades nulas ou a
 realização de cálculos complexos era extremamente difícil. Com a introdução do
 zero, os matemáticos puderam desenvolver sistemas de numeração mais eficientes
-e precisos, como o sistema de numeração posicional usado atualmente.
+e precisos, como o sistema posicional usado atualmente.
 
 
 #### Nas Linguagens de Programação
 
 A invenção do número zero, como conceito matemático, e o conceito de `null` ou
 nulo em linguagens de programação têm uma relação interessante. Assim como o
 número zero foi introduzido na matemática para representar uma quantidade vazia
-ou a ausência de algo, o conceito de `null`, em linguagens de programação,
-serve para representar uma referência vazia ou a ausência de um valor válido.
-Tanto o zero quanto o `null` desempenham a função de indicar a ausência de
-algo, mas em contextos diferentes.
-
-Diferentemente do zero, a possibilidade de referenciar um endereço inválido,
-custou muito caro. O cientista da computação Tony Hoare, em sua palestra _"Null
-References: The Billion Dollar Mistake"_[^2], ressalta que as referências nulas
+ou a ausência de algo, o conceito de `nulo`, em linguagens de programação,
+serve para representar uma referência vazia ou a ausência de um valor. Tanto o
+zero quanto o `null` desempenham a função de indicar a ausência de algo, mas em
+contextos diferentes.
+
+Diferentemente do zero, a possibilidade de referenciar um endereço inválido
+custou muito caro (literalmente). O cientista da computação Tony Hoare, em sua
+palestra [Null References: The Billion Dollar
+Mistake](https://youtu.be/ybrQvs4x0Ps)[^2], ressalta que as referências nulas
 em linguagens de programação podem levar a erros e comportamentos indesejados,
-que custou bilhões de dólares em depuração de código e manutenção de sistemas.
+algo que vêm nos custando bilhões de dólares em depuração de código e
+manutenção de sistemas.
 
 O ponto principal da palestra é que o uso de referências nulas torna o código
 mais propenso a erros, pois muitas vezes os desenvolvedores esquecem de
 verificar se uma referência é nula antes de usá-la, o que pode levar a falhas
-no programa. A exceção `NullPointerException` manda lembranças.
+no programa. O `NullPointerException` nos manda lembranças.
 
 Se por um lado a invenção do zero trouxe vantagens significativas para a
 matemática, o conceito de referências nulas em linguagens de programação tem
 sido alvo de críticas por seus possíveis efeitos negativos e potenciais erros
 causados pela sua utilização inadequada.
 
-#### Na arquitetura de software
-
-Antes de aprofundarmos a discussão do quer seria o zero ou ausência
-arquitetural, gostaria que você refletisse sob a seguinte questão: todo
-sistema/software possui uma arquitetura associada?! Naturalmente estamos
-considerando sistemas com uma quantidade de funcionalidade suficiente para que
-decida definir alguma arquitetura. Para responder essa pergunta, primeiro
-precisamos definir o que seria a arquitetura de um software.
-
-A análise da arquitetura de um software é por natureza multidimensional e deve
-considerar fatores como estrutura, características arquiteturais, princípios de
-desenho e decisões arquiteturais[^4]. A dimensão "_estrutura_" refere-se ao
-tipo de [estilo
-arquitetural](https://notes.clementino.me/blog/estilos-arquiteturais/)
-implementado, ou seja, como os módulos (funções, classes, pacotes e etc.) de um
-sistema devem estar organizados. Em suma, para fins da discussão proposta nesse
-artigo, podemos considerar a _arquitetura de um software como o conjunto de
-regras que governa a organização dos seus módulos.
+#### Na Arquitetura de Software
+
+Antes de aprofundarmos a discussão sobre o que seria um zero ou ausência
+arquitetural, gostaria que você refletisse sobre a seguinte questão: *todo
+sistema/software possui uma arquitetura associada*? Naturalmente, estamos
+considerando sistemas com uma quantidade de funcionalidades suficiente para que
+se decida definir alguma arquitetura. Só é possível responder a essa pergunta, a
+partir do entendimento do que seria a arquitetura de um software.
+
+A análise da arquitetura de um software é, por natureza, multidimensional. Nesse
+sentido, devemos considerar fatores como _estrutura, características
+arquiteturais, princípios de design e decisões arquiteturais_[^4]. A dimensão
+"_estrutura_" refere-se ao tipo de estilo arquitetural implementado, ou seja, como
+os módulos (funções, classes, pacotes, etc.) de um sistema devem estar
+organizados. Em resumo, para fins da discussão proposta neste artigo, podemos
+considerar a arquitetura de um software como o conjunto de regras que governa a
+organização de seus módulos.
 
 Agora que estamos alinhados com a definição de arquitetura de software, podemos
-retornar com a reflexão feita no inicio dessa seção sobre se todo sistema de
-uma uma arquitetura, ou refraseando, após definirmos o conceito de arquitetura
-de software, se para todo sistema é possível determinar um conjunto finito de
-regras logicamente interconectadas que determinam a sua organização?! No limite
-a resposta é não! 
+retornar à reflexão feita no início desta seção: será que todo sistema possui
+uma arquitetura, ou, em outras palavras, após definirmos o conceito de
+arquitetura de software, é possível determinar um conjunto finito de regras
+logicamente interconectadas que determinam sua organização? Em última
+instância, a resposta é não!
 
-Assim como na matemática a ausência do zero na matemática dificultaria a
-compreensão e execução de operações, a falta de  uma arquitetura clara e bem
-definida em um sistema de software pode levar a diferentes problemas. Tanto que
-esse tipo de cenário recebeu um nome "_Big Ball of Mud_".
+Na matemática, a ausência do zero dificulta a compreensão e execução de
+operações. Da mesma forma, a falta de uma arquitetura clara e bem definida em
+um sistema de software pode levar a diferentes problemas. Tanto que esse tipo
+de cenário recebeu o nome de "_Big Ball of Mud_".
 
-## O anti-padrão: Big Ball of Mud
+## O Anti-Padrão: Big Ball of Mud
 
 O conceito de _"Big Ball of Mud"_ se refere a um estilo arquitetural em que
-essas regras e estruturas não estão presentes ou são negligenciadas. Esse termo
-foi cunhado por Brian Foote e Joseph Yoder em seu artigo[^3], descrevendo um
-sistema em que é difícil identificar qualquer tipo de estilo arquitetural
-claro. 
+regras e estruturas não estão presentes ou são negligenciadas. Esse termo foi
+cunhado por Brian Foote e Joseph Yoder em seu artigo[^3], descrevendo um
+sistema em que é difícil identificar qualquer tipo de estilo arquitetônico
+claro.
 
->(...) Big Ball of Mud  é uma selva de código espaguete, estruturada de forma
+>(...) Big Ball of Mud  é uma selva de código espaguete, estruturado de forma
 >aleatória, (...), desleixada, (...). Esses sistemas mostram sinais
 >inconfundíveis de crescimento desordenado (...) . As informações são
->compartilhadas de forma promíscua entre elementos (...) do sistema, muitas
+>compartilhadas de forma promíscua entre os elementos (...) do sistema, muitas
 >vezes a ponto de quase todas as informações importantes se tornarem globais ou
 >duplicadas.
 
-Um sistema com as características de "Big Ball of Mud" geralmente resulta em
+Um sistema com as características de "_Big Ball of Mud_" geralmente resulta em
 código desorganizado, com dependências entrelaçadas, falta de modularidade e
-reutilização de código. Isso impacta diretamente na manutenção, escalabilidade
-e evolução do sistema. O código torna-se difícil de ler e entender,
-dificultando a detecção de problemas, a implementação de novas funcionalidades
-e a correção de erros.
+ausência de reutilização de código. Isso impacta diretamente na manutenção,
+escalabilidade e evolução do sistema. O código torna-se difícil de ler e
+entender, dificultando a detecção de problemas, a implementação de novas
+funcionalidades e a correção de erros.
 
+## Mitigando a Erosão Arquitetural
 
-## Como evitar o anti-padrão
-
-No artigo que dar origem ao termo "_Big Ball of Mud_", os autores, ao avaliaram
+No artigo que deu origem ao termo "_Big Ball of Mud_", os autores, ao avaliarem
 os motivos da ocorrência do anti-padrão, relatam que _"(..) A estrutura geral
 do sistema pode nunca ter sido bem definida. Se tiver sido, pode ter se
-desgastado de forma irreconhecível"_. A partir do que os autores afirma, o
-anti-padrão acontece para os projetos em que arquitetura nunca foi uma
-preocupação, ou se foi, as regras não foram respeitadas ocorrendo o fenômeno
+desgastado de forma irreconhecível"_. A partir do que os autores afirmam, o
+anti-padrão acontece em projetos nos quais a arquitetura nunca foi uma
+preocupação, ou se foi, as regras não foram respeitadas, ocorrendo o fenômeno
 conhecido como _erosão arquitetural_.
 
-A fim de mitigar os efeitos da erosão de um arquitetural, o primeiro passo é a
-mudança de mentalidade de todos envolvidos no desenvolvimento do software. Essa
-mudança de comportamento pode partir da premissa que _"apenas funcionar não
-deveria ser o suficiente"_. Na prática, cada alteração no sistema deveria se
-realizada de forma estratégica e não de uma maneira tática[^5].
+Com o intuito de mitigar os efeitos da erosão de um arquitetural, o primeiro
+passo consiste na mudança de mentalidade de todos envolvidos no desenvolvimento
+do software. Essa mudança de comportamento pode partir da premissa que _"apenas
+funcionar não deveria ser o suficiente"_. Na prática, cada alteração no sistema
+deveria se realizada de forma estratégica e não de uma maneira tática[^5].
 
-Na abordagem tática, seu foco principal é fazer com que algo funcione, como um
-novo recurso ou uma correção de bug. Por outro lado, ao atuar na evolução do
-sistema de forma estratégica, você não deve pensar em "código funcional" como
+Na abordagem tática, o foco está em fazer com que algo funcione, como um novo
+recurso ou uma correção de bug. Por outro lado, ao atuar na evolução do sistema
+de forma estratégica, você não deve pensar apenas no "código funcional" como
 seu objetivo principal, embora, é claro, seu código deva funcionar. O objetivo
-deve ser produzir um ótimo design, que também funcione[^5]. Porém, apenas a
-mudança de comportamento pode não ser suficiente.
-
-Em alguns cenários talvez seja mais efetivo automatizar a detecção de anomalias
-arquiteturais. Para projetos que utilizam Java e outras linguagens
-correlacionadas existe a biblioteca chamada
-[ArchUnit](https://www.archunit.org/). Ao utilizá-la como um teste no projeto
-de software, é possível garantir que a arquitetura definida seja continuamente
-seguida, mesmo que as pessoas envolvidas no projeto não façam mais parte dele.
-Dessa forma, a biblioteca auxilia na manutenção do estilo arquitetural,
-promovendo a consistência e coerência ao longo do tempo. Além disso, a
-_ArchUnit_ possibilita a detecção automática de violações arquiteturais,
-permitindo uma rápida identificação e correção de problemas antes que eles se
-tornem críticos. Isso resulta em um código mais limpo, modular e de fácil
-manutenção. A seguir temos o exemplo de um teste que valida que as classes de
-serviço só tenham dependência com outras classes de serviço ou aquelas de
-camada de acesso à dados.
-
+deve ser produzir um ótimo design, que também funcione[^5]. Porém, em
+determinados contextos, apenas a mudança de comportamento pode não ser
+suficiente.
+
+Em alguns projetos, é mais efetivo automatizar a detecção de anomalias
+arquiteturais. No caso de bases de código escritas em Java, ou outras linguagens
+correlatas, existe uma biblioteca chamada [ArchUnit](https://www.archunit.org/).
+Ao utilizá-la, por meio de um teste no projeto, é possível mitigar desvios na
+arquitetura. Nesse sentido, esse tipo de biblioteca auxilia na manutenção do
+estilo arquitetural, promovendo a consistência e coerência ao longo do tempo.
+
+Além disso, adotar o _ArchUnit_ nos projetos possibilita a detecção automática
+de violações arquiteturais, permitindo uma rápida identificação e correção de
+problemas antes que eles se tornem críticos. Isso resulta em um código mais
+limpo, modular e de fácil manutenção. A seguir, temos um exemplo de um teste
+que valida que as classes de serviço só tenham dependência com outras classes
+de serviço ou com aquelas da camada de acesso aos dados (_repository_).
 
 ```java
 import static com.tngtech.archunit.lang.syntax.ArchRuleDefinition.classes;
@@ -221,10 +221,10 @@ um código mais organizado, reutilizável e de fácil manutenção.
 
 Um anti-padrão como o "_Big Ball of Mud_" existe justamente para nos mostrar a
 importância de estabelecer estruturas e regras para tornar sistemas complexos
-mais compreensíveis e manejáveis. Enquanto o zero facilita operações
-matemáticas, a adoção de uma arquitetura clara facilita a desenvolvimento de
+mais compreensíveis e manejáveis. Assim como o zero facilita operações
+matemáticas, a adoção de uma arquitetura clara facilita o desenvolvimento de
 software de qualidade. Ter uma abordagem estratégica durante a evolução do
-projeto e automatizar a identificação de anomalias podem evitar a erosão da
+projeto e automatizar a identificação de anomalias pode evitar a erosão da
 arquitetura do seu projeto.
 
 [^1]: