Falando um pouco sobre custos e a "melhor solução" para tudo


E aí, que decisão tomar?No desenvolvimento de aplicações, sites, e tudo o mais, é comum lidar com muito material falando sobre performance. "Vamos fazer desta forma porque vai economizar 10ms do carregamento da página", "vamos usar essa plataforma pois vai permitir que a gente escale de 1 a 1000 servidores em 10 segundos", "vamos utilizar essa linguagem porque ela é assíncrona e vai permitir atender picos muito rapidamente". São muitas as escolhas que você realmente pode e na verdade deve fazer durante o desenvolvimento, mas, ao mesmo tempo que todo mundo fala dos pontos positivos, é raro você ver alguém falando sobre os custos e sobre as eventuais dificuldades que você vai enfrentar. E é sobre isso que eu vou falar um pouco hoje.

Afinal, como tomar a melhor decisão?

Se você já trabalhou no inicio de um projeto, com certeza já se deparou com inúmeras perguntas, que todo desenvolvedor se depara quando vai criar algo novo, do zero. Alguns exemplos de perguntas comuns são:

  • Que linguagem usar?
  • Escolhida a linguagem, usar ou não um framework? Se sim, qual?
  • Bom, escolhi a linguagem e se vou usar framework, mas, que banco de dados usar?
  • Escolhi a linguagem, framework e banco de dados. Agora que sistema de cache vou usar?
  • Sistema de cache escolhido! Agora, vamos ver que bibliotecas podem fazer isso aqui que quero fazer?

E assim vai. São muitas perguntas, as de cima são apenas algum exemplos, obviamente, mas, de todas as perguntas que podem surgir, com certeza as piores que podem acontecer são durante o projeto, quando você pára, vê uma solução possivelmente milagrosa e pensa "Putz, será que eu escolhi certo?".

Exemplo da relação de amor e ódio com um framework. Tirinha "The New Framework" feita pelo site Commitstrip
Exemplo da relação de amor e ódio com um framework. Tirinha "The New Framework" feita pelo site Commitstrip

Durante todos esses questionamentos, desenvolvedores costumam levantar inúmeros pontos. Muitos procuram por velocidade, outros, procuram por tamanho da comunidade, enquanto outros curtem muito quando veem algum post ou recomendação maneira para tomar aquela escolha em questão. Mas...como saber qual é a melhor resposta para cada pergunta acima? Bom, para isso, existem duas questões a se fazer, para cada pergunta acima:

    • Quais são os requisitos do projeto? Qual opção atende melhor eles?
    • Se todas as opções atendem os requisitos bem, em qual das opções você (e sua equipe) tem mais experiência?

Mas, por qual motivo apenas duas questões? Simples: Por mais entusiasmante que seja ter inúmeras opções e algumas opções prometerem mundos e fundos, de nada adianta se elas não se encaixam adequadamente nos requisitos do seu projeto e você realmente não tem experiência nelas.

Consigo citar isso com um exemplo bem válido: A escolha de SGBDs. Muitos programadores hoje, quando vão escolher um SGBD, se deparam com opções de bancos de dados que prometem coisas como escalabilidade fácil para centenas, milhares de servidores, schema inexistente (ou seja, sem necessidade de definir tabelas, colunas, etc. previamente), drivers para muita linguagens e facilidade de uso surpreendente. Aí o desenvolvedor, que anteriormente só trabalhou com SGBDs relacionais, cai na tentação e vai lá experimentar. Tudo para descobrir que..o modelo de dados do SGBD escolhido realmente não se adapta bem ao seu caso de uso, e opções de consultas que você tinha no SGBD relacional que usava se tornam um mártire de fazer no novo SGBD escolhido.

Outro exemplo é na escolha de linguagens de programação. Muitos se perguntam: "Nossa, que linguagem devo escolher?", e acabam caindo na tentação de experimentar fazer em uma linguagem que, embora todo mundo fale bem, o desenvolvedor não possui experiência o suficiente.

O que esses dois exemplos costumam resultar? Atrasos, atrasos, e mais atrasos.. E existem muitos casos no qual problemas do tipo ocorreram e tiveram que ser revertidos a pressa para não causar ainda mais problemas. Um clássico é o caso do Diaspora, uma rede social que resolveu usar um SGBD orientado a documentos e viu que, para o caso deles, isso não é totalmente mil maravilhas.

Qual é o aprendizado que fica? Simples:

Não existe uma solução que seja perfeita para todo e qualquer caso ou desafio que você tenha que enfrentar.

