Radar de Tecnologia

Uma nova edição do Technology Radar da ThoughtWorks foi publicada ontem

https://www.thoughtworks.com/content/dam/thoughtworks/documents/radar/2023/09/tr_technology_radar_vol_29_en.pdf

Para surpresa de ninguém, IA é o grande tema desta edição, eu entretanto fui atraído por 2 itens:

Mermaid

Mermaid está no quadrante de adoção.

https://mermaid.js.org/

No meu projeto atual usamos documentação-como-código desde o inicio, exceto que a nossa escolha foi PlantUML. O que eu posso comentar da minha experiência, em 3 aspectos:

  • Consistência: Ao tratar a documentação como código, torna-se mais fácil manter a consistência entre o código e sua documentação, especialmente no que tange à arquitetura de software. Utilizamos C4 e quando fazemos mudanças estruturais, os diagramas e o novo código são versionados no mesmo PR, mostrando exatamente a evolução do sistema;
  • Colaboração: Entre engenheiros é ótimo pois soa mais natural editar a documentação no mesmo fluxo com que o software é editado. Fora do mundo dos engenheiros, há uma barreira pois é necessário saber o markup e uma interface point-and-click é mais intuitiva. Isto fica evidente na discussão do contexto do software, em que é necessária a interação com os colegas de negócio;
  • Automação: Aqui é o ponto em que a documentação-como-código brilha. Se a cultura dos times incentiva comentários no seu codebase, vários diagramas podem ser gerados automaticamente.

Complexidade

Para mim é difícil concordar com o argumento de que devemos abraçar a complexidade em desenvolvimento de software. Complexidade é algo que deve ser combatido no seu design, na sua implementação, no seu processo. Utilizando o Cynefin, nosso objetivo é transicionar do complexo para o complicado e, veja, o artigo utiliza AI como um exemplo de complexidade porém AI opera no complicado, ao utilizar padrões e conhecimento para tomar decisões.

Neste tópico, eu lembro do Dumbledore falando para o Harry: “Soon we must all face the choice, between what is right and what is easy”. O trabalho de um arquiteto, e todos os engenheiros são arquitetos em alguma escala, é resistir à tentação da solução fácil; é comum nestas situações introduzir complexidade acidental. Se estamos falando de complexidade essencial, ok, ainda assim, devemos lutar para diminuí-la. Mas eu não culpo a ThoughtWorks pela abordagem, o Dijkstra já dizia “complexity sells better”.

https://www.thoughtworks.com/en-us/insights/blog/technology-strategy/why-embracing-complexity-real-challenge-software-today

Leiam o Radar, sempre é interessante especialmente confiram o que está próximo do nível de adoção.