Funcional, procedural, orientado ao objeto?
Qual paradigma usar no seu projeto?
Hoje em dia existem diversas formas de fazer a mesma coisa. Com a evolução da tecnologia também evoluiu a forma de escrever código. Atualmente existem diversos paradigmas, tecnologias, linguagens e padrões que são ferramentas valiosas para desenvolver software. Porém, qual é a que você deve usar no seu projeto?
O Melhor Paradigma
O melhor paradigma é aquele que vai lhe dar menos trabalho para atingir seus objetivos e que vai levá-lo a um código simples, eficiente e eficaz. No fim das contas não tem a menor importância qual paradigma você utilize contanto que os requerimentos do cliente sejam corretamente implementados.
O melhor paradigma é aquele que custa menos para resolver o problema do cliente.
Pode parecer conversa de gambiarreiro, mas não é. Com grande sofisticação vem grande complexidade. E com grande complexidade vem grandes custos de manutenção, tanto evolutiva quanto corretiva. Infelizmente, vários developers esquecem que desenvolvem uma atividade produtiva e, com isso, esquecem-se que precisam justificar o seu salário para o seu empregador. No caso do developer ser dono do próprio negócio, é preciso maximizar o lucro e isto é feito com qualidade e simplicidade.
Trocando em miúdos: o melhor paradigma é aquele que custa menos para resolver as dores do cliente.
Simplicidade ≠ Gambiarra
Código simples não é código gambiarrado. Código simples quer dizer que pensou-se na solução mais simples que resolve o problema. Este é, em última instância, o objetivo de toda engenharia: resolver um problema complexo da forma mais simples possível. Pergunte a um engenheiro aí do seu lado se estou mentindo.
Simplicidade não é, também, facilidade. As soluções simples são as mais difíceis de encontrar, mas valem a pena do ponto-de-vista financeiro: você escreve menos, o seu código fica mais simples e a manutenção fica mais barata.
Por que falar em dinheiro?
O tempo que todo desenvolvedor gasta para escrever código novo é pago pelo cliente. Se não for assim, trabalha-se de graça. Todo o lucro auferido da venda do esforço de desenvolvimento vai pelo ralo se o programador precisa resolver defeito atrás de defeito. Por isso que gambiarra é uma péssima ideia.
Gambiarra é uma péssima ideia.
Quando o seu código é sofisticado demais, o resultado é que a manutenção tanto corretiva quanto evolutiva serão, igualmente, sofisticadas. E sofisticado quer dizer: mais horas de trabalho. E isto quer dizer: mais caro. Se olharmos um pouco para fora, veremos que a concorrência vai fazer mais barato para tomar o seu cliente para si. Ao tomar o seu cliente, você tem uma fonte de receita a menos e pode chegar ao dia em que será necessário começar as demissões para que a empresa continue viva no mercado.
Paradigmas sofisticados são mais caros
Se você optar por usar paradigmas de desenvolvimento muito sofisticados, prepare-se para pagar mais caro por isso, a começar pela contratação de mão-de-obra capacitada. Quanto mais sofisticado é o seu paradigma, mais caro é o developer que o domina. Consequentemente, mais cara será a sua solução e maior será seu preço no mercado.
Resultado? Se a concorrência conseguir desenvolver a mesma solução por um custo mais baixo que o seu, provavelmente você estará em maus lençois.
Empreendedorismo de mãos dadas com o desenvolvimento de software
É um assunto quase recorrente nos meus artigos a questão financeira ligada ao desenvolvimento de software. E não é para menos: o que fazemos, enquanto profissionais de TI, é criar valor para que empresas possam crescer e se beneficiar disso. E quando falo empresas, falo das comunidades que as cercam: empregados, donos, stakeholders, investidores, clientes, fornecedores…
Eu só cheguei à essa visão depois que me tornei empreendedor, há cerca de 9 anos atrás. Foi quando comecei a entender que as minhas soluções sofisticadas tinham pouco valor no mercado pois o mercado procurava eficácia e não beleza técnica.
O mercado procura eficácia e não beleza técnica.
Claro, nós como profissionais de TI queremos dar o nosso melhor para escrever as nossas soluções. Porém, é preciso que essas soluções sejam as mais baratas possível e isso inclui deixar de lado um pouco do egocentrismo e escrever coisas mais simples.
Código de baixa qualidade é muito caro.
E quando falo barato, não estou falando de um código de baixa qualidade. Código de baixa qualidade não é, absolutamente, barato. Na verdade, é caro prá burro pois entra em um ciclo de manutenção corretiva sem fim. E quanto mais manutenção corretiva um código exige, mais caro ele fica. Quando falo em mais barato quero dizer: a solução eficaz com o menor custo possível. Isto implica:
- excelente qualidade de código, com baixa taxa de defeitos e desvios funcionais;
- eficácia na resolução do problema proposto;
- eficiência na resolução do problema proposto;
- uso racional de recursos, minimizando-se o que for possível.
Conclusão
Não importa qual paradigma você vai usar no desenvolvimento do seu projeto. O que importa é: qualquer que seja o que você decidir, que resolva as dores do seu cliente de forma eficiente, eficaz e no menor custo possível.
Fazer diferente disso é alimentar o próprio ego.
Happy Coding!