Esse artigo não é um resumo do livro, é minha impressão sobre o conteúdo e quais foram os pontos que achei mais importantes. Assim como conteúdos que eu senti falta ou algo com que não concordei.
Esse livro para mim é sobre um projeto de software, porém encarando o projeto de software como uma ciência, e deixa claro que é possível encarar dessa forma.
Os primeiros capítulos o autor decide definir o que é um software, depois o que é ciência, para então definir o que é um projeto. Depois de ter essa base o autor define o que é um um projeto de software. Para então começar a dar sua visão como criar um bom projeto de software. Dessa forma o livro consegue ser útil para um leque maior de pessoas, pois não exige um conhecimento prévio dos leitores.
O livro defende que o software serve para ajudar pessoas, esse é o valor principal do software. Logo, um bom projeto de software é um projeto que mantém o software ajudando as pessoas pelo maior tempo possível e da melhor forma possível. Para isso os projetistas precisam transformar complexidade em simplicidade, desta forma a manutenção e extensão do software se torna um processo mais fácil, assim gerando menos bugs... consequentemente ajudando mais as pessoas.
Muito bonita essa visão, mas passar essa visão é em certo nível, muito simplório, é preciso um conhecimento mais profundo para conseguir projetar um software com uma arquitetura simples resolvendo problemas complexos. Você imagina a complexidade de lidar em um software contábil que tem que lidar com leis municipais, estaduais, federais no setor tributário, contábil e trabalhista? Adianto que não é algo simples.
Em minha visão o livro entrega esse valor mais técnico, mostrando exemplos de projetos que se tornam complexos, exemplos de projetos que falham antes de serem lançados e projetos que constantemente quebram por não ter a manutenção realizada de forma efetiva. Mostra até quando é válido refazer um projeto. Explica também quais técnicas devemos aplicar para manter nosso software simples.
O livro entrega tanto a assunto mais conceitual quanto o assunto mais aprofundado, ao menos que focado mais na tomada de decisão do que nos código em si
Se fomos generalizar temos dois tópicos que abrangem as leis fundamentos explicitas no livro, priorização e over engineering. São assuntos bem debatidos já na área de TI, mas é bom ver eles serem discutidos na literatura também.
Priorização: Nos é apresentado como priorizar levando em conta manutenção da feature, esforço inicial, entrega de valor aos usuários a curto e longo prazo. Uma má-priorização das atividades do time de TI e uma má-compreensão de como o usuário enxerga cada funcionalidade pode custar alguns milhares/milhões de reais ou até mesmo reduzir a vida útil do software. O livro tenta nos afastar dessas más decisões.
Over engineering: Um grande terror para o CTO, um sonho para o programador e uma confusão para o usuário. Temos exemplos do que pode ser considerado uma extrapolação do time técnico, muitos ligados a tentativa de evitar trabalho no futuro, tentando prever uma demanda que não temos certeza que virá. Ou, ás vezes, tentamos criar uma arquitetura tão genérica que ela se torna falha, quando originalmente deveria executar apenas uma função. O livro também nos guia como projetar o software na medida certa, evitando trabalhos desnecessários.
Minha visão sobre o livro
No sentido de nos guiar nas tomadas de decisões relacionadas ao projeto de software o livro é bem definido, é um guia, principalmente para iniciantes.
O livro não alcança alguns outros tópicos relacionados ao projeto de software, como por exemplo, aspectos mais relacionados a implementação do código em si, e nem está em sua proposta dissertar sobre esses aspectos, e isso fica claro na leitura. Evitando frustar o leitor. Por exemplo, Como implementar uma transação bancária em nosso software de forma simples? Para buscar respostas nesse sentido será necessário buscar outras literaturas. E tudo bem.
No geral é uma leitura recomendável e super bem-vinda em qualquer momento da carreira, tanto para programadores, mas também para qualquer profissional que influencie no direcionamento do software no dia-a-dia.
Minha crítica ao livro
O livro se propõem a tratar o assunto como ciência, mas no final se mostra como uma visão pessoal do autor, que também seria válida desde que se encarasse dessa forma. O autor não revela de onde tirou suas conclusões, não demostra metodologia para suas afirmações e nem se apoia em nenhum trabalho passado, o que para o método cientifico é muito suspeito.
Top comments (0)