Alexandre Valente's Blog

Se da última vez que escrevi, eu achava que estava sobrecarregado, eu ainda não tinha idéia do que estava vindo! Estes últimos meses tem sido extremamente agitados na White Fox, estamos abrindo várias frentes, criando iniciativas onde um bom software possa ser um diferencial competitivo. Estamos tendo mais sucesso do que eu esperava inicialmente, este ano está sendo fechado com chave de ouro. Em breve, vou escrever sobre algumas destas inciativas aqui. Mas deixe-me continuar finalmente o post anterior, falando sobre desenvolvimento de software.

Como citei no post anterior, a ideia é tentar falar um pouco da maneira pela qual eu desenvolvo software, considerando as metodologias e correntes atualmente em voga. Para começar, acredito que o mais importante de todo o processo é entender que desenvolver software é entregar, dentro de um prazo e um custo acordado, algo que atenda uma necessidade de alguém de maneira satisfatória. Por mais óbvio que isto pareça, a maior parte dos desenvolvedores esquece estes objetivos primordiais. Acredito que isto aconteça porque, como desenvolvedores, tendemos a não lembrar que desenvolver software é uma atividade extremamente cara para quem compra. Assim, não cumprir um prazo pode significar uma perda de oportunidade que inviabiliza todo o investimento. E é claro que não cumprir custo pode fazer com que um investimento seja inviável em termos de resultado financeiro, determinando a falência do projeto. E mesmo atingindo ambos os objetivos, o software ainda tem que servir para melhorar algum processo ou trazer alguma receita, de forma que o investimento feito seja compensado. Claro que muitas vezes isto é difícil de ser avaliado, mas, por mais difícil que seja, isto é o que queremos obter quando desenvolvemos comercialmente. É importante ter isto em mente porque nossas decisões, como desenvolvedores ou arquitetos, vão justamente impactar estas características e elas só fazem sentido quando permitem que a construção do software seja financeiramente viável.

Entregar um software que funciona bem também parece ser algo óbvio, mas que na prática é justamente uma dos pontos mais subjetivos da nossa profissão. Por exemplo, na prática poderíamos construir praticamente qualquer sistema utilizando somente telas de CRUD (listar, editar, alterar, remover). Apesar de funcionar, um sistema assim muito provavelmente seria quase impossível de ser utilizado com eficiência pelos usuários – eu mesmo já tive a chance de conhecer vários sistemas feitos desta forma! No extremo oposto, o software pode ter poucas telas, extremamente complexas e que fazem “tudo”, o que podem pro um lado ser um pesadelo para quem usa ou, mesmo sendo fácil de usar, ser um pesadelo para manter e evoluir – novamente, já vi vários assim. Encontrar o ponto ideal de usabilidade versus produtividade é pra mim um dos maiores desafios do desenvolvimento. No entanto este é um assunto que eu raramente vejo em fóruns técnicos.

Um outro ponto importante dos conceitos gerais de desenvolvimento é a questão da manutenabilidade de software. Esperamos que o software que construímos seja usado por muito tempo, talvez até muitos anos. Assim, se um software for extremamente caro para manter (e manter aqui significa alterar e evoluir o mesmo conforme necessário para o negócio), ele também pode se tornar inviável para quem está comprando. Daí toda esta preocupação de desenvolvedores em fazer software utilizando uma estrutura que permita que ele seja entendido e alterado com facilidade por alguém no futuro. O problema é que isto é também é algo extremamente subjetivo, já que é difícil determinar qual o grau de estruturação que vai permitir atingir este custo ideal de manutenção. Em outras palavras, é muito complicado determinar o quanto a mais tem-se que gastar no desenvolvimento e calcular em quanto isto deixa a manutenção mais barata. Alguns acham, por exemplo, que somente software que faça uso da última moda em BDD, TDD, DDD e etc. teria um custo de manutenção adequado. Mas muitas vezes, o que se gasta para se incluir uma determinada metodologia ou técnica em um processo de construção torna o software tão caro pra fazer que a conta não fecha. Por outro lado temos exemplos de software com anos de uso, em FORTRAN ou CLIPPER, que estão em uso até hoje e que possuem ainda um custo de manutenção que não justifica uma eventual migração. Claro que cada caso é um caso, porém, na minha visão, este é um dos conceitos que mais geram dúvida e que mais é erroneamente empregado por desenvolvedores em geral.

Pra mim a manutenabilidade é super crítica, já que o software que eu construo tem a tendência de ser usado por muito tempo – tenho alguns que estão em uso há mais de 10 anos. Ao longo dos anos, surgem e desaparecem metodologias e técnicas, plataformas e linguagens são evoluídas. A minha solução para isto foi sempre criar um framework que abstraia os artefatos produzidos, na medida do possível, de toda esta mudança, sem perder as novidades. Pra mim, de longe, o mais caro no software é construir interfaces. Assim, desde os tempos do ASP eu trabalho com algum tipo de abstração de interface para tornar isto um pouco mais barato – ver posts sobre produtividade. E interessante que, apesar de todas as mudanças, estes frameworks têm alguns pontos comuns. Claro que hoje em dia, com MVC e jQuery, a facilidade para abstração é muito maior. Porém algumas áreas como visualização e separação lógica, permanecem de maneira muito similar.

Com relação à usabilidade, eu tento manter a criação de telas complexas no limite do que o framework permite. Claro que com a evolução do framework, hoje é possível fazer praticamente qualquer tela. Mas ainda assim, eu sempre prefiro utilizar telas que sejam mais simples de expressar no framework, desde que não atrapalhe muito a usabilidade. É claro que é sempre possível fazer algo super complexo, porém deixo claro para quem compra que a escolha por uma interface complexa vai gerar um maior custo pra fazer e um muito maior pra manter, o que usualmente é um argumento bastante convincente. E interessante de ser ter software usado por muito tempo é que ao longo dos anos, os indicadores mostram que a maior parte do custo de evolução se concentra justamente nas telas complexas, confirmando a teoria de que telas grandes são algo bastante difícil de se justificar, financeiramente.

Então, retomando o tópico principal, como desenvolvo software? Tudo começa com uma necessidade. Para efeito de ilustração, vamos assumir daqui por diante uma necessidade de um cliente que deseja, por exemplo, passar a controlar dados que estavam numa planilha. A partir daqui vou tentar imaginar um software que atenda a necessidade, que seja feito utilizando os artefatos do framework e que custe algo pra fazer que possa ser retornado em algum tempo. Neste exemplo, de uma planilha, o ganho do cliente seria a redução da perda é de tempo dos usuários (afinal manter planilhas grandes é algo complicado), a diminuição do risco de um erro de digitação (planilhas grandes são difíceis de operar) e no aumento da disponibilidade da informação proporcionada por um sistema web.

No próximo post, continuarei deste ponto mostrando como uma necessidade é transformada em software e quais os critérios que uso na construção dos artefatos e na implantação final do produto. Prometo não demorar pra escrever a continuação!