Produtividade na programação (ou no desenvolvimento de softwares)

Quem está no curso de Ciência da Computação da UESC sabe dos últimos e-mails que rolaram na lista de discussão dos alunos, sobre a utilização de ferramentas RAD para criar interfaces gráficas em C++. Um dos colegas do curso defendeu o uso de ferramentas RAD nesta etapa do desenvolvimento.

Bem, ele defende veementemente qualquer ferramenta que se propôe a facilitar e agilizar alguma etapa do desenvolvimento de um software, mas acho que ele esquece de analisar se essa ferramenta não vai acabar atrapalhando e atrasando etapas posteriores do desenvolvimento, resultando em um projeto mais demorado do qual se não fosse utilizada tal ferramenta.

Eu dei minha contribuição na lista de discussão. Argumentei que nem sempre agilizar uma etapa agiliza o todo. Como a discussão era sobre criação de interfaces gráficas, também argumentei que essa etapa do desenvolvimento leva pouco tempo e que se feita corretamente, o tempo dela pode se tornar desprezível em relação ao todo.

O e-mail que eu postei na lista de discussão está abaixo. Ele vai ser o post de hoje do meu blog:

"A conversa sobre usar ou não uma ferramenta RAD pra criar interfaces gráficas me fez pensar sobre produtividade na programação. Então, vou expôr o que eu pensei e o que eu acho sobre isso.

As empresas estão atrás de produtividade. É verdade, claro. E também é verdade que devemos ser produtivos, para assim termos um emprego, ganhar dinheiro e nos manter, sempre pensando em ter algo mais pra entretenimento e futilidades extras. "Mas Just é um cara tão GNU!! Como pode dizer isso??" Ora, eu também gosto de dinheiro :)

Entrando na conversa de programação, não adianta muito fazer as janelas (ou outras interfaces gráficas) bem rapidamente. O cara abre a IDE, desenha tudo rapidinho e depois vem a pergunta: "E agora? O que eu faço?" É preciso programar! Escrever código, claro!

Aí entram as grandes empresas. Essas sim precisam ser muito produtivas e rápidas. Como já foi discutido na lista antes e continuou sendo essa semana, empresas grandes e importantes exigem experiência. Bem, um programador experiênte consegue criar uma interface gráfica na mão tão rapidamente quanto usando uma IDE RAD. E ainda, criar a interface na mão pode fazer o desenvolvimento se tornar mais rápido por um todo.

O que eu quero dizer, é que se você desenha a interface com uma IDE RAD, ela fica pronta rapidamente, mas dá trabalho pra fazer algumas alterações. Se você faz via código, dependendo da sua experiência na framework e na linguagem utilizada, você cria a janela tão rapidamente quanto se usasse uma IDE RAD. E ainda, se quiser fazer alterações futuras, fica bem simples. É só adicionar uma linha, ou alterar outra, e por ai vai.

Mas ainda não acabei. Acrescento ainda, que durante todo o processo de desenvolvimento de um software, a interface gráfica pode ser algo em torno de 10% do projeto total. Vou citar como exemplo o WinPolicy (todo mundo já deve tá de saco cheio dele :P). Fiz as interfaces dele via código (aproveitei essa etapa pra aprender wxWidgets, hoje eu criaria a mesma interface muito mais rápido que antes). Depois de fazer as interfaces, foi só programação das funcionalidades. Lancei a versão 3.0. Adicionava algum recurso, corrigia bugs, 3.0.1, 3.0.2, 3.1, 3.1.1, 3.1.2 e agora está em 3.1.3. Quer dizer, a criação da interface gráfica tomou em torno de 10% do tempo e do código do software inteiro. O importante é programar bem pra fazer o resto com velocidade e qualidade.

Citando outro exemplo, estou terminando um outro projeto. Como já sabia mais de wxWidgets, a interface gráfica foi um tapa! Depois disso, fui implementando as funções do software. Essa semana terminei a versão beta. Pretendo lançar ele em breve.

Concluindo: não viagem nessa de querer uma ferramenta que faça tudo pra vocês, ou então a única experiência que vocês vão ter vai ser em clicar nos botões de uma ferramenta específica. No dia que ela cair em desuso, lascou-se! Se você aprende a programar bem, você não fica dependente de ferramenta. Além disso, essa experiência vai ajudar muito pra aprender outras linguagens e frameworks."

Explicando um pouco mais, acho melhor aprender a programar bem do que usar uma ferramenta bem. Se você entende bem a programação e o uso das frameworks, caso seja preciso aprender outra linguagem ou framework, vai ficar mais fácil do que se treinar em uma nova ferramenta de "clique-e-arraste".

Estão aí meus argumentos. Acredito estar correto. Espero receber comentários sobre o assunto. :)

Backports (Debian)

Todo usuário do Debian sarge deve ter um problema em comum: apesar do sistema ser realmente estável, alguns softwares estão bastante desatualizados. Exemplos:

- Firefox 1.0.4
- Thunderbird 1.0.2
- OpenOffice.org 1.1.3
- Gaim 1.2.1
- e por aí vai...

Existe a opção de você não utilizar os pacotes Debian desses softwares e baixar o fonte no site oficial e compilar. Mas qual a graça de usar Debian sem o apt?

Essa semana, enquanto pesquisava sobre como instalar o Catalyst no Debian sarge (ele tem pacotes no testing e no unstable, mas não no stable), encontrei um site chamado Debian Backports, que fornece os pacotes do Debian testing (alguns do unstable), compilados com as libs do stable (sarge). E lá estava o libcatalyst-perl, que é do testing, mas preparado para o sarge :)

O Backports funciona assim: você inclui o repositório deles em /etc/apt/sources.list e pode instalar os pacotes mais recentes com o apt-get:

deb http://www.backports.org/debian/ sarge-backports main contrib non-free

Depois é preciso adicionar essas linhas em /etc/apt/preferences (isso vai desativar os pacotes do Backports e fazer o apt usar os pacotes do sarge como padrão):

Package: *
Pin: release a=sarge-backports
Pin-Priority: 200

Para instalar um pacote que está no Backports:

# apt-get update
# apt-get -t sarge-backports install mutt

Pronto. Seja feliz no Debian sarge! :)