Acabo de responder um questionário de um aluno do Mackenzie sobre design patterns, que será utilizado em seu trabalho de conclusão de curso. Era curto (e isso é pré-requisito, ou eu não responderia), composto de apenas sete perguntas rápidas. Ele entrou em contato com alguns dos artigos que ando publicando sobre o assunto, e pediu meu feedback.

E porque estou contando isso pra vocês? Porque a terceira pergunta era essa:

Em algum projeto, durante a fase de análise, já foi detectado que a melhor solução era a não utilização de Design Patterns?

Fase de análise? Alguém ainda acredita em fase de análise? Parafraseando um twit meu, eu acredito em duendes, mas não acredito em fases de análise.

Minha resposta ao universitário:

Não entendo que exista uma “fase de análise”. Isso leva a um modelo de desenvolvimento em cascata, que é prejudicial. E a analise arquitetural, que é feita um pouco antes do código, não deve chegar ao ponto de definição de padrões de codificação, mas sim a padrões arquiteturais. E mesmo essa, deve ser feita de forma incremental.

Não me estendi demais no comentário porque a pergunta já foi feita errada. Não é a primeira vez que entro em contato com conteúdo acadêmico fundamentado em práticas waterfall. As universidades, em sua grande maioria, estão presas à idéia de que construir software é igual a construir carros em uma fábrica, ou a construir uma ponte. Não é.

Temos que parar de “analisar o negócio” e voltar a escrever código. Milhões se gastam em papel, e proporcionalmente muito pouco em código funcionando. O overhead gasto em arquitetura, análise de negócio, análise de sistemas, documentação, gestão de projetos é grande demais. Tudo isso devia acontecer apenas como suporte do produto final funcionando. Temos que fazer análises arquiteturais, de sistemas, de negócio? Claro! Temos que ter uma fase para elas? Não, de forma alguma.

As universidades ensinam pouco aos estudantes, e quando dão para ensinar, ensinam isso: técnicas anacrônicas, despreparadas para a realidade. Os alunos chegam ao mercado de trabalho com a cabeça enviesada a favor de técnicas que não funcionam, e, dependendo da faculdade, ideológicamente estragados (principalmente se forem faculdades públicas).

Posso falar com autoridade sobre o assunto. Tenho aplicado, em paralelo à consultoria de arquitetura, também consultoria em agilidade. É comum o cliente entender a arquitetura, mas ainda ter problemas com processo, e acaba me perguntando como resolver, e aí aparece a consultoria de processo. Os resultados são impressionantes, e sempre muito positivos. E garanto: não existe fase de análise em projeto focado na entrega, ágil, produtivo.

Há muito o que caminhar ainda para que tenhamos uma profissão, para que possamos chamar nossa prática de desenvolvimento de software pelo nome de “profissão”. Por enquanto, o que temos são discussões dispersas, práticas sem comprovação, e, sem dúvida alguma, ego demais.

Giovanni Bassi

Arquiteto e desenvolvedor, agilista, escalador, provocador. É fundador e CSA da Lambda3. Programa porque gosta. Acredita que pessoas autogerenciadas funcionam melhor e por acreditar que heterarquia é mais eficiente que hierarquia. Foi reconhecido Microsoft MVP há mais de dez anos, dos mais de vinte que atua no mercado. Já palestrou sobre .NET, Rust, microsserviços, JavaScript, TypeScript, Ruby, Node.js, Frontend e Backend, Agile, etc, no Brasil, e no exterior. Liderou grupos de usuários em assuntos como arquitetura de software, Docker, e .NET.