{"id":74955,"date":"2020-03-22T08:42:23","date_gmt":"2020-03-22T05:42:23","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-prochest-i-ispravit-100000-strok-koda-za-nedelyu"},"modified":"2020-03-22T08:42:23","modified_gmt":"2020-03-22T05:42:23","slug":"kak-prochest-i-ispravit-100000-strok-koda-za-nedelyu","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/kak-prochest-i-ispravit-100000-strok-koda-za-nedelyu","title":{"rendered":"Como ler e corrigir 100.000 linhas de c\u00f3digo em uma semana","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Como
\nNo in\u00edcio, \u00e9 sempre dif\u00edcil entender um projeto grande e antigo. A avalia\u00e7\u00e3o de arquitetura \u00e9 uma das atividades do arquiteto. Normalmente, temos que trabalhar com projetos grandes e antigos, e os resultados precisam ser apresentados em uma semana.<\/p>\n

Como avaliar um projeto com 100 mil linhas de c\u00f3digo ou mais em uma semana e fornecer resultados realmente \u00fateis para o cliente?<\/p>\n

A maioria dos arquitetos e l\u00edderes t\u00e9cnicos j\u00e1 se deparou com avalia\u00e7\u00f5es de projetos como estas. Pode parecer um processo semi-formal ou um servi\u00e7o separado, como fazemos em nossa empresa, mas, de qualquer forma, a maioria de voc\u00eas j\u00e1 lidou com isso.<\/p>\n

A vers\u00e3o original em ingl\u00eas para seus amigos que n\u00e3o falam russo est\u00e1 aqui: Avalia\u00e7\u00e3o de Arquitetura em uma semana<\/a><\/noindex>.
\n<\/a><\/noindex><\/p>\n

Abordagem em nossa empresa<\/h2>\n

\nVou explicar como isso funciona em nossa empresa e como eu lido com situa\u00e7\u00f5es semelhantes, mas voc\u00ea pode facilmente adaptar essa abordagem \u00e0s necessidades do seu projeto e da sua empresa.<\/p>\n

Existem duas variantes de avalia\u00e7\u00e3o de arquitetura.<\/p>\n

Interna<\/b> \u2013 geralmente fazemos isso para projetos dentro da empresa. Qualquer projeto pode solicitar uma avalia\u00e7\u00e3o de arquitetura por v\u00e1rias raz\u00f5es:<\/p>\n

    \n
  1. A equipe pensa que seu projeto \u00e9 perfeito e isso \u00e9 suspeito. J\u00e1 tivemos casos em que, frequentemente, em tais projetos, tudo n\u00e3o est\u00e1 t\u00e3o perfeito.<\/li>\n
  2. A equipe quer verificar seu projeto e suas decis\u00f5es.<\/li>\n
  3. A equipe sabe que tudo est\u00e1 ruim. Eles podem at\u00e9 listar os principais problemas e raz\u00f5es, mas querem obter uma lista completa de problemas e recomenda\u00e7\u00f5es para melhorar o projeto.<\/li>\n<\/ol>\n

    \nExterna<\/b> \u2013 \u00e9 um processo mais formal do que a avalia\u00e7\u00e3o interna. O cliente vem somente quando as coisas est\u00e3o realmente ruins. Normalmente, o cliente entende que existem problemas globais, mas n\u00e3o consegue identificar corretamente as causas e desmembr\u00e1-las.<\/p>\n

    A avalia\u00e7\u00e3o de arquitetura para um cliente externo \u00e9 um caso mais complexo. O processo deve ser mais formal. Os projetos s\u00e3o sempre grandes e antigos. Eles t\u00eam muitos problemas, bugs e c\u00f3digo defeituoso. O relat\u00f3rio do trabalho realizado deve ser preparado em algumas semanas, no m\u00e1ximo, onde devem estar os principais problemas e recomenda\u00e7\u00f5es para melhorias. Portanto, se conseguirmos resolver a avalia\u00e7\u00e3o externa do projeto, a interna ser\u00e1 apenas uma quest\u00e3o simples. Vamos considerar o caso mais complexo.<\/p>\n

    Avalia\u00e7\u00e3o de Arquitetura de um projeto enterprise<\/h2>\n

    \nUm projeto t\u00edpico de avalia\u00e7\u00e3o \u00e9 um grande projeto de enterprise antigo com muitos problemas. O cliente nos procura e pede para consertar seu projeto. \u00c9 como um iceberg; o cliente v\u00ea apenas o topo de seus problemas e n\u00e3o percebe o que est\u00e1 abaixo da superf\u00edcie (na profundidade do c\u00f3digo).<\/p>\n

    Problemas que o cliente pode relatar e dos quais pode estar ciente:<\/p>\n