Sistemas O.O. não são apropriados para grandes demandas (milhares de transações/hora)

[quote=victorwss]Bem, cheguei atrasado, mas vou dar o meu pitaco:

A maior parte dos programas encontrados em bancos e instituições financeiras realmente não são feitos com metodologia OO. Tampouco metodologia estruturada, nem funcional, nem qualquer outra assim. Eles usam a exata metodologia que é a mais usada de todas: A POG.

Dos sistemas bancários que já vi e já ouvi falar, o que vejo em comum entre eles é a grande quantidade de remendos, erosão e subversão de suas arquiteturas e estruturas e grande desorganização. Não muito diferente do que a maioria dos sistemas feitos em java, em C ou mesmo na melhor linguagem que você puder imaginar, mesmo que a linguagem seja muito boa, não há remédio para programadores ruins. É óbvio que há programas bons rodando e eles melhoram com o tempo, mas grande parte é gambi.

Estes sistemas tem o seu sucesso por motivos bem diferentes do que a linguagem de programação usada:

[list]O hardware é rápido.[/list]
[list]Os programas passaram por vários remendos para corrigir bugs (e são muitos bugs). Há um medo muito grande de qualquer mudança para evitar que novos bugs sejam inseridos (refactoring torna-se algo proibido). Quando as mudanças são necessárias elas sempre ocorrem da forma que menos altere/afete código já existente, por pior que este seja. Com o passar dos anos o sistema fica estabilizado, mesmo se for mal-projetado e mesmo que pemaneçam alguns bugs menores não corrigidos.[/list]
[list]Os sistemas em geral rodam isolados uns dos outros (frequentemente fisicamente), e se comunicam entre si por uma série de meios distintos, entre eles escrita e leitura arquivos em formato texto ou binário, sockets, banco de dados relacionais, webservices SOAP, POX+HTTP+REST e mais um monte de outras coisas. O motivo de isso ter ocorrido é que cada um deles foi concebido em separado para fazer uma determinada coisa (como é de se esperar em qualquer lugar), de forma que no final “o sistema” seja na verdade algumas dezenas ou centenas de sistemas independente se comunicando entre si. Isto tem a vantagem de que cada ponto pode evoluir (e até ser completamente substituído) de forma independente sem afetar muito os demais. Também é uma vantagem que, embora nem sempre tenha sido inicialmente planejado, isto acaba trazendo escalabilidade. As grandes desvantagens são a grande desorganização e a heterogenidade.[/list]
[list]Existe bastante intervenção humana.[/list]

Enfim, um dos maiores mitos que existem na área de sistemas de bancos e outras instituições financeiras é que eles são muito bem arquitetados, confiáveis e rápidos. Isso daí é simplesmente uma grande mentira. Dizer que eles são bem arquitetados, confiáveis e rápidos porque não são OO é mentir duas vezes.

OO é sim apropriada (e muito bem apropriada, diga-se de passagem) para grandes demandas de milhares de transações por hora. Não é a linguagem que determina se é ou se não é, é a infraestrutura de rede, a organização interna dos servidores e o hardware que determina isso.[/quote]
concordo plenamente com cada letra e virgula do que escreveste… exacto acho que tens toda a razao

[quote=sulito][quote=victorwss]Bem, cheguei atrasado, mas vou dar o meu pitaco:

A maior parte dos programas encontrados em bancos e instituições financeiras realmente não são feitos com metodologia OO. Tampouco metodologia estruturada, nem funcional, nem qualquer outra assim. Eles usam a exata metodologia que é a mais usada de todas: A POG.

Dos sistemas bancários que já vi e já ouvi falar, o que vejo em comum entre eles é a grande quantidade de remendos, erosão e subversão de suas arquiteturas e estruturas e grande desorganização. Não muito diferente do que a maioria dos sistemas feitos em java, em C ou mesmo na melhor linguagem que você puder imaginar, mesmo que a linguagem seja muito boa, não há remédio para programadores ruins. É óbvio que há programas bons rodando e eles melhoram com o tempo, mas grande parte é gambi.

Estes sistemas tem o seu sucesso por motivos bem diferentes do que a linguagem de programação usada:

