Em 16/10/07, Roberto Mello<[EMAIL PROTECTED]> escreveu: > On 10/16/07, Angelo Augusto Frozza (UNIPLAC*) <[EMAIL PROTECTED]> wrote: > Cuidado. A empresa esta' perto de cometer o erro crucial de empresas > de software: reescrever.
A solução de reescrever deve ser pensada apenas se: 1 - Não se encontram mais profissionais para trabalhar com a linguagem escolhida a um custo acessível (ex: Cobol, muito usada em sistemas de bancos e tal, mas cada vez mais difícil encontrar programadores) 2 - O sistema possui erros estruturais impossíveis de serem solucionados sem sua reescrita 3 - Não é possível integrá-lo com outros sistemas porque o banco não tem suporte nas linguagens dos outros, ou a linguagem usada não pode ser integrada com os outros sistemas porque não tem drivers para os bancos de dados ou não suporta outra forma de integração como webservices. > Ja' vi isso em varias empresas aqui nos EUA. Querem reescrever o > sistema de linguagem X para Java ou .NET. Contrata-se um horror de > gente geralmente ganhando bem mais do que vale. Gasta-se 1 ano. O > sistema nao sai do lugar. "Precisamos de mais engenheiros Java > qualificados". Contrata-se mais um horror de gente. Isso é um fenômeno mundial, infelizmente... Só deve ser contratado mais programadores se for um novo projeto na minha opinião. > Programadores SEMPRE querem reescrever tudo que encontram pela frente, > por um unico motivo: > > Escrever codigo e' mais facil do que ler codigo. > > Entendeu? Escrever e' mais facil do que ler. Ninguem quer ler o codigo > dos outros. Nao importa qual a linguagem, a dificuldade e' parecida. Se o código pelo menos estivesse comentado... Já ajudava... Isso é um mal hábito em qualquer lugar. > Grande insercao de dados vai ser trabalho do banco de dados. > PostgreSQL e' uma otima escolha. > > Java e' uma "tendencia" em sistemas corporativos por uma unica > razao... Quando um gerente que nao entende de software precisa > escolher uma linguagem para um projeto que ele nao entende direito, a > unica coisa que ele consegue enxergar e' o outdoor da Sun altamente > iluminado, que diz "Java e' a solucao". Na verdade... eu tenho uma visão um pouco diferente, e que justifica porque aqui em Brasília há uma grande penetração do Java em relação ao PHP no Governo, enquanto em São Paulo não se fala em outra coisa que não C/C++/C#. Java é uma linguagem que surgiu dentro de uma empresa específica: SUN. A Sun, em uma bela jogada de marketing, logo em seguida lançou a certificação de programadores Java. Nesse período utilizava-se muito mais C/C++, porém a linguagem C/C++ é padrão ANSI não tendo uma certificação oficial. Com o Java tínhamos essa certificação oficial vindo da empresa criadora, e embora outras empresas até começaram a implementar um Java próprio tiveram as asinhas logo cortadas pela Sun, detentora plena dos direitos. Então, temos Java em frente a C/C++ e agora PHP. Pois bem... Java ter certificação oficial, C/C++ não (só certificação de uma ferramenta específica como um Visual C++ da vida), PHP também não (tem a certificação da Zend, mas não é oficial do PHP, é apenas da Zend que faz praticamente todo o PHP mas não é oficial). Então, para ganhar uma licitação, as empresas com seus lobistas começaram a falar "pede que tenha certificação java, nossa empresa tem". Para a época, era o ó do borogodó, porque quase ninguém tinha (hoje em dia vc acha profissinal "certificado" em qualquer bueiro), então, fixou-se isso quase como regra. Hoje em dia, mesmo quando um projeto não vai ter java, vc vê nego pedindo certificação java! Absurdo! Mas é só porque reduz o número de gente tentando participar... > Se voce perguntasse desse mesmo gerente ha' 10 anos atras qual era a > linguagem que deveria ser usada, ele responderia sem hesitacao: C++ Vide história acima. > "Padroes" de Java sao padroes criados por comite. O resultado e' o > tipico resultado de comite: uma burocracia gigante com pouco > beneficio, mas que aparenta ser muito bonitinha e segura. Tem muita > coisa boa em Java por ai. E tem _muita_ coisa ruim. Padrao ABC de > empresa XYZ nao cria bom software. Padrões são bons, não vou questionar, ajuda a homogeinizar, mas não são a solução final, nem nunca serão, são apenas isso: padrão, uma sugestão a ser utilizada... ou não. _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
