Uma espécie de manifesto

Atualmente é acessível para muitos começar a desenvolver uma solução baseada em software. Existem linguagens de programação acessíveis mesmo a pessoas sem experiência em programação, permitindo-lhes assim resolver um problema recorrendo a um computador.

Porém, quantos desses programadores se regem por valores ou regras comuns quando desenvolvem uma solução? Quero acreditar que são muitos, e os que não o fazem é porque não desenvolveram ainda um conjunto de normas base, ou simplesmente não tenham pensado nisso. Por isso, resolvi escrever 4 pontos essenciais que considero importantes durante o desenvolvimento de software e assim refletir um pouco sobre o que estamos a entregar, seja para nós próprios ou para um cliente.

Usar apenas os recursos indispensáveis para atingir o objetivo

Com o aumento do poder computacional, nos dias de hoje é comum descurar a performance de um processo porque “é igual, não há diferença”. Existem algumas variáveis que definem esta diferença, por exemplo: tempo, memória, gastos externos (papel, água, luz). Estas podem ser usadas indiscriminadamente com a justificação que existe uma grande margem de gasto.

Enquanto essa margem pode ser de facto segura para ser gasta nesse momento, isso traz problemas de escalabilidade. Exemplificando de grosso modo, um processo que gastava 2% de memória, e agora gasta 5%, reduz a sua escalabilidade de 50 para 20 instâncias. É um problema a longo prazo.

Para mim é importante que uma solução use apenas os recursos considerados essenciais, e aplico esta regra em tudo o que me for possível.

Desenvolver uma experiência de utilização humana, para humanos

A experiência de utilização evoluiu muito nestes últimos anos, e hoje podemos afirmar que é possível ter interfaces agradáveis e fáceis de interagir. Na minha opinião, uma interface apenas com um destes requisitos não é completa.

Uma interface agrdável pode transmitir ao utilizador uma sensação de satisfação, alegria ou até espanto. Por outro lado, uma interface fácil de interagir pode dar mais confiança, revelar-se inteligente e versátil.

Não sou, de longe, alguém especializado em design. Contudo, tenho como objetivo desenvolver interfaces que satisfaçam estes requisitos de forma aceitável, com vista a entregar uma solução que resolva o problema e seja acessível.

Não reinventar a roda

Por bons e maus motivos, entrámos num mercado global, onde a competição já não se rege apenas ao nível de uma localidade ou país. Uma consequência negativa imediata é facto de as entidade que concorrem a um determinado objetivo são cada vez mais eficientes, de forma a manterem-se em “jogo”.

No entanto, é perfeitamente possível tirar proveito disso. Hoje em dia, existem inúmeros repositórios de software que permitem adicionar módulos a um projeto e resolver problemas específicos. Porque não confiar em pessoas que têm um objetivo focado de resolver um problema que têm em comum connosco? Provavelmente o módulo que desenvolveram é atualmente utilizado por mais pessoas, e testado de forma exaustiva. Isso permite que nos foquemos mais na solução que queremos desenvolver enquanto se retiram “pedras do caminho”.

Quando possível, uso bibliotecas externas de código aberto que resolvam um pequeno problema e sejam apoiadas pela comunidade. Uma parte interessante disto é que podemos fazer parte dessa comunidade, retribuindo com contruibuições para melhorar esse módulo. É uma experiência excelente, que já tive a oportunidade de ter.

Quebrar padrões quando é estritamente necessário

Os padrões são definidos pela indústria de forma a dar linhas de orientação para o desenvolvimento de soluções não só com um objetivo comum, mas também com processos comuns para o atingir de uma forma que é conhecidas por todas as partes. Isto é especialmente importante para criar um contrato entre essa solução e uma outra solução externa poderem interagir.

Contudo, uma solução pode conter requisitos que não passíveis de ser resolvidos usando métodos bem conhecidos. Nesse caso pode torna-se necessário estender, e talvez até inovar essa parte do processo. Com melhores e piores exemplos, muitas empresas e pessoas individuais o fazem com vista a atingir os seus objetivos particulares. Isto quebra o “contrato” e poderá resultar em quebras de compatibilidade. Por outro lado, é uma necessidade real que deve ser satisfeita, e não o é possível fazer com os métodos existentes.

Assim, dou a mim próprio flexibilidade para quebrar alguns padrões quando se torna necessário. É importante trabalhar com o cliente (seja numa relação comercial ou para a comunidade de software livre) de forma a encontrar um compromisso entre o que é pretendido e o que é possível fazer nesse momento. Eventualmente terão de haver cedências de ambas as partes, e é aqui que este ponto entra em ação.