domingo, agosto 20, 2006

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. :)

3 comentários:

Anônimo disse...

Oi Just,
Eu concordo totalmente com você, e vou um pouco mais além... que devemos evitar a preguiça de pensar. É muito fácil abrir um VB da M$, desenhar a interface, até colocar algum código nos eventos, e pronto! temos uma aplicação rodando... toda fechadinha, não sai do padrão... aí o cara quer colocar um recurso adicional, pronto, tá ferrado!
Tive 3 experiências com programação de interface gráfica, a primeira com o VB, depois um pouquinho de Win32 (na minha vida pregressa, quando eu ainda era usuário M$... :-) ) e agora estou estudando GTK2. Realmente, é imensamente diferente a programação Win32 da GTK, porém muitos conceitos que aprendi em win32 (por exemplo "callback", você definir uma função que vai ser chamada em resposta a um evento) existem aqui na GTK. E você sabe exatamente o que está acontecendo com seu programa.
Abraços!
Carlão

Anônimo disse...

Bem,

não sou um programador experiente e muito menos trabalhei com programação visual (se é que posso chamar VB assim) ou fiz programas com interface gráfica, porém, tenho capacidade suficiente para entender o ponto de vista de Just e Carlão com relação a tempo e eficiência na programação.
Programo há um ano e seis meses com linguagem C e estudei um pouco de Win32.
Percebi que não era vantagem continuar o aprendizado em Win32 pois dá muito trabalho e não é portável, assim gastaria muito tempo para aprender algo que não me ajudaria muito num futuro próximo.
Até que fui apresentado ao wxWidgets por Just. Em algumas horas de estudo criei uma simples janela com menu e botões. Lembrando que nessa época ainda não sabia os conceitos de POO e fui capaz de manipular o código tranquilamente. Assim, fica claro que quando você utiliza wxWidgets pode-se ter um código mais eficiente (é você que está programando), mais compreensível, feito em um tempo menor (você não vai precisar entender o código de terceiros para saber, exatamente, como desenvolver as funcionalidades do programa) e um dos mais importantes: a sua grande portabilidade.
Portanto, quem "programa no dedo" sabe o que está fazendo e com certeza terá sucesso no seu programa, já para aqueles que utilizam ferramentas não digo o mesmo, pois alguns deles "não sabem exatamente" o que estão fazendo.
Fico por aqui.

Abraço

Fillipe

Unknown disse...

Concordo em partes com Just, realmente o programador deve saber sim o que a ide faz, trabalhei muito tempo com uma ferramenta RAD , a facilidade te construir muita coisa automática realmente pode ser um problema, principalmente quando se trata de evolução de software, as ferramentas RAD , são boas mas deve se ter um bom senso de utilizar da melhor forma, não é porque ela te dá a opção de criar quase tudo automático que o desenvolvedor deve utilizar, e em relação a parte gráfica essa sim pode ser muito utilizada para se construir com as ferramentas RAD , porém o desenvolvedor as vezes necessita fazer alguns ajustes no braço, então é sempre bom saber como a ferramenta gerar seus códigos automáticos, e utilizando alguns padrões vc consegue desenvolver um sistema de maneira rápida e eficiente.