[list]O hardware é rápido.[/list]
[list]Os programas passaram por vários remendos para corrigir bugs (e são muitos bugs). Há um medo muito grande de qualquer mudança para evitar que novos bugs sejam inseridos (refactoring torna-se algo proibido). Quando as mudanças são necessárias elas sempre ocorrem da forma que menos altere/afete código já existente, por pior que este seja. Com o passar dos anos o sistema fica estabilizado, mesmo se for mal-projetado e mesmo que pemaneçam alguns bugs menores não corrigidos.[/list]
[list]Os sistemas em geral rodam isolados uns dos outros (frequentemente fisicamente), e se comunicam entre si por uma série de meios distintos, entre eles escrita e leitura arquivos em formato texto ou binário, sockets, banco de dados relacionais, webservices SOAP, POX+HTTP+REST e mais um monte de outras coisas. O motivo de isso ter ocorrido é que cada um deles foi concebido em separado para fazer uma determinada coisa (como é de se esperar em qualquer lugar), de forma que no final “o sistema” seja na verdade algumas dezenas ou centenas de sistemas independente se comunicando entre si. Isto tem a vantagem de que cada ponto pode evoluir (e até ser completamente substituído) de forma independente sem afetar muito os demais. Também é uma vantagem que, embora nem sempre tenha sido inicialmente planejado, isto acaba trazendo escalabilidade. As grandes desvantagens são a grande desorganização e a heterogenidade.[/list]
[list]Existe bastante intervenção humana.[/list]

Enfim, um dos maiores mitos que existem na área de sistemas de bancos e outras instituições financeiras é que eles são muito bem arquitetados, confiáveis e rápidos. Isso daí é simplesmente uma grande mentira. Dizer que eles são bem arquitetados, confiáveis e rápidos porque não são OO é mentir duas vezes.

OO é sim apropriada (e muito bem apropriada, diga-se de passagem) para grandes demandas de milhares de transações por hora. Não é a linguagem que determina se é ou se não é, é a infraestrutura de rede, a organização interna dos servidores e o hardware que determina isso.[/quote]
concordo plenamente com cada letra e virgula do que escreveste… exacto acho que tens toda a razao[/quote]

++

[quote=victorwss]Bem, cheguei atrasado, mas vou dar o meu pitaco:

A maior parte dos programas encontrados em bancos e instituições financeiras realmente não são feitos com metodologia OO. Tampouco metodologia estruturada, nem funcional, nem qualquer outra assim. Eles usam a exata metodologia que é a mais usada de todas: A POG.

Dos sistemas bancários que já vi e já ouvi falar, o que vejo em comum entre eles é a grande quantidade de remendos, erosão e subversão de suas arquiteturas e estruturas e grande desorganização. Não muito diferente do que a maioria dos sistemas feitos em java, em C ou mesmo na melhor linguagem que você puder imaginar, mesmo que a linguagem seja muito boa, não há remédio para programadores ruins. É óbvio que há programas bons rodando e eles melhoram com o tempo, mas grande parte é gambi.

Estes sistemas tem o seu sucesso por motivos bem diferentes do que a linguagem de programação usada:

[list]O hardware é rápido.[/list]
[list]Os programas passaram por vários remendos para corrigir bugs (e são muitos bugs). Há um medo muito grande de qualquer mudança para evitar que novos bugs sejam inseridos (refactoring torna-se algo proibido). Quando as mudanças são necessárias elas sempre ocorrem da forma que menos altere/afete código já existente, por pior que este seja. Com o passar dos anos o sistema fica estabilizado, mesmo se for mal-projetado e mesmo que pemaneçam alguns bugs menores não corrigidos.[/list]
[list]Os sistemas em geral rodam isolados uns dos outros (frequentemente fisicamente), e se comunicam entre si por uma série de meios distintos, entre eles escrita e leitura arquivos em formato texto ou binário, sockets, banco de dados relacionais, webservices SOAP, POX+HTTP+REST e mais um monte de outras coisas. O motivo de isso ter ocorrido é que cada um deles foi concebido em separado para fazer uma determinada coisa (como é de se esperar em qualquer lugar), de forma que no final “o sistema” seja na verdade algumas dezenas ou centenas de sistemas independente se comunicando entre si. Isto tem a vantagem de que cada ponto pode evoluir (e até ser completamente substituído) de forma independente sem afetar muito os demais. Também é uma vantagem que, embora nem sempre tenha sido inicialmente planejado, isto acaba trazendo escalabilidade. As grandes desvantagens são a grande desorganização e a heterogenidade.[/list]
[list]Existe bastante intervenção humana.[/list]

Enfim, um dos maiores mitos que existem na área de sistemas de bancos e outras instituições financeiras é que eles são muito bem arquitetados, confiáveis e rápidos. Isso daí é simplesmente uma grande mentira. Dizer que eles são bem arquitetados, confiáveis e rápidos porque não são OO é mentir duas vezes.

