Escolher as tecnologias para construir um software requer cuidado e critério uma vez que há muitas opções disponíveis. Estamos vivendo o período de maior abundância tecnológica que já existiu. Há vários tipos de linguagens de programação, frameworks, APIs, bibliotecas (i.e., libraries), serviços e outras tantas opções de tecnologias de fácil acesso. Decidir quais escolher é um desafio sobretudo quando se quer criar um produto que pode durar por vários anos.
As decisões para criar um software são afetadas por diferentes fatores. A plataforma onde o software irá executar (ex., Windows, MacOS, Linux, iOS, Android, etc.) impõe algumas restrições além de regras formais que precisam ser seguidas. As tecnologias conhecidas pela equipe técnica se tornam, naturalmente, uma forte opção de escolha. Além disso, se leva em conta, muitas vezes, as tecnologias que estão em evidência no momento ou aquelas que já aparecem como promissoras para o futuro.
Há alguns anos, a decisão em escolher o sistema operacional para um novo software era mais simples: Windows, MacOS ou Linux. Hoje, sabe-se de antemão que um novo software, muito provavelmente, terá que funcionar em mais de uma plataforma — tanto em computador (ex., Windows, MacOS, Linux, etc.) quanto em smartphones e tablets (ex., iOS, Android, etc.). Na web não é diferente; um software tem que funcionar, no mínimo, no Google Chrome, Safari, Mozilla Firefox e Microsoft Edge — e muitos ainda precisam contemplar o velho Internet Explorer.
Também há outras variáveis que devem ser levadas em conta, como a dependência e o custo de profissionais que saibam programar ou operar as tecnologias escolhidas. Essa questão pode não parecer preocupante na fase inicial, especialmente porque se pensa em escolher uma tecnologia atual ou já muito bem conhecida pela equipe. No entanto, as pessoas da área de tecnologia, em sua maioria, gostam de trabalhar com algo novo, moderno, atual.
Ou seja, deve-se fazer um exercício quanto à oferta de profissionais para o futuro. Um olhar mais a longo prazo pode ajudar: haverá profissionais que terão interesse nas respectivas tecnologias daqui a 5 ou 10 anos? Como tecnologias similares criadas há 5 ou 10 anos estão hoje? Há ainda oferta e demanda para profissionais de tais tecnologias?
Passamos, na Knewin, por uma situação complicada há dois anos quando tivemos que buscar profissionais para manter um software que veio junto com uma empresa adquirida. O software foi criado com tecnologias que já haviam sido abandonadas. Levamos mais de três meses para encontrar um profissional e até hoje ainda estamos migrando partes antigas daquele produto para tecnologias mais modernas.
Esse tipo de problema sempre existiu e sempre existirá em se tratando de desenvolvimento de software — o bug do milênio, pouco antes do ano 2000, teve uma demanda absurda por profissionais que sabiam programar na linguagem Cobol. O desafio é minimizá-lo.
Outra variável que muitas vezes passa despercebida é a fase do negócio ou do produto. Se o objetivo é testar rapidamente uma ideia deve-se escolher tecnologias que sejam fáceis e rápidas de se desenvolver — gerar protótipos em poucos dias (senão em horas). Valida-se uma ideia e, novamente, deve-se verificar se faz sentido continuar com as tecnologias já usadas ou se faz sentido buscar alternativas. O peso das variáveis, no entanto, vai mudando com a evolução, uso e validação do produto.
Os requisitos funcionais e não funcionais de um software devem ser os guias para suportar as decisões quanto às escolhas iniciais ou mudanças de suas tecnologias. O ideal é que tais tecnologias permitam a evolução gradual e contínua de um produto com o passar dos anos.
A regra que usamos na Knewin é escolher, sempre que possível, tecnologias estáveis e mais robustas. Por exemplo, é preferível escolher uma linguagem de programação que já esteja no mercado por anos, que esteja sendo usada por grandes empresas mundo afora e que tenha potencial de evoluir pelos próximos anos do que escolher uma nova linguagem que não se sabe ao certo sobre o seu futuro — o grau de aposta aumenta ou diminui dependendo da escolha.
Nós fazemos essa reflexão para cada nova função a ser codificada e não apenas para a escolha das tecnologias iniciais de um produto. Faz sentido, por exemplo, usar uma biblioteca (i.e., library) para programar uma nova função? Quais são os prós e contras em ter uma nova biblioteca como mais uma dependência em um produto? O tempo para desenvolver a função será mais curto? A função terá mais qualidade, segurança e robustez?
A análise crítica se torna ainda mais desafiadora com a abundância de frameworks, bibliotecas e APIs que nascem a cada novo dia. O bom senso ainda faz parte desse processo de escolha.
Temos, na Knewin, tecnologias que escolhemos há alguns anos para funções específicas e que hoje se tornaram um problema. O custo para remove-las ou substitui-las ainda não fez sentido — será mais caro troca-las do que ainda mantê-las. Teremos que conviver com elas por mais algum tempo. Estudar as escolhas do passado e o reflexo no presente é fundamental para se tomar as decisões para o futuro.
Um exercício simples e, no mínimo, curioso é analisar os frameworks Javascript para se desenvolver aplicações Web que foram criados pela comunidade open source. Ao se buscar aqueles que estiveram na moda há 5 anos, por exemplo, já se vê vários projetos abandonados, sem nem mesmo qualquer ação recente dos próprios criadores. Olha o tamanho do problema para uma empresa que escolheu um desses frameworks? O seu produto está totalmente dependente de uma tecnologia que não é mais evoluída nem mesmo pelos seus criadores.
Há, também, os casos onde uma tecnologia precisa ser substituída por não atender a evolução no uso de um produto. Diferentes variáveis podem obrigar a isso como, por exemplo, lentidão devido ao aumento no número de usuários ou no volume de dados a serem manipulados. Passamos por isso na Knewin algumas vezes, como quando a tecnologia para processamento distribuído se tornou muito cara para nos atender. Enfim, esse é o tipo de cenário que pode gerar ainda mais transtornos se não for devidamente antecipado e muito bem planejado — substituir uma tecnologia tende a ser mais complicado e mais caro do que fazer algo novo.
Construir um software ainda é uma atividade complexa. Há muitas variáveis que precisam ser cuidadosamente pensadas. As tecnologias usadas podem ter grande impacto no sucesso de um produto assim como podem ser a sua ruína. O grau de incerteza precisa ser reduzido e para isso as decisões devem ser baseadas em uma visão holística, com critérios técnicos, econômicos e de negócio muito bem pensados. De todo modo, qualquer escolha que seja feita ainda não deixa de ser uma aposta.
Novas postagens no endereço fbeppler.com.