Quantos projetos j\u00e1 fracassaram, n\u00e3o por falta de talento, mas por excesso de caos? Programar \u00e9 como erguer uma catedral! Cada linha de c\u00f3digo \u00e9 um tijolo, e a grandiosidade do projeto depende de como se sustentam. Sem alicerces s\u00f3lidos, at\u00e9 a ideia mais brilhante desaba sob o peso da desordem. Martin (2009) defende que a desorganiza\u00e7\u00e3o no c\u00f3digo amplifica as falhas e custos de manuten\u00e7\u00e3o, transformando sistemas em labirintos intranspon\u00edveis.<\/p>\n\n\n\n
Na faculdade, aprende-se a esculpir fun\u00e7\u00f5es com precis\u00e3o, mas pouco sobre como entrela\u00e7\u00e1-las. Quando se mergulha em projetos reais, 500 linhas inocentes viram 50.000, e a manuten\u00e7\u00e3o se transforma num jogo de espelhos quebrados. Foi para domar esse caos que surgiram os padr\u00f5es de projeto, n\u00e3o como regras engessadas, mas como filosofias que celebram a clareza (GAMMA et al., 1994).<\/p>\n\n\n\n
A organiza\u00e7\u00e3o transcende a est\u00e9tica: \u00e9 a ess\u00eancia econ\u00f4mica de uma obra-prima. Uma biblioteca onde cada livro tem lugar certo ilustra um sistema com responsabilidades claras. Quando cada m\u00e9todo segue o princ\u00edpio da responsabilidade \u00fanica, conforme sugerido por Fowler e Beck (1999), os bugs<\/em> tornam-se exce\u00e7\u00f5es, n\u00e3o a regra. Nessa arquitetura bem estruturada, pr\u00e1ticas como revis\u00f5es de c\u00f3digo e integra\u00e7\u00e3o cont\u00ednua atuam como curadores invis\u00edveis: cada erro \u00e9 detectado precocemente, isolado como um livro fora do lugar, antes que defeitos m\u00ednimos se propaguem transformando-se em falhas. Essa disciplina n\u00e3o apenas reduz a incid\u00eancia de bugs<\/em>, como otimiza a evolu\u00e7\u00e3o do sistema, um equil\u00edbrio entre rigor e agilidade que Martin (2009) e Fowler e Beck (1999) elevam \u00e0 condi\u00e7\u00e3o de arte.<\/p>\n\n\n\n E aqui surge a ironia: coment\u00e1rios excessivos, alerta Knuth (1992, p. 97-134), muitas vezes mascaram a falta de clareza na arquitetura, como gesso sobre rachaduras. Al\u00e9m disso, a implementa\u00e7\u00e3o de testes automatizados e a refatora\u00e7\u00e3o cont\u00ednua s\u00e3o essenciais para evitar o ac\u00famulo de d\u00edvida t\u00e9cnica, o custo oculto dos atalhos e da manuten\u00e7\u00e3o negligente. Como exposto por Fowler e Beck (1999), aprimorar constantemente a estrutura do c\u00f3digo \u00e9 t\u00e3o vital quanto sua constru\u00e7\u00e3o inicial, permitindo que o software evolua sem perder sua robustez.<\/p>\n\n\n\n Mas como medir toda essa complexidade? \u00c9 aqui que m\u00e9tricas, como a Complexidade Ciclom\u00e1tica de McCabe (1976), entram em cena: uma lente que revela a intrincada teia de decis\u00f5es l\u00f3gicas e define a robustez de um sistema. Um exemplo an\u00e1logo seria um engenheiro medieval calculando tens\u00f5es em arcos; McCabe (1976) prop\u00f4s algo similar para o c\u00f3digo, quantificando os caminhos poss\u00edveis que um fluxo de execu\u00e7\u00e3o pode percorrer. Quanto mais ramifica\u00e7\u00f5es, maior o risco de fissuras na l\u00f3gica.<\/p>\n\n\n\n \u00c9 um term\u00f4metro da manutenibilidade: sistemas com baixa complexidade, aliados a padr\u00f5es como os de Gamma et al. (1994), resistem ao tempo. Separar l\u00f3gica de neg\u00f3cios da interface n\u00e3o \u00e9 vaidade, \u00e9 projetar alicerces imunes a decora\u00e7\u00f5es ef\u00eameras. A arquitetura limpa de Martin (2009) isola regras do dom\u00ednio em “colunas d\u00f3ricas”, est\u00e1veis ante interfaces vol\u00e1teis.<\/p>\n\n\n\n Startups que escalam e gigantes como o Google compreendem esse princ\u00edpio. Seus c\u00f3digos s\u00e3o como catedrais g\u00f3ticas: cada arco (m\u00e9todo) calcula tens\u00f5es, cada vitral (interface) filtra a complexidade. A ess\u00eancia \u00e9 resumida por Knuth (1992, p. 97-134): programar para humanos, e n\u00e3o para m\u00e1quinas, \u00e9 o que transforma linhas de c\u00f3digo em legados.<\/p>\n\n\n\n N\u00e3o se trata de perfei\u00e7\u00e3o, mas de resili\u00eancia. Quando se enxerga o c\u00f3digo como uma entidade viva \u2013 em que cada vari\u00e1vel h\u00e1 um prop\u00f3sito e em cada loop, narrativa \u2013, constroem-se monumentos digitais. Porque grandes softwares, assim como as catedrais medievais, s\u00e3o lembrados n\u00e3o apenas pelo que representam, mas pela arte invis\u00edvel que os sustenta.<\/p>\n\n\n\n REFER\u00caNCIAS<\/strong><\/p>\n\n\n\n FOWLER, M.; BECK, K. Refactoring: Improving the design of existing code<\/strong>. Boston, MA, USA: Addison Wesley, 1999.<\/p>\n\n\n\n GAMMA, E. et al. Design patterns: Elements of reusable object-oriented software<\/strong>. [s.l.] Addison-Wesley Professional, 1994.<\/p>\n\n\n\n KNUTH, D. E. Literate Programming<\/strong>. 1. ed. Stanford, CA, USA: Centre for the Study of Language & Information, 1992. v. 27.<\/p>\n\n\n\n MARTIN, R. C. Clean code: A handbook of agile software craftsmanship<\/strong>. Filad\u00e9lfia, PA, USA: Prentice Hall, 2009.<\/p>\n\n\n\n MCCABE, T. J. A Complexity Measure. IEEE transactions on software engineering<\/strong>, v. SE-2, n. 4, p. 308\u2013320, 1976.<\/p>\n\n\n\n \u2022 Alunos:<\/strong> Roger Freitas Pereira, Guilherme Rodrigues Dos Santos, Marcos Felipe Correia Soares Quantos projetos j\u00e1 fracassaram, n\u00e3o por falta de talento, mas por excesso de caos? Programar \u00e9 como erguer uma catedral! Cada linha de c\u00f3digo \u00e9 um tijolo, e a grandiosidade do projeto depende de como se sustentam. Sem alicerces s\u00f3lidos,…<\/p>\n","protected":false},"author":3,"featured_media":1631,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[15,33],"tags":[],"class_list":["post-1630","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ciencia-tecnologia","category-eng-de-computacao"],"_links":{"self":[{"href":"https:\/\/cefsa.org.br\/crescendojuntos\/wp-json\/wp\/v2\/posts\/1630","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cefsa.org.br\/crescendojuntos\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cefsa.org.br\/crescendojuntos\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cefsa.org.br\/crescendojuntos\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/cefsa.org.br\/crescendojuntos\/wp-json\/wp\/v2\/comments?post=1630"}],"version-history":[{"count":0,"href":"https:\/\/cefsa.org.br\/crescendojuntos\/wp-json\/wp\/v2\/posts\/1630\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cefsa.org.br\/crescendojuntos\/wp-json\/wp\/v2\/media\/1631"}],"wp:attachment":[{"href":"https:\/\/cefsa.org.br\/crescendojuntos\/wp-json\/wp\/v2\/media?parent=1630"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cefsa.org.br\/crescendojuntos\/wp-json\/wp\/v2\/categories?post=1630"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cefsa.org.br\/crescendojuntos\/wp-json\/wp\/v2\/tags?post=1630"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\u2022 Orientador:<\/strong> Prof. Me. Eduardo Rosalem Marcelino<\/p>\n","protected":false},"excerpt":{"rendered":"