OO é sim apropriada (e muito bem apropriada, diga-se de passagem) para grandes demandas de milhares de transações por hora. Não é a linguagem que determina se é ou se não é, é a infraestrutura de rede, a organização interna dos servidores e o hardware que determina isso.[/quote]

Victor, falou tudo!

concordo com cada palavra!

sem falar que vc não precisa fazer 100% OO.

Vc pode ter a parte de regra de negócios, por exemplo, e o resto ser “procedural”, “funcional” ou até mesmo implementado diretamente em hardware.

[quote=victorwss]Bem, cheguei atrasado, mas vou dar o meu pitaco:

A maior parte dos programas encontrados em bancos e instituições financeiras realmente não são feitos com metodologia OO. Tampouco metodologia estruturada, nem funcional, nem qualquer outra assim. Eles usam a exata metodologia que é a mais usada de todas: A POG.

Dos sistemas bancários que já vi e já ouvi falar, o que vejo em comum entre eles é a grande quantidade de remendos, erosão e subversão de suas arquiteturas e estruturas e grande desorganização. Não muito diferente do que a maioria dos sistemas feitos em java, em C ou mesmo na melhor linguagem que você puder imaginar, mesmo que a linguagem seja muito boa, não há remédio para programadores ruins. É óbvio que há programas bons rodando e eles melhoram com o tempo, mas grande parte é gambi.

Estes sistemas tem o seu sucesso por motivos bem diferentes do que a linguagem de programação usada:

[list]O hardware é rápido.[/list]
[list]Os programas passaram por vários remendos para corrigir bugs (e são muitos bugs). Há um medo muito grande de qualquer mudança para evitar que novos bugs sejam inseridos (refactoring torna-se algo proibido). Quando as mudanças são necessárias elas sempre ocorrem da forma que menos altere/afete código já existente, por pior que este seja. Com o passar dos anos o sistema fica estabilizado, mesmo se for mal-projetado e mesmo que pemaneçam alguns bugs menores não corrigidos.[/list]
[list]Os sistemas em geral rodam isolados uns dos outros (frequentemente fisicamente), e se comunicam entre si por uma série de meios distintos, entre eles escrita e leitura arquivos em formato texto ou binário, sockets, banco de dados relacionais, webservices SOAP, POX+HTTP+REST e mais um monte de outras coisas. O motivo de isso ter ocorrido é que cada um deles foi concebido em separado para fazer uma determinada coisa (como é de se esperar em qualquer lugar), de forma que no final “o sistema” seja na verdade algumas dezenas ou centenas de sistemas independente se comunicando entre si. Isto tem a vantagem de que cada ponto pode evoluir (e até ser completamente substituído) de forma independente sem afetar muito os demais. Também é uma vantagem que, embora nem sempre tenha sido inicialmente planejado, isto acaba trazendo escalabilidade. As grandes desvantagens são a grande desorganização e a heterogenidade.[/list]
[list]Existe bastante intervenção humana.[/list]

Enfim, um dos maiores mitos que existem na área de sistemas de bancos e outras instituições financeiras é que eles são muito bem arquitetados, confiáveis e rápidos. Isso daí é simplesmente uma grande mentira. Dizer que eles são bem arquitetados, confiáveis e rápidos porque não são OO é mentir duas vezes.

OO é sim apropriada (e muito bem apropriada, diga-se de passagem) para grandes demandas de milhares de transações por hora. Não é a linguagem que determina se é ou se não é, é a infraestrutura de rede, a organização interna dos servidores e o hardware que determina isso.[/quote]

Eu não só concordo como ratifico, tendo em vista que esse cenário é o meu dia-a-dia… Não tiro nem uma vírgula do que disseste…

Abs []

É vero, metodologia POG, com projeto Ágil a la XGH é a tendencia!!

Eu não digo nem tendência, mas é como o Víctor colocou lá em cima… o medo de mecher no que já está funcionando é tão grande…

É quase como se fizéssemos um castelo de cartas, onde em um determinado momento, a construção do mesmo se estabilizou… O medo de que ele caia é tão grande que (e isso é sério) NINGUÉM quer que você mecha no que “está funcionando”…

Não adianta trazer argumentos, não haverá ninguém que vai se responsabilizar pela cagada…

Se você conversar com quem nasceu o filho, eles defenderão com unhas e dentes… Se conversar com alguém que entrou no meio do Processo, ele diz que até queria que fosse diferente, mas que não adianta tentar… Ou seja, a maioria quer mudança, mas ninguém quer assinar a mudança…

É desse cenário que eu não vejo a hora de sair, afinal, acabamos dançando conforme a música… :frowning:

