Abstração e polimorfismo na prática

No documento “The new Methodology” [4], Martin Fowler traz uma excelente visão sobre um novo estilo de desenvolvimento de software, baseado em metodologias ágeis. Metodologias tradicionais de engenharia de software, focadas em planejamento, têm sido utilizadas ao longo do tempo. O grande problema é que elas são muito burocráticas, dão ênfase em contratos fixos, documentação excessiva, vasto planejamento antecipado (prematuro). Essa abordagem não condiz mais com a realidade da maioria dos projetos na área de tecnologia, onde novos requisitos são criados, modificados ou mesmo removidos após um planejamento inicial. Processos e metodologias modernas, como as metodologias ágeis de desenvolvimento, são evolutivos por natureza. Organizam o trabalho de forma interativa, realizado em pequenas partes, com pequenas entregas (design, código, teste, documentação), liberadas aos poucos, ao invés de um único release enorme. Dão maior ênfase na colaboração e comunicação aberta e fluente entre stakeholders, clientes e membros do time, minimizando as chances de insucesso em projetos. Os princípios básicos da abordagem ágil sugerem que indivíduos e interações são mais importantes que processos e ferramentas, trabalho deve ser feito mais focado no software em si que em uma documentação abrangente, colaboração do cliente mais que negociação de contrato e, principalmente, responder a mudanças mais que seguir um plano.

O problema é que as abordagens tradicionais de engenharia de software se baseiam em outros ramos de engenharia, como a civil e mecânica, onde os custos com planejamento são menores. Em software, estima-se que até 50% de custos são gastos com design e planejamento. Projetos com um escopo invariável são raros, e se requisitos constantemente mudam, há um grande desperdício de esforço com análise que é descartada em virtude disso. Trabalho, tempo e dinheiro que são preciosos são perdidos. Uma abordagem ágil garante que a equipe e projeto sejam capazes de se adaptar às mudanças que ocorrerão, dentro de um contexto evolutivo.

A XP – Extreme Programming, uma abordagem ágil, prega cinco valores principais: comunicação, feedback, simplicidade, coragem e respeito, com foco maior em disciplina do que processos. Já Scrum prega um desenvolvimento ágil baseado em iterações chamadas sprints e reuniões de acompanhamento frequentes (meetings). Aplicações reais precisam continuamente ser evoluídas, novos requisitos implementados, melhorias devem ser feitas no projeto existente (design), algumas vezes é necessário mudar de tecnologia ou plataforma, corrigir bugs, otimizar e melhorar a performance. Isso remete a uma pergunta: O que pode ser considerado um “bom software”? Um bom software é aquele que funciona como planejado, mas depende do seu negócio. Para pequenas companhias (startups), bons softwares devem ser criados rapidamente. Para grandes corporações, o foco na construção de um software é torná-lo fácil de ser mantido ao longo do tempo. Nesse sentido, é necessário tomar cuidado com bons princípios de design, como criar componentes com baixo acoplamento, reutilizáveis, que garantam que alterações em componentes não afetam outros, que objetos tenham responsabilidades únicas, separadas, partes facilmente substituíveis, complexidade encapsulada. Esses são princípios básicos da programação orientada a objetos que, vistos dentro de um contexto de uma abordagem ágil evolutiva, vão tornar o sistema de software mais fácil de testar, evoluir, manter e entender. Padrões de Projeto (Design Patterns) [1] ajudam a criar bons designs de software, já o uso de refatoração [2] contínua (outra técnica amplamente divulgada por Fowler) garante código claro, limpo e funcional em equipes que programam de forma mais ágil, sem se preocupar em um primeiro momento com muitos aspectos de design, usando, por exemplo, Padrões de Projeto.

Padrões de Projeto são soluções reutilizáveis para problemas recorrentes no desenvolvimento orientado a objetos. Aplicar padrões antecipadamente em um projeto requer mais tempo e aumenta custos, ao mesmo tempo em que aumenta sua complexidade. Requisitos são modificados, criados ou mesmo eliminados conforme projetos evoluem. Tentar aplicar padrões antecipadamente para prever essas mudanças é um problema conhecido como excesso de engenharia [3]. Já projeto em escassez reduz custos, pois o sistema de software é criado rapidamente devido à falta de tempo, conhecimento ou necessidade de se adicionar funcionalidades em curto prazo. Ao longo do tempo, armazena-se um débito de projeto [3], que torna o sistema de software muito difícil de ser mantido e evoluído. É nesse contexto que entram as refatorações, como uma forma de melhorar o projeto existente sem alterar seu comportamento externo observável. Refatoração é o aspecto-chave para um projeto evolutivo, e é na evolução que se encontra a verdadeira sabedoria. Nesse caso, desenvolvimento ágil, evolutivo, incremental, apoiado em refatorações e testes, é uma excelente receita para garantir o sucesso do projeto, seja ela para um startup ou uma grande corporação."