Nossa maior limitação na hora de escrever um código é a habilidade de entender o que estamos criando.
- John Ousterhout
Essa é uma das frases da introdução do livro A Philosophy of Software Design que iniciei a leitura recentemente. A frase da inicio a argumentação sobre o que rege o desenvolvimento de software.
Essas notas serão livres, não se propõe a serem um resumo do livro.
Como o próprio nome já diz soft, de maleável, trás a ideia de que o software pode mudar e que é fácil de mudar. De fato nós podemos adicionar mais funcionalidades, isso é simples, porém, elas podem vir carregadas de dependências e de complicações, gerando complexidade.
É fato que a complexidade aumenta com o ciclo de vida de uma aplicação, quanto maior um sistema e quanto mais pessoas trabalham nele, maior a dificuldade em gerenciar a complexidade. No entanto, um design simples nos ajuda a entender e realizar esse gerenciamento, sem que isso se torne cansativo.
Para diminuir essa complexidade nós temos duas abordagens. A primeira é no design do código, criando algo simples e óbvio. A segunda abordagem foca na modularização do sistema, de uma forma em que as partes do sistema são encapsuladas e não há necessidade de lidar com toda a complexidade de uma vez. Geralmente esses módulos são desenhados para serem independentes um do outro.
A maioria dos projetos de software usam uma abordagem incremental, que vem do agile development. Essa abordagem foca em desenvolver pequenos tópicos da funcionalidade geral do sistema. Conforme ele é implementado, é avaliado a implementação e seus resultados. A partir disso é determinado se há necessidade de mudanças. Apenas após a aprovação é que a próxima etapa inicia. Um desenvolvimento incremental significa que o design do software nunca está concluído, que é um processo continuo, até o fim do ciclo de vida do sistema.
Com isso, nós, desenvolvedores, temos algumas obrigações com o design do sistema que estamos mantendo:
- O design acontece de uma forma continua no ciclo de vida de um sistema, por isso devemos sempre estar pensando em problemas de design.
- Nós devemos sempre estar procurando por oportunidades de melhorar o design do sistema em que estamos trabalhando, e devemos sempre planejar gastar uma fração do nosso tempo nessas melhorias de design.
- Se nós devemos sempre estar pensando sobre problemas de design, e a redução de complexidade é a coisa mais importante no design de software, então podemos concluir que nós, devemos sempre estar pensando sobre complexidade.
Vale ressaltar também que: o design inicial de um sistema ou de um componente nem sempre é o melhor, a experiência inevitavelmente vai nos mostrar uma melhor forma de fazer as coisas.
Conclusão
A melhoria do design e o controle de complexidade de um software é um trabalho continuo. Vale pensar em como lidamos com isso no ciclo de vida das nossas aplicações!
Top comments (2)
Bons pontos Matheus. O livro parece bem interessante, não o conhecia. Que tal compartilhar o link para o livro na amazon ao final do seu artigo?
Este tema (complexidade) é realmente uma área de muito debate. Existem correntes (como o TDD por exemplo) que advogam estratégias onde iniciamos sem muito desenho e a arquitetura emerge com o tempo (começamos muito simples e na medida em que o código cresce a refatoração vai ocorrendo e adicionando complexidade) e há outras que vão para o outro lado, sugerindo ser importante nascer com um grau X de arquitetura para diminuir o retrabalho e debitos técnicos no futuro. Será que este livro aborda um pouco sobre estas divergências? Qual sua opinião sobre isso?
O link para o livro está bem no comecinho, quando cito ele! =)
Pelo que pude olhar no sumário do livro ele fala um pouco sobre as estratégias de TDD, Design patterns e afins, mas creio que ele está mais preocupado em explorar o pensamento sobre o design do sistema, principalmente na visão do código escrito.
Acredito que a estratégia para iniciar um sistema é carregada de trade offs. No nosso mundo não existe uma estratégia a prova de balas. Cada sistema possui seu contexto e as finalidades que precisa atingir. Acredito que cada sistema possui seu pilar e isso é definido de forma explicita ou implícita. Esse aqui é um exemplo disso: github.com/asouza/pilares-design-c....
Uma empresa que aplica esses pilares explicitamente é a StackOverflow e a Roberta Arcoverde (twitter.com/rla4) fala bastante sobre isso aqui no Brasil. Essa aqui é uma live explicando: youtube.com/watch?v=-cYsHoUfFwE