{"id":4002,"date":"2022-04-12T18:30:40","date_gmt":"2022-04-12T21:30:40","guid":{"rendered":"https:\/\/elemarjr.com\/arquiteturadesoftware\/?p=4002"},"modified":"2024-01-11T17:55:19","modified_gmt":"2024-01-11T20:55:19","slug":"construindo-arquiteturas-que-evoluem-capitulo-1-5-v3-0","status":"publish","type":"volume-1","link":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/construindo-arquiteturas-que-evoluem-capitulo-1-5-v3-0\/","title":{"rendered":"Construindo arquiteturas que evoluem \/ Cap\u00edtulo 1.5 v3.0"},"content":{"rendered":"

Software muda! Muitas vezes para atender novas necessidades do neg\u00f3cio, algumas vezes para acomodar evolu\u00e7\u00f5es tecnol\u00f3gicas.<\/strong> Boas pr\u00e1ticas arquiteturais ajudam a “aceitar” melhor as mudan\u00e7as, minimizando custo e riscos.<\/p>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\" <\/p>\n

Apesar de nossos melhores esfor\u00e7os, o software se torna mais dif\u00edcil de alterar com o tempo. Por uma variedade de raz\u00f5es, as partes que comp\u00f5em os sistemas de software desafiam a modifica\u00e7\u00e3o f\u00e1cil, tornando-se mais fr\u00e1geis e intrat\u00e1veis com o tempo.\u00a0<\/em><\/p>\n

\r\n

Ford, Parsons e Kua<\/strong><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

Com o tempo, a aplica\u00e7\u00e3o de mudan\u00e7as gera, naturalmente, complexidades predat\u00f3rias.<\/strong> Ou seja, resqu\u00edcios de iniciativas ou decis\u00f5es do passado que ficam no c\u00f3digo ou em decis\u00f5es que n\u00e3o foram adequadamente revertidas. As pr\u00e1ticas da arquitetura devem mitigar essas complexidades de maneira cont\u00ednua e disciplinada.<\/strong><\/p>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\" Complexity is anything related to the structure of a software system that makes it hard to understand and modify the system.<\/em>\r\n

John Ousterhout<\/strong><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

O ritmo das mudan\u00e7as, tecnol\u00f3gicas e de neg\u00f3cios, est\u00e1 acelerado e est\u00e1 ficando cada vez mais acelerado. Ali\u00e1s, essa \u00e9 a caracter\u00edstica que melhor justifica as atividades de arquitetura.<\/p>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\" If I had to name one primary factor that influences architecture, I\u2019d put rate of change at the top of my list.<\/em>\r\n

Greg Hohpe<\/strong><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\nPor tudo isso, Evolvability<\/em> \u00e9 um importante atributo de qualidade para qualquer boa arquitetura, sen\u00e3o o mais importante.<\/strong>\n

\n
\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\" Sempre inclua Evolvability <\/em>entre os atributos de qualidade de seus projetos.<\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

 <\/p>\n

\"Fixing<\/p>\n

\r\n

Defini\u00e7\u00e3o: Evolvability<\/p>\r\n

<\/p>\n

Atributo de qualidade relacionado a capacidade de um sistema “evoluir”, tanto para atender demandas de neg\u00f3cio como para “acomodar” novidades tecnol\u00f3gicas, sem comprometer objetivos do neg\u00f3cio, desrespeitar restri\u00e7\u00f5es ou romper os demais atributos.<\/p>\n

<\/p>\r\n<\/div>\n

As leis de Lehman<\/h2>\n

Ao longo de d\u00e9cadas, Meir Lehman<\/a> e L\u00e1szl\u00f3 B\u00e9l\u00e1dy<\/a> formularam, propuseram e aprimoraram diversas \u201cleis\u201d que, alegadamente, governam a evolu\u00e7\u00e3o de sistemas de software. Essas leis ficaram conhecidas como \u201cLeis de Lehman\u201d.<\/p>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\"\r\n

As leis de Lehamn<\/p>\r\n<\/p>\n

As \u201cLeis de Lehman\u201d direcionam o comportamento e o projeto das iniciativas para engenharia de software.<\/p>\n

\n

Nesse epis\u00f3dio, dispon\u00edvel em \u00e1udio e v\u00eddeo, explicamos essas leis.<\/p>\n

\r\n

Acessar epis\u00f3dio<\/a><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\nAs \u201cLeis de Lehman\u201d descrevem e ajudam a entender o sens\u00edvel equil\u00edbrio entre as motiva\u00e7\u00f5es para a evolu\u00e7\u00e3o de um software, por adapta\u00e7\u00f5es, e as causas para o aumento da complexidade (em consequ\u00eancia, do lead time para atender demandas do neg\u00f3cio) ao longo do tempo.\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\" <\/p>\n

Complexity will still increase over time, in spite of our best efforts, but simpler designs allow us to build larger and more powerful systems before complexity becomes overwhelming.<\/em><\/p>\n

\r\n

John Ousterhout<\/strong><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

As duas primeiras \u201cleis\u201d formuladas por eles, em 1974, foram a lei da \u201cmudan\u00e7a cont\u00ednua\u201d e a lei da \u201ccomplexidade crescente\u201d.<\/strong> A primeira diz que, ao longo do tempo, um sistema de software precisa ser continuamente adaptado, recebendo novas \u201cadapta\u00e7\u00f5es\u201d, para se manter relevante e satisfat\u00f3rio. A segunda aponta que, enquanto essas \u201cadapta\u00e7\u00f5es\u201d s\u00e3o feitas, o software se torna mais complexo, exceto quando existam esfor\u00e7os explicitamente direcionados para mitigar essa complexidade.<\/p>\n

\"Qual<\/p>\n

As duas leis, deliciosamente evidentes e conflitantes, levam a alguns desdobramentos preocupantes:<\/p>\n