Portanto, não é porque existem usuários felizes e grandes usando que você precisa usar um projeto. Estude-o, primeiro, cuidadosamente, e verifique se ele é adequado para o que você precisa, procurando validar os requisitos que você tem com os projetos que você pretende usar.

Sobre os custos que decisões ruins provocam

Uma coisa importante relacionada a esse aspecto é que, muitas vezes, escolhas que não foram feitas da maneira mais adequada possível não impedem o desenvolvimento do projeto, como pode se pensar comumente. Ou seja, se você está desenvolvendo um projeto em um SGBD orientado a documentos mas que se encaixa melhor em um modelo de SGBD relacional, seu desenvolvimento raramente será impedido por isso. Entretanto, os variados custos (entendeu o por que de custo ser mencionado no titulo deste post?) relacionados ao projeto em questão aumentarão. Ou seja:

Decisões feitas incorretamente a respeito de um projeto tornam custos mais altos, em vez de mais baixos.

Mas, que custos são esses? Bom, são vários, e variam de projeto para projeto. Dentre os mais comuns, eu posso citar os seguintes custos:

  • Custo de desenvolvimento - Mais horas gastas desenvolvendo algo que poderia realmente ficar mais simples se decisões tivessem sido feitas com mais cuidado. Ou seja, você precisa se preocupar com mais fatores do que seria necessário. No caso do problema do SGBD com o Diaspora, por exemplo, no modelo relacional, quando alguém mudava o avatar do perfil, apenas um registro precisaria ser modificado, enquanto que no modelo orientado a documentos inúmeros registros precisam ser atualizados, tornando o custo de desenvolvimento (e performance, como vamos ver abaixo), maior, pois você precisa escrever mais código e garantir que mais coisas estão funcionando em conjunto;
  • Custos relacionados a performance - Sua aplicação pode ficar mais lenta (em vez de mais rápida) quando a decisão errada é tomada. Um exemplo é o citado acima, relacionado ao Diaspora. O que é mais rápido? Atualizar um registro ou atualizar mais vários? Pois bem, usando o modelo orientado a documentos, uma simples atualização de avatar implicaria em atualização de inúmeros registros, tornando assim mais lenta a aplicação para o usuário final e sobrecarregando os servidores de banco de dados, também;
  • Custos relacionados a hospedagem - Esse tem estreita relação com o custo  de performance. Oras, se você tem menos performance em uma aplicação, logo você precisa ou de servidores mais caros ou de mais servidores para poder deixar sua aplicação numa velocidade mais aceitável. Certo?

E esses são apenas os três custos mais comuns relacionados a decisões tomadas de forma incorreta durante o desenvolvimento do projeto. Com certeza há muito mais custos por aí, mas esses são os que normalmente se aplicam mais aos projetos em geral.

Sobre mudanças de decisão no meio do projeto

Por fim, mas não menos importante nessa história toda, gostaria de atentar para algo que normalmente programadores novos, ou mais curiosos, tendem a enfrentar: A falta de foco.

Imagine que você está programando, de boas, quando você de repente se depara com um novo framework/SGBD/qualquer outra coisa que seu projeto possa usar, que parece resolver todos os seus problemas de forma mágica. Bom..acho que a tirinha abaixo deixa bem claro o que acontece se você resolve mudar para esse novo framework/SGBD/qualquer outra coisa que seu projeto possa usar:

Tirinha "Side Project" feita pelo site CommitStrip
Tirinha "West Side-Project story" feita pelo site CommitStrip

Conclusão

No fim das contas, acho que já deu para entender que toda essa questão de decisões é muito importante para o seu projeto. E decisões erradas podem e provavelmente vão implicar em maiores custos para o projeto nas mais variadas áreas e aspectos, desde o custo de desenvolvimento (que, por muitas vezes, é mais raro de sentir), a custos relacionados a performance e hospedagem.

Além disso, deu para ver o que decisões relacionadas a grandes mudanças tomadas no meio de um projeto podem provocar, né?

Pois então. Fica então o alerta para quem está começando ou quer começar um projeto e está ainda na fase de procura pelo que usar ou não. Por fim, quero convidá-lo a opinar sobre esse assunto que é tão complexo e para o qual raramente se encontra um consenso válido, aguardo sua opinião nos comentários!

E se você curtiu este post, não perca os próximos: Clique para ver as diferentes formas de acompanhar o blog e não perder mais nenhum post daqui. 🙂

Até a próxima!


Posts relacionados


Uma resposta para “Falando um pouco sobre custos e a "melhor solução" para tudo”

  1. Avatar de Braytiner Heggendorn
    Braytiner Heggendorn

    Muito bom, simples direto e atual!

Deixe um comentário

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.