2 de março de 2011

O que distingue um bom programador?

Esta semana estou a fazer o Developer Boot Camp da OutSystems. A ideia é aprofundar os meus conhecimentos na óptica de Developer para a Agile Platform para que possa estar mais à vontade a desenvolver as ferramentas que se usam internamente na OutSystems (a grande maioria é desenvolvida com a própria plataforma da OutSystems), mas também para saber o que é que se anda a ensinar a quem usa a plataforma de forma a melhor compreender os erros que nos aparecem na Manutenção.

Uma das vantagens destes boot camps é conhecer outros profissionais da área de informática, particularmente com outra história e sensibilidades. Ontem gerou-se uma discussão que eu achei bastante interessante. Estava o formador a explicar as "Simple Queries" e como funcionavam e não é que aparece nos slides um "SELECT * FROM tabela ...". Visto isto há um dos colegas que pergunta se é possível seleccionar especificamente os campos em vez de se usar *. Ele claramente preocupado com aderir às boas práticas de SQL de seleccionar apenas os campos que interessam e obtê-los numa ordem previsível. "Não é preciso, a plataforma faz isso por si. Não só o '*' conceptual é expandido nos campos concretos da tabela, como os campos que não são usados também não são obtidos." é a resposta à preocupação dele. Devia chegar, mas não chegou.

É então que surge outra preocupação pelo mesmo colega: "Ora. Se a plataforma faz isso, como é que distingo quem sabe o que está a fazer de quem não sabe o que está a fazer quando faz perguntas à base de dados?". Aqui o argumento é bastante diferente: ao estar a tirar um fardo do programador, a plataforma está a retirar uma das características que o senhor usava para avaliar a competência dos seus programadores.

A minha opinião sobre o assunto é que se o que distingue um bom programador de um mau programador é algo que pode ser automatizado, então eu proponho que não é uma boa medida para avaliar o trabalho de um ser humano. Automatize-se o que se puder ao máximo e avaliem-se as capacidades cognitivas do programador, não as suas capacidades mecânicas.

Esta boa prática em particular tem como principal objectivo que as perguntas à base de dados sejam mais eficientes e menos propensas a erros. Com o "*", conceptualmente, os campos podem vir numa qualquer ordem, e poder-se-ia estar a introduzir um erro difícil de detectar se os campos viessem numa ordem diferente da esperada, ou pior ainda, se por alguma razão deixarem de vir pela ordem que vinham quando se definiu a pergunta. Por isso é boa prática enumerar os campos em vez de usar '*'. Por outro lado, se só precisarmos de dois ou três dos campos das tabelas usadas para realizar a pergunta, também é boa prática listar apenas os campos que vamos usar na selecção. Isto vai fazer com que hajam menos dados a passar na ligação (usualmente remota) à base de dados, melhorando o desempenho da aplicação.

Estas boas práticas são particularmente chatinhas de manter: se de repente deixo de precisar ou passo a precisar de um certo campo, posso ter de ir à definição da variável que guarda os valores adicionar/remover o campo, ter a certeza que na pergunta está lá ou deixa de estar. Enfim, pode ser preciso estar a alterar várias partes do código para fazer alterações rotineiras, das quais é fácil esquecer uma ou outra. Alterações do modelo de dados que se queiram utilizar podem também necessitar ir a uma série de perguntas alterar a lista de atributos obtidos, noutra operação rotineira e propensa a erros.

Como todas as operações rotineiras e monótonas, quanto mais automático isto for melhor. Na Agile Platform da OutSystems é exactamente isso que acontece. Os programadores que usem "Simple Queries" (servem perfeitamente para a vasta maioria das perguntas) beneficiam de borla destas boas práticas sem terem de se preocupar com isso. É maravilhoso poder fazer perguntas optimizadas a um nível de abstracção tão alto como o possível na Agile Platform.