Isso é complicado viu, eu mesmo estava(estou) dando manutenção em um programa que tem algumas bizarrices e partes obscuras… O cara que começou o projeto já está longe, na verdade já estou na “terceira geração” de desenvolvedores mechendo no sistema e não se tem tempo de ficar refatorando o código, pois a cada dia os clientes pedem uma funcionalidade diferente, e do jeito que a coisa tá, se começar a modificar vai demorar um bom tempo até corrigir tudo e fazer ficar funcionando de novo :frowning: :oops:

Esta é uma visão muito simplista.
A verdade é que na maioria dos casos seria uma IRRESPONSABILIDADE mexer no que está funcionando.
Quem nunca trabalhou na TI de um Banco (só pra ficar no caso clássico de legado) não tem a mínima idéia da quantidade de sistemas, do tamanho, da complexidade, e do tempo que se levou para que tudo esteja simplesmente funcionando.
Não tem a menor (e isso não é exagero) idéia de tudo o que ocorre quando aperta um botão no caixa eletrônico ou clica em algum botão no internet banking.
Estes sistemas estão sob constante ameaça de erros que causam a insatifação e até a perda de clientes, processos judiciais, multas de orgãos regulatórios, etc.
Imaginem então o risco que representa para estas empresas reconstruir tudo do zero!
Isto NUNCA vai acontecer.
Sem contar que o mainframe é uma máquina espetacular, não pode ser comparada com nenhuma outra opção comercial.
O mainframe é eterno, o cobol é eterno, pelo menos enquanto o mundo for o mundo que conhecemos.
Tudo o que o vitorwss falou é verdade, e vai continuar assim indefinidamente.
Afinal, o objetivo destas empresas não é fazer sistemas bonitos, mas simplesmente funcionarem.

Verdade… É o castelo de carta delicado que seria difícil e demorado reconstruir de novo…

Meus 5 centavos de contribuição: Big Ball of Mud.

Inté.

Não é só banco, a maioria das grandes empresas que a tecnologia não é atividade fim são conservadoras na hora de atualizar-se e refatorar código. Estabilidade é mais importante que atualização tecnológica e sai mais barato atualizar o hardware que o software.

Só pra citar um caso interessante, onde trabalho hoje eles usam Java pra web, com uma biblioteca javascript própria, que tem compatiblidade até com o IE 3 e Netscape 4. Foi a maior luta convencê-los a retirar o código de compatibilidade antigo, queriam me matar, mesmo que há anos não usássemos mais e mesmo os sites externos, quantos ainda acessam web por um Windows 95?

No final, consegui deixar até o IE 5, já podemos utilizar CSS. hehehe
E os programas java quero atualizar os 100% servlets, pelo menos deixar os apps JSP pra cima.

bem, eu tenho uma certa experiência com instituições financeiras…

no meu antigo emprego, que a maioria dos clientes eram bancos, a linguagem predominante era sem dúvida c/c++ + cobol…

primeiramente eu acho que vai demorar séculos para um banco trocar seu cobol / mainframe / db2…

o que eu vi acontecendo é que a parte transacional tem sido repensada, porém a validação, regras de negócios, etc, ainda ficam no mainframe…

o maior problema é ver alguns frameworks próprios horríveis que os bancos estão usando…

eu trabalhei cerca de 1 ano e meio em projetos para apenas um banco, um dos maiores do brasil… e posso afirmar que o ambiente que eles possuem utilizando ansi c é maravilhoso… muito bom, estável e fácil de desenvolver novas aplicações… aliás c é maravilhoso. porém eles vieram com uma plataforma nova em java, e sinceramente, não há nada mais escroto e instável que aquilo, e definitivamente foi um dos motivos de eu ter largado este emprego, pois era extremamente broxante trabalhar com algo tão mal feito…

a questão não é saber se OO é melhor que estruturado, a questão é saber quais são as melhores opções que você tem e fazer direito.

[quote=Rafael Marques]bem, eu tenho uma certa experiência com instituições financeiras…

no meu antigo emprego, que a maioria dos clientes eram bancos, a linguagem predominante era sem dúvida c/c++ + cobol…

primeiramente eu acho que vai demorar séculos para um banco trocar seu cobol / mainframe / db2…

o que eu vi acontecendo é que a parte transacional tem sido repensada, porém a validação, regras de negócios, etc, ainda ficam no mainframe…

o maior problema é ver alguns frameworks próprios horríveis que os bancos estão usando…

