Bom pessoal, no vídeo anterior a gente falou sobre as leis de... as leis não, a lei de Postel, ou seja, a gente. Ela foi criada, e reza a lenda que ela não foi criada apenas por Leman, ela foi criada também por Belade em 1974. Inclusive, eu estou deixando aqui embaixo o paper onde tem essa lei explicada e com todos os detalhes aqui. Desses oito itens dessa lei, dessas leis, eu quero trazer quatro aqui que eu acredito que fazem muito sentido na hora de você criar o seu software e fazer com que o seu software dure bastante tempo. E fazer com que o seu software dure bastante tempo. E são alguns pontos que realmente são óbvios, mas que fazem muito sentido para você conseguir dar um outro olhar para o seu software e você ressignificar muita coisa. Então, quais são essas leis aqui? Uma lei aqui que a gente chama é a lei da mudança contínua. A lei aqui que a gente chama é a lei da mudança contínua. Um sistema de software deve se adaptar às mudanças em seu ambiente. Caso contrário, sua eficácia diminuirá ao longo do tempo. Óbvio, né? Ou seja, lei da mudança contínua. Se o seu software está parado faz muito tempo, provavelmente é porque a sua empresa está começando a utilizar outro software. Provavelmente é porque esse software já não está atendendo tão bem a sua empresa. Software é algo que muda o tempo todo. Então, se não está mudando, tem algo errado. Quanto tempo faz que você deu o último commit em um determinado software? Faz muito tempo? Dá uma revisada nisso aí, porque normalmente tem coisa errada, você vai ver que esse software está sendo pouco atualizado. Outra lei aqui interessantíssima, lei do crescimento da complexidade. O que ele fala? Fala que à medida que um sistema evolui, sua complexidade tende a aumentar, a menos que haja um esforço explícito para reduzi-la. Olha só que interessante, galera. Imagina que todo dia tem mudanças no seu software. Você vai perceber, e eu acredito que você já sabe disso, que quanto mais você mexe, mais complicado vai ficando o software ao longo do tempo, e você vai tendo mais dificuldades lá na frente. O que essa lei quer dizer aqui para você do crescimento da complexidade? Como que eu evito o crescimento da complexidade? Eu evito aumentar a complexidade fazendo uma luta explícita contra ela. O que isso significa? Significa que o software ele não pode ser apenas um cara que você está pensando em adicionar coisas novas, mas ele tem que ser um cara que muda continuamente e briga para se melhorar o tempo todo para que nas próximas iterações as mudanças não fiquem cada vez mais complexas. Ou seja, você gerou um monte de feature, opa, vamos trabalhar agora, depois que essa feature está em produção, para como que eu deixo isso mais simples. Por quê? Porque na próxima feature, o meu nível de complexidade vai estar igual ao longo do tempo. Se o nível de complexidade do seu software está aumentando ao longo do tempo, é porque você não está fazendo de forma intencional um processo para diminuir essa complexidade. Então, se o seu software cada vez fica mais complexo, a culpa é sua. Entre aspas, brigue com a complexidade, faça melhorias no seu software, e nem que essas melhorias não tragam necessariamente nenhuma feature mas essa melhoria é a melhoria que aquela história plantar para colher você vai estar plantando quando se briga com a com a complexidade porque porque quando você planta lá na frente na próxima feature você não vai ter dificuldade, entre aspas, para fazer, porque a terra está pronta ali para o novo plantio. Se você só colhe, só colhe, só colhe uma hora, você não vai conseguir colher nada, porque o chão não está pronto para você. Bacana? Vamos lá, a outra lei aqui, que é a lei da conservação da familiaridade. O que a lei da conservação da familiaridade fala? Que o conteúdo global de um sistema de software deve ser mantido em um nível que seja familiar para os desenvolvedores envolvidos na sua solução. Se você participa de um projeto, e na hora que você for trabalhar nesse projeto, existem coisas ali que não fazem sentido para você, você olha ali e fala, cara, isso aqui é totalmente novo, não sei de onde está vindo. Você está fazendo um módulo, o outro cara está fazendo outro módulo, e quando você vê, parece que uma coisa não fala com a outra, não sei de onde que está vindo você está fazendo um módulo o outro cara está fazendo outro módulo e quando você vê, parece que uma coisa não fala com a outra, não se encaixa ou seja, quando você olha para o software, o seu software parece um estranho para você mesmo, significa que você está quebrando essa lei e isso vai fazer com que isso prejudique a evolução do software, se o software está começando a ficar esquisito para alguns membros do time, é porque você está quebrando essa lei da conservação da familiaridade. Então a gente falou, deixa eu só voltar aqui, lei da mudança contínua, a gente falou lei do crescimento da complexidade, da conservação da familiaridade, e a gente tem mais uma aqui, que é a lei da conservação do esforço. O esforço total para implementar e manter um sistema de software aumentará ao longo do tempo, mesmo que a quantidade de funcionalidades adicionais permaneça constante. Esse aí, galera, é um ponto que é muito complexo né quando o seu software você tinha uma funcionalidade você for colocar a segunda você teve um esforço para fazer da segunda para a terceira também da terceira para quarta também mas você vai começar a perceber que quanto maior o software vai ficando né mesmo que você não esteja adicionando novas funcionalidades você vai perceber que pra implementar e manter esse sistema vai ficando mais difícil porque Porque você não está conseguindo conservar o esforço. O seu esforço começa a ficar desproporcional ao longo que o software cresce. E eu acredito que se você já trabalhou no sistema legado, você já sabe o que a gente quer dizer. O cara pede para você mudar um campo e você tem um trabalho danado para fazer essa mudança. Por quê? Porque o software vem de muito tempo, às vezes tem um acoplamento muito alto, não está familiar, ele está difícil para dar manutenção. Então você começa a perceber que até mesmo coisas simples começam a ficar mais complicadas para você trabalhar. Pessoal, por que tudo isso que eu estou falando para vocês é importante? Eu não tenho dúvidas que isso vai mudar a forma de você ressignificar o seu software. Um arquiteto de software não está preocupado apenas em como colocar código. Ele está preocupado em metrificar. Ele está preocupado em manter. Ele está preocupado em conseguir fazer com que esse software fique fácil, até no onboarding de pessoas no time. Então, quando você começa a ler cada coisa dessa, você vai tendo insights. Putz, essa parte está esquisitona do meu software. Vamos deixá-la mais familiar? Olha, está ficando muito difícil para mudar isso. Vamos trabalhar para a gente conseguir ser mais eficiente, para quando a gente for criar uma funcionalidade não dar tanto trabalho? Então, esses tipos de coisa são extremamente importantes. E um dos papéis, inclusive, do arquiteto de software, de um tech lead, de um desenvolvedor sênior pleno, é o quê? É ter carinho, ter zelo por aquilo que você faz. Ter profissionalismo. E para você fazer isso, você tem que ter noção dessas vertentes que a gente acaba falando. É isso aí.