Revisitando a preocupação do meu colega de formação: quando a plataforma faz tanto por nós pode parecer mais difícil distinguir um bom programador de um mau programador. Não me parece que seja um problema, principalmente porque o que interessa é ter bom código. Se ele foi feito por um bom programador, um mau programador ou por um gerador de código, não é tão relevante quanto isso. E nem sequer é um problema novo.

Quando surgiram compiladores de linguagem máquina para linguagens sequenciais simples, os programadores deixaram de se preocupar com (por exemplo) meter variáveis a 0 usando xor com ela própria (poupa algumas instruções) para se passarem a preocupar com problemas de mais alto nível. O mesmo se observou quando surgiram linguagens "managed" que (entre outras coisas) gerem grande parte da alocação da memória pelo programador. Em ambas estas instâncias o que distingue um bom programador da linguagem "antes" e o que distingue um bom programador na linguagem "depois" são quase sempre pormenores diferentes. Claro que também há características distintivas de bons programadores em geral que não estão ligadas a tecnologias especificas.

Mas esta subida da parada é algo positivo. Mesmo que os novos programadores Java (ou C#) não saibam nada de alocação de memória, e não se fossem lembrar de fazer os free's para todos os malloc's, eles agora vão ser avaliados pelo quão bem conhecem e usam as bibliotecas da linguagem, por exemplo. E é bom que não se tenham de preocupar com as coisinhas de baixo nível para virarem a sua atenção para a organização do programa e em ter mais e melhores funcionalidades no produto final.

Quando "programamos em OutSystems" a linguagem que usamos é gráfica: arrastamos bolinhas e outros bonequinhos para fluxos, editamos (visualmente) como a informação é apresentada, e definimos o modelo de dados das nossas aplicações usando o modelo Entidade-Relação. Por trás a plataforma vai gerar o SQL, o código aspx (ou jsp), e o código C# ou Java que implementa a nossa aplicação. Não temos de nos preocupar em fazer x = 0 com XOR em vez de usando uma constante (é o compilador de baixo nível que faz isso), nem com fazer um free por cada malloc (a linguagem "managed" é quem tem essa preocupação), e agora nem temos de nos preocupar com o código aspx/html ou sequer com as perguntas SQL (é a Agile Platform quem faz isso). Isto é mais do que bom, é óptimo.

Não termos de nos preocupar com estes pormenores (e eles serem feitas pelas camadas mais abaixo) quer dizer que as nossas preocupações vão para outros pormenores. Já não conseguir distinguir o "bom" programador que sabe o básico de optimizar perguntas SQL é uma vantagem já que mesmo o tipo que não sabe optimizar perguntas SQL vai gerar perguntas SQL optimizadas. Tal como o tipo que não sabe onde deve fazer free, vai ter os free's no sítio certo. O código por baixo é portanto de melhor qualidade. Remover estas preocupações propencia a uma melhor qualidade geral do programa, e é isso que todos queremos fazer: programas de qualidade.

Com a Agile Platform, o nível onde estão as distinções entre programadores fica cada vez mais próximo do nível que quem utiliza a aplicação vai ver. A não ser quando o programa estoura por falta de memória, quem usa um programa não quer saber se os free's estão todos feitos. A não ser que o programa demore um tempo alarvo a ir buscar dados à base de dados, o utilizador quer lá saber se o SELECT tem * ou não. O foco da qualidade da aplicação passa para cada vez mais perto de onde interessa, para quem o utiliza. E esta aproximação do utilizador final só pode ser positiva. Temos de nos lembrar que não fazemos aplicações por fazer aplicações (por mais tecnicamente bem feitas que estejam), mas sim que fazemos aplicações para serem usadas por alguém.

Um bom programador OutSystems vai ser aquele que melhor constrói  o modelo de dados adequado ao problema em mãos. É também aquele que melhor desenha a funcionalidade desejada sobre esses dados, com cada vez mais atenção que o cliente quer (quer ele o expresse ou não). Um bom programador OutSystems vai fazer aplicações fantásticas para quem as utiliza.

Sem comentários:

Enviar um comentário