Programação Espiritual

Muitos dos conceitos da Extreme Programming giram em torno de tirar a bola de cristal da mão do desenvolvedor e fazer ele entregar o código ao invés de passar semanas em modo de masturbação mental sobre a extensibilidade do código. Se vc ainda não deu uma olhada em XP, aproveite a deixa

www.xispe.com.br

Oba, ninguém respondeu essa ainda, vou poder falar todo tipo de abobrinha que eu quiser.

:oops: (parentese: a cerca != acerca) :oops:

Eu acredito que vc vai fazer um sistema, vai dar manutencao por um tempo, depois vai jogar fora. Até hoje, isso tem acontecido muito.

Um dos campos de estudo da eng de soft era garantir que um software fosse fácil de manter, de alterar, e de acrescentar ou remover funcionalidades. Foi minha paixao por uma epoca, ate eu ver que as tecnologias evoluem e as coisas realmente vao pro buraco.

Tem um pessoal aí que estuda P=NP e pode te dizer que por enquanto acredita-se que nao eh possível fazer um programa capaz de escrever qualquer programa e que termine em tempo finito. Nao sei se eh exatamente assim o enunciado, mas vai por aih.

Talvez seja possível construir um programa que, para um conjunto de restricoes finito, consiga fazer uma aproximacao bem razoavel. Bom, aí qual a diferenca entre este programa e um humano??

Cada vez mais acredito no mote dos XPzeiros: “embrace change”, tb conhecido como jogaforaessamerdaefazdireito.

Acredito que com o passar dos anos, as tecnologias vao tornar mais fácil, mais prático, mais rápido de construir sistemas simples, de modo que os sistemas que antes eram complexos vao ficando triviais, a ponto de o custo de faze-lo de novo do zero sempre vai cair mais do que o custo de manutencao.

É só uma opiniao, claro!! : ))

[]s!!

[quote=“dukejeffrie”]Oba, ninguém respondeu essa ainda, vou poder falar todo tipo de abobrinha que eu quiser.

Quase, duke… eu cheguei 5 minutos antes

“dukejeffrie”:

Cada vez mais acredito no mote dos XPzeiros: “embrace change”, tb conhecido como jogaforaessamerdaefazdireito.

Não é bem “jogaforaessamerdaefazdireito”, tá mais pra “refazessamerdaatéficarbom”…

Po, já reparou como isso já vem acontecendo cada vez mais, e cada vez mais a gente vai jogando código pra área de “infra”? Hoje em dia, ter controle de persistencia, transacoes, serializacao, memoria, concorrencia já não é mais nem um décimo da tarefa que isso representava há 10 anos atrás.

Você consegue se imaginar fazendo as coisas que faz hoje com um Servlet em um cgi-bin escrito em C?

O que eh melhor em termos de custo-beneficio? O cliente esta te pagando para se preocupar com isso?

Analise tudo isso. Mudar de paradigma (digamos, procedural para OO) eh radical e re-desenvolver um sistema dessa forma sera quase como desenvolver do zero, desde a base, dependendo do caso. Sera que o cliente vai querer passar por toda a fase de desenvolvimento, teste, implantacao e treinamento novamente? Quanto tempo tua nova versao vai demorar para estar estavel tanto quanto a anterior?

Ou seja (como quase tudo): depende.

Ate concordo contigo, mas uma mudanca de paradigma como voce citou eh algo radical - acontece de tempos em tempos (eu acho). Voce nao precisa se preocupar com isso no dia-a-dia.

O que acontece eh que vai chegar um belo dia em que a situacao estara bem clara diante dos teus olhos (ou do teu cliente)… Algo como: puxa, essas telas em Clipper para DOS estao realmente defasadas. Nao sera hora de desenvolver uma versao mais atual desse sistema? (vide caso de sucesso na Java Magazine desse mes).

IA? Linguagens 4GL apregoadas pela Engenharia de Software?

Nao sei… primeiro tente encontrar as bases da tua preocupacao. Seria as mudancas de paradigma? Ou simples mudancas de linguagem?

Veja - se voce tem um sistema X. Hoje lancaram a revolucionaria linguagem .Y. Voce nao precisa sair correndo e converter teu sistema, nao eh mesmo? Amanha lancam uma nova versao do Z que tem super-recursos. Voce vai migrar seu sistema soh por isso? Aquele que esta funcionando redondinho?

Acho que nao justifica. Como ja diria o Falcao: manutencao eh manutencao, nova versao eh nova versao, linguagem eh linguagem e paradigma eh paradigma!

Marcio Kuchma

Quase, duke… eu cheguei 5 minutos antes ;)

Oloko! Demorei 5min redigindo a mensagem e qdo volto encontro um debate a pleno vapor… Esse pessoal “rato-de-forum”…

Marcio Kuchma

Pois eh, cv, vc nao chegou antes, apenas deu send antes. Tipo, eu fui lá, pesquisar pra ver se eu nao tava falando besteira, e tal… : ))

fora que vc tá a todo vapor, e eu to aqui pedindo cama, já…

O kuchma, deixa eu escrever o que vc disse de novo:

Foi meio isso que eu quis atacar, tipo, uma hora, vai ficar tao fácil reescrever tudo que o custo de se ter uma versao estavel sob as novas tecnologias e os novos metodos vai ser mais baixo do que o custo de promover, a partir da versao atual, a adequacao às necessidades do cliente…

[]s!!!

Hmm, nao sei se concordo TOTALMENTE com isso dukejeffrie…

Eu acho que ha uma tendencia em termos de evolucao na maneira como desenvolvemos… os primeiros computadores eram programados diretamente nas valvulas, mais tarde veio o assembly, programacao procedural (pascal, c, etc) e hoje temos a OO (c++, java, etc) e outras tecnicas. A Engenharia de Software (apesar de parecer balela na maioria das vezes - sim, eu tambem acho isso :)) tambem evoluiu durante estes anos.

Isso refletiria (teoricamente) na qualidade do software e na rapidez de desenvolvimento. Digo teoricamente pois sistemas criticos ainda sao colocados nas maos de gente que nao tem nocoes de Engenharia, Logica e essas coisinhas que a gente ve por ai (numa universidade, p.ex. :)) e que fazem alguma diferenca na hora de projetar um sistema.

Hoje ja temos, em certos aspectos, a rapidez para desenvolver. Mas a qualidade, hmmm… sei nao…

Um negocio legal que esta ligado a isso eh o desenvolvimento baseado a componentes. Parece uma buzzword de Engenharia, entao nao me perguntem… mas seria algo mais ou menos como o que acontece com o Eclipse hoje: para que desenvolver um editor para a linguagem X se temos o Eclipse e podemos fazer um plugin?

Soh que isso eh um software generico (editor de textos). Nao consigo vislumbrar isso sendo aplicado a softwares especificos - se alguem tiver exemplos ou ideias, manifeste-se.

Marcio Kuchma

O que vc descreveu foi basicamente a inversão de controle (a tão aclamada IoC). Estou me dando razoavelmente bem trabalhando com isso na construção de um sistema de gerenciamento de conteúdo aqui.

Um pouco da literatura e propaganda sobre IoC está disponivel no site do Avalon e do PicoContainer. Voce tb pode achar mais sobre isso enterrado nas mailing lists do XWork/WebWork.

Aqui vai a linkaiada:

http://jakarta.apache.org/avalon
http://www.picocontainer.org
http://www.opensymphony.com/webwork

Divagando um pouco mais, acho que a unica razao pela qual a gente nao ve realmente software de qualidade sendo construido hoje em dia é a falta de metodologia - qualquer que seja ela - no desenvolvimento de software em equipes. Cada um trabalha do seu jeito, a seu ritmo, e tem SEMPRE uma merda de um cliente pra atrapalhar tudo - com prazos forçados, objetivos impossiveis dados os recursos disponiveis, e por ai vai. Se nao fosse pelos clientes, eu tenho quase certeza de que os objetivos da engenharia de software como ciencia exata poderiam ser muito bem cumpridos na vida real

Cliente é um beneficiário e mesmo que eu desenvolva algo para mim na verdade sou um “cliente”. O problema sempre segue em torno da ANSIEDADE!!.

Exemplo:
Porque alguns funileiros ganham rios de dinheiro transformando poucos carros antigos ou novos! Porque eles não tem pressa e usam toda a sua habilidade aliada a ferramentas modernas.
Precisamos aprender a dominar a ansiedade do cliente e não sermos dominados por ela.
Não é fácil, pois temos que estar sempre mostrando que estamos fazendo algo realmente bom e com a participação do cliente para que ele não fique semanas sem saber como está ficando seu produto.

Verdade… eu tb já desenvolvi com constraints realistas, e é outra coisa. Continua havendo ansiedade, mas nao existe aquele “bom, faz assim mesmo por enquanto”.

Também é bom quando nao tem aquele anti-pattern “the lone ranger”, que o cara fez todo aquele código sozinho, foi embora e agora alguma outra pessoa tem que mexer naquilo, sem documentacao, sem nada…

em Java ainda dá pra recuperar alguma coisa, um Javadoc “vazio” ainda é util. Mas e em C??

Kuchma, pensa na qualidade. O que é um software de qualidade? Os velhos nomes ainda se aplicam: robusto, eficiente, abrangente, tolerante a falhas, elegante (esse nao é velho, mas se aplica). Se vc exagerar um pouco, vc consegue imaginar um software que pode ser refeito em uma tarde, algum que levou meses para fazer?

[]s!!

Como sempre, o nivel das respostas é espantoso! Baseado nelas, deixa eu falar um pouquinho mais…

Minha vontade era conseguir armazenar conhecimento e baseado nele produzir alguma coisa de forma mais automatizada possivel. Como “viajei” um pouco no conceito, gostaria de saber até que ponto isso era possivel e o quanto era utilizado na prática.

Parece sempre mais fácil jogar tudo fora e começar do zero. E o dia a dia dos amigos tem demonstrado isso. Para que criar um sistema “pensante” se temos um cérebro para isso?

James Martin escreveu que o maior desafio era a administração da complexidade. Dependendo do porte da aplicação tenho um certo receio de sair produzindo código, mas a prática meio que nos impõe isso. E o interessante é que no final das contas a coisa funciona!

Mas, porém, entretanto, todavia e contudo ainda estou mordido, meio que influenciado por Prolog, pela idéia da programação declarativa e de uma base de conhecimento. Vou brincar mais um pouquinho e tentar produzir alguma coisa. Se não der em nada, pelo menos terá sido divertido.

Obrigado a todos !

Ps. tá bom, tá bom, não vou esquecer do cliente…

dukejeffrie (eita, este nick deveria ter um underline em algum lugar ;)), nao sei se entendi bem sua pergunta…

Quanto a qualidade, voce esta certo - sao todas essas caracteristicas e ainda outros adjetivos bonitos como extensibilidade, escalabilidade, manutenibilidade, etc.

Sobre a questao de desenvolver do zero versus custo de manutencao… Realmente nao acredito que um software que demorou meses para ser feito possa ser refeito em apenas uma tarde… Mas a manutencao dele tambem com certeza nao envolvera apenas uma tarde.

O que eu vejo em geral sao softwares dificeis de serem mantidos (quem ja “herdou” algum sistema ja deve ter passado por isso) - dai surge a vontade de “jogar tudo e comecar do zero” (alias, nao se engane - eu sou fan dessa tatica :)). Se o software fosse construido desde o inicio pensando nessas questoes e seguindo boas praticas, o quadro seria outro. Nao sei se esse eh apenas o cenario em que o pequeno desenvolvedor (como eu) vive e entre os “peixes grandes” (grandes equipes, grandes projetos, grandes qtdes de $$) isso seja diferente. Realmente nao sei.

Ou seja, com a qualidade do software que temos hoje realmente por vezes compensa mais jogar tudo fora e comecar do zero do que arcar com os custos de manutencao. Talvez isso possa ser visto como uma construcao. Ja esta tudo caindo mesmo, entao pra que remendar as rachaduras? Vamos demolir e refazer (da forma correta, tomara ;)).

Mas ha a outra realidade, sistemas em que partir pra essa solucao radical eh literalmente impensavel - imagine os sistemas de transacoes bancarias e outros setores criticos. Ate hoje tem gente que mexe com COBOL com emprego garantido nessas areas. Java eh melhor que COBOL - hmmm, acho que sim. Mas e dai? Os caras querem que funcionem e pronto. Nesse caso compensa dar manutencao (mesmo que seja custosa).

O fato eh que pouca gente esta capacitada para desenvolver software de qualidade (com aquelas caracteristicas que ja comentamos). E nao quero me eximir disso - eu ainda nao tenho conhecimentos suficientes para fazer um diagrama UML bem detalhadinho (inclusive nao sei se isso influenciaria em alguma coisa na qualidade final ;)).

Bom, fechando, quero colocar um dos motivos (IMHO) desse problema: dh facil entrar na nossa area. Com medicos, engenheiros e advogados a coisa eh um pouco diferente.

Se alguem quiser discordar de algo ou ainda dar dicas/sugestoes PRATICAS de como desenvolver software de qualidade, esteja a vontade.

Marcio Kuchma

Opa - depois comente como foram suas experiencias. Tambem tenho interesse nessa area.

Marcio Kuchma

Acho que vocês estão assistindo muito Matrix e Exterminador do Futuro.