Kent Beck, um dos autores originais do Manifesto Ágil para Desenvolvimento de Software, deu a palestra de encerramento no QCon San Francisco de 2022. O título de sua palestra foi “Tidy First?”, que também é o nome de seu próximo livro.
Ele começou apresentando sua missão pessoal de “ajudar os geeks a se sentirem seguros no mundo”, o que ele explica em um post no Facebook.
Ele falou sobre ter relido recentemente o livro de Design Estruturado de Ed Yourdon e Larry Constantine. Ele descreve o livro como contendo as leis de Newton para o desenvolvimento de software; os conceitos e ideias são tão relevantes para a programação hoje como eram quando o livro foi publicado pela primeira vez. O livro introduziu os conceitos de acoplamento e coesão, que continuam sendo um desafio para a engenharia de software hoje, assim como eram quando o livro foi publicado em 1975.
Ele diz que passou os últimos 17 anos aprendendo a explicar a coesão no design de software, o que o levou a escrever uma série de três livros que explorarão o design de software. Os livros podem ser acessados à medida que o conteúdo é lançado no Substack.
Ele diz que:
O design de software é um exercício em relacionamentos humanos.
E é explorando esses relacionamentos que os sistemas de software ganham vida no mundo.
O primeiro relacionamento é entre a ideia sendo explorada e o comportamento que trará essa ideia à vida. O relacionamento é bidirecional e evolutivo – a ideia define o comportamento e a existência do comportamento pode gerar mais ideias (“agora que vejo isso, que tal aquilo…”). Abaixo da ideia e do comportamento está a estrutura do sistema. Esta é a arquitetura, e ela tem um efeito profundo no comportamento visível.
A estrutura do sistema tem um efeito profundo no comportamento e nas ideias que são geradas, porque o comportamento pode mudar. A estrutura influencia o comportamento, o que resulta em novas ideias pedindo mudanças no comportamento que podem afetar a estrutura, em um processo contínuo. O fluxo de trabalho “Tidy First?” nos faz pausar e perguntar se a estrutura precisa ser alterada ou se devemos apenas implementar a mudança de comportamento. Se a mudança precisar impactar a estrutura, então arrume a estrutura primeiro – refatore a arquitetura subjacente conforme necessário. NÃO tente fazer mudanças na estrutura e comportamento ao mesmo tempo, pois é aí que os sistemas se tornam endividados tecnicamente.
Ele diz que existem dois pontos de vista envolvidos quando os sistemas estão sendo construídos, especialmente quando precisam ser modificados. As duas perspectivas são aguardadores e modificadores. Os aguardadores têm a ideia e querem que o comportamento faça a nova coisa o mais rápido possível; os modificadores precisam manter o código e querem arrumar a estrutura primeiro para que a mudança de comportamento possa ser feita com segurança.
A complexidade aumenta ainda mais quando há vários modificadores que cuidam de áreas diferentes do mesmo produto. É provável que os incentivos dos aguardadores e os incentivos concorrentes dos diferentes modificadores estejam em tensão.
As habilidades de design de software são sobre manter bons relacionamentos entre fabricantes díspares e entre os modificadores e os aguardadores.
A pergunta com a qual um modificador se depara ao receber uma solicitação de mudança em um produto normalmente resulta em “este código está bagunçado – devo arrumá-lo antes de fazer as mudanças?” A resposta para essa pergunta muitas vezes é “depende” – queremos que a mudança seja feita o mais rápido possível E queremos manter a base de código livre de dívidas técnicas. Infelizmente, você não pode ter os dois. Uma decisão precisa ser tomada, e a resposta correta deve ser “depende”.
Ele desenhou essa imagem para ilustrar os diferentes relacionamentos no ecossistema de aguardadores e modificadores:
Em seguida, ele explicou por que o design detalhado inicial era uma ideia ruim nos anos 1990 e ainda é uma ideia ruim nos dias de hoje. Ele disse que a abordagem cascata está de volta e algumas organizações estão novamente tentando definir o sucesso para o desenvolvimento de software em termos de tempo, custo e escopo definidos antecipadamente, e como o desenvolvimento iterativo e incremental sempre foi a abordagem economicamente mais viável para a construção de sistemas de software, e ainda mais nos dias de hoje.
Ele discutiu como a Equivalência de Constantine mostra que o custo efetivo de um sistema de software é o custo de modificá-lo. Ao longo da vida útil do sistema, o custo de mantê-lo tornará o custo inicial de desenvolvimento uma parte trivial do investimento total. Ele então mostrou como o custo de manter um produto está diretamente relacionado ao custo do acoplamento no sistema. Onde uma mudança feita em um elemento do sistema causa uma mudança em cascata em outro elemento, que causa uma mudança em outro elemento e assim por diante…
O custo geral do sistema pode ser visto como o custo desse acoplamento mais o custo de desacoplar os elementos do sistema (ele usou o termo elementos para indicar que a natureza real do código é irrelevante nesse contexto – pode ser funções, procedimentos remotos, microservices ou qualquer outro componente que tenha dependências).
A estrutura subjacente (arquitetura, design) do sistema é o fator mais importante na equação de acoplamento/desacoplamento.
Ao considerar as mudanças em um sistema, a maioria provavelmente será feita em áreas que não têm muitos acoplamentos em cascata, no entanto, é provável que haja algumas mudanças ao longo da vida do produto que são mudanças jackpot – aquelas em que a cascata de acoplamentos é tão grande que o custo de fazer a mudança é astronômico. Essas mudanças jackpot provavelmente constituem a grande maioria dos custos de manutenção do sistema ao longo de sua vida útil.
Ele terminou incentivando a audiência a fazer mudanças em pequenos incrementos, a manter a estrutura de seus sistemas limpa e o mais desacoplada possível, e a adotar uma abordagem “Tidy First” para a manutenção de software.
Esse artigo é a tradução do artigo original: Kent Beck: Software Design is an Exercise in Human Relationships
Deixar um comentário