eu trabalhei cerca de 1 ano e meio em projetos para apenas um banco, um dos maiores do brasil… e posso afirmar que o ambiente que eles possuem utilizando ansi c é maravilhoso… muito bom, estável e fácil de desenvolver novas aplicações… aliás c é maravilhoso. porém eles vieram com uma plataforma nova em java, e sinceramente, não há nada mais escroto e instável que aquilo, e definitivamente foi um dos motivos de eu ter largado este emprego, pois era extremamente broxante trabalhar com algo tão mal feito…

a questão não é saber se OO é melhor que estruturado, a questão é saber quais são as melhores opções que você tem e fazer direito.[/quote]

Java roda em um Segmento OMVS do Mainframe ou no zLinux. A IBM ja ofereceu onde eu trabalho desconto pros MIPS do java. Assim eles podem rodar WebSphere com tudo que se tem direito no z10 ou no zEnterprise. Qual o custo/benefício? Não sei, mas me chamou a atenção.

Porém ainda tem o mal do trabalhador que não se capacita e não se atualiza. Ai mantem-se o que está.

Isso vale na plataforma baixa também que permite gestores preferirem contratar 10 programadores dotNet mediocres bem baratinho (tem também ainda os que vieram do VB6/ASP) que contratar 2 bons e caros programadores java. E da espaço pros mesmos fazerem afirmações sobre o dotNet com VB ser melhor que o mesmo java oferecido pela IBM em seus produtos.

Galera pelo amor do Pai…

Os bancos não vão migrar os legados em MainFrame por questões financeiras, isto é determinação executiva e não vem de nehnum comitê de IT, eles não estão nem ai para linguagem procedural ou O.O, o banco se importa é com custos e os custos de migração são altos de mais e ainda não justificáveis.

Foram gastos no mínimo 30 anos em desenvolvimento e manutenção desses legados, sem contar as enormes perdas da epóca da Reengenharia onde tentou-se fazer isso e não deu certo. O problema não é técnico é financeiro.

Já citaram lá atrás que as Telecom operam plataformas baseadas Java e na sua maioria aqui no Brasil utilizando um SOA através de uma solução de mercado com Oracle SOA Suite e antiga BEA e as coisas vão bem, dão conta milhões de transações.

Existe uma pressão para a troca de tecnologia nos bancos que vai aumentando ano a ano, essa pressão tem como causa a falta de profissionais Mainframe, por isso muitos bancos investem na formação desses profissionais ou vão atrás do pessoal de mainframe aposentado. Pode não estou afirmando que vai acontecer de que em um determinado momento a falta de profissionais possa justificar essa migração.

[quote=DaviPiala]Galera pelo amor do Pai…

Os bancos não vão migrar os legados em MainFrame por questões financeiras, isto é determinação executiva e não vem de nehnum comitê de IT, eles não estão nem ai para linguagem procedural ou O.O, o banco se importa é com custos e os custos de migração são altos de mais e ainda não justificáveis.

Foram gastos no mínimo 30 anos em desenvolvimento e manutenção desses legados, sem contar as enormes perdas da epóca da Reengenharia onde tentou-se fazer isso e não deu certo. O problema não é técnico é financeiro.

Já citaram lá atrás que as Telecom operam plataformas baseadas Java e na sua maioria aqui no Brasil utilizando um SOA através de uma solução de mercado com Oracle SOA Suite e antiga BEA e as coisas vão bem, dão conta milhões de transações.

Existe uma pressão para a troca de tecnologia nos bancos que vai aumentando ano a ano, essa pressão tem como causa a falta de profissionais Mainframe, por isso muitos bancos investem na formação desses profissionais ou vão atrás do pessoal de mainframe aposentado. Pode não estou afirmando que vai acontecer de que em um determinado momento a falta de profissionais possa justificar essa migração.

[/quote]

Bom, eu não sei quanto aos outros, mas eu não falei em migrar legado. Mas continuar desenvolvendo na tecnologia do legado vale a pena?

Outra coisa: Visual Age é legado forte em alta plataforma também e a IBM já deu uma rasteira nos compradores desse legado. O EGL não é 100% compatível e as customizações não estão previstas no conversor do fornecedor. Portanto, ao meu ver, continuar no legado sem suporte é tiro no pé.

Deixo apenas uma questão,
o Cobol é mais performático ou a infra-estrutura sobre a qual ele roda é que é muito boa?

Poucos servidores se comparam em termos de processamento que os sistemas mainframe.
Na minha visão, cobol só é realmente eficaz por atuar em mainframe, se atuasse em servidores “usuais” não teria muitos elogios e seria substituido com menos medo :wink:

Legado é algo que se troca quando o valor da manutenção supera o valor da migração com melhorias.