RSS Feed
Jan 16

Novas linguagens de programação e software legado

Posted on Friday, January 16, 2009 in TI

Fabio Cevasco lista possíveis 10 linguagens de programação que poderiam ser aprendidas no ano de 2009. Há quem discorde da prática de aprender uma nova linguagem de programação a cada ano.

Enquanto ainda há gente rodando software em Cobol de 20 anos ou programas escritos em assembly – porque não havia outra linguagem disponível na época – há quem rode “the best and the brightest situational-Web 2.0-agile-social-networking-enabledsemantically-dense-cloud-basedsystems-of-systems-script-based software” (Booch) e, em poucas semanas, considere-o velho porque surgiu a novíssima e a melhor tecnologia dos últimos tempos da última semana (propaganda clichê).

Independentemente do mérito de aprender ou não uma nova linguagem de programação, seja por experimentação ou por demandas e necessidades mais sofisticadas, por exemplo, concorrência, faz-se necessário entender que sistemas escritos em novas linguagens possuem quase nenhuma representatividade no mercado de trabalho. Possivelmente serão Java, 14 anos de estrada, que segundo os apocalípticos já está tornando-se o novo COBOL, C, com quase 40 anos continua sendo importante no cenário na indústria, e C++, 30 anos em 2009, que pagarão suas contas. Estas são, respectivamente, as três primeiras colocadas no índice TIOBE e em muitos outros rankings. O ranking de Janeiro de 2009 esta abaixo:

TIOBE Programming Community Index for January 2009TIOBE Programming Community Index for January 2009

Muitos novos profissionais frustram-se ao depararem-se com a realidade de dar manutenção em sistemas antigos, com linguagens de programação “defasadas”.  Sommerville estima que cerca de 80% do tempo de vida do software seja dedicado à manutenção e evolução. Por isto que linguagens de programação “ultrapassadas” como Visual Basic, Delphi e Perl ainda configuram na lista entre as 10 linguagens mais populares em janeiro de 2009, logo abaixo, entre as top 20, aparecem ABAP e COBOL. Não é nenhuma surpresa elas dividem espaço com linguagens mais novas.

tiobe-trends-jan2009

TIOBE Long term trends

O certo é que software legado é realidade nas empresas, encará-lo é questão de tempo. Ele existe porque tem valor para seus usuários e, principalmente, porque não é trivial substituí-lo. Cedo ou tarde as empresas deparam-se com a pergunta: o que fazer com meu software legado? Para Booch, além da natural manutenção, há outros possíveis fins para software legado:

  1. Abandoná-lo, jogar na lata do lixo;
  2. Abrir o código fonte para a comunidade;
  3. Ignorá-lo, isto é, apenas deixá-lo rodando como está hoje, por exemplo, como os bancos fazem há décadas com muitos de seus sistemas;
  4. Mantê-lo rodando em sua plataforma original, pois software legado não é multi-plataforma, tentando assim encontrar e comprar o hardware antigo onde ele roda quando a disponibilidade da plataforma é o maior desafio;
  5. Reescrevê-lo em novo ambiente, plataforma e linguagem;
  6. Inspirar-se e criar novo software baseado no conhecimento embutido no código;
  7. Encapsulá-lo em serviços, SOA, para ser usado como componentes de um novo software;
  8. Mantê-lo e evoluí-lo no seu ambiente atual;
  9. Preservá-lo, doando-o a um museu.

Importante frisar: a linguagem é apenas uma pequena parte do ecossistema técnico do desenvolvimento de um software. O melhor mesmo é aprender a programar em vários paradigmas e, de preferência, em qualquer linguagem para encarar o duro mercado de trabalho.

Referências:

Comments (0) | Tags: , , ,
Nov 10

Dicas sobre Padrões de Projetos

Posted on Monday, November 10, 2008 in TI

Dúvida de um aluno:

- Prof. Kelon, gostaria que você pudesse nos sugerir o uso de alguns padrões para utilizarmos no nosso mini-projeto. Conheço os padrões de criação Factory e Singleton. Além da própria arquitetura MVC, outros padrões que já utilizei foram o Façade e o DAO. Além destes, o senhor sugere mais algum padrão que podemos utilizar? Peço que nos passe também algum link que porventura você tenha utilizado.

A minha resposta segue logo abaixo.

Três coisas:

  1. Para poder recomendar algo, preciso conhecer melhor como você está projetando seu software e para qual ambiente;
  2. Padrões de Projeto (PP) são usados por necessidade e não ‘usar por usar’. É a mesma coisa de você querer encaixar Herança onde não existe só para depois dizer que usou polimorfismo. Sei que não é estritamente seu caso, pois entendo o que você está pedindo, porém é salutar ressaltar;
  3. Padrões de Projeto não são solução para software mal projetado. Novamente, não estou sugerindo que este seja seu caso, mas talvez seja o caso de alertá-los para ‘Buzzword bingo‘ (vídeo de comercial IBM).

Retomando o que falei no início, elaborarei um pouco mais o item (3). Volto a falar, mais uma vez, que balas de prata não existem e possivelmente nunca existirão :-) O mais próximo que temos da famigerada bala de prata são bons projetistas (arquitetos) de software (de arquiteturas), pois eles buscam direta e primariamente minimizar os problemas essenciais de software, principalmente complexidade e conformidade (com o ambiente onde é implantado). Por isto que ratifiquei o link compartilhado e enviei outro sobre o mesmo assunto: Projeto de Software Orientado a Objetos.

De nada vale usar os 23 padrões de projeto clássicos se você força uma hierarquia de classes apenas para usar determinado padrão, isto é, você adapta seu projeto para acomodar um padrão. O que deveria ocorrer é muito diferente: o projeto de sua aplicação, naturalmente, sugerirá os padrões a serem aplicados.

Por exemplo, considere o caso de um objeto exigir mudanças em outros quando ele próprio é alterado, mas você não sabe quantos outros objetos necessitam ser modificados, como em um software de segurança residencial que dispara sinal de alerta para os vários alarmes no momento que a residência é invadida. Este problema é recorrente em várias outras situações e é resolvido com o padrão Observer. A depender de como sua solução foi projetada, o padrão Observer será a solução óbvia. Claro que ter conhecimento sobre PP auxilia a pensar e projetar as soluções, porém sozinhos não resolvem problema algum. O problema de projeto de software é mais embaixo, este é o ponto.

Para aprender a projetar software OO, recomendo Larman, C. 2004 Applying UML and Patterns: an Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition). Prentice Hall PTR. Livro que vai do básico ao avançado em se tratando de análise e projeto orientados a objetos.

Conheço os padrões de criação Factory e Singleton. Além da própria arquitetura MVC, outros padrões que já utilizei foram o Façade e o DAO. Além destes, o senhor sugere mais algum padrão que podemos utilizar? Peço que nos passe também algum link que porventura você tenha utilizado.

Você já usa vários padrões sem saber (pena o link não exibir alguns dos códigos).Mas, continuando a explicação anterior, padrões de projetos são usados quando se identifica uma oportunidade para tal, isto é, quando percebe-se que determinado problema é recorrente e já tem solução disponível. Quando isto ocorre, você consulta catálogos de padrões, verifica se há um padrão que resolve o problema e lê como ele deve ser solucionado. Para isto, sugiro ler Comentários finais sobre Design Patterns, que aponta para Sinopse dos Design Patterns da “Gang of Four”, pois é um resumo bem elaborado dos padrões clássicos de GoF.A [finada?] Argo Navis tem dois ótimos cursos no tema, com material disponível para download: J930: GoF Design Patterns em Java e J931: J2EE Design Patterns. A Argo Navis ainda disponibiliza um mini-curso sobre o tema. Veja o que há nos pré-requisitos do segundo curso: “[...] É fortemente recomendado que o aluno tenha conhecimentos de Design Patterns clássicos (GoF) – pelo menos os mais importantes (Observer, Composite, Strategy, Command, Factory Method, Abstract Factory, Iterator, Proxy, Adapter, Façade, Singleton, Decorator) pois eles não serão revisados e são aplicados em vários padrões J2EE. [...]” (Grifo meu). Sendo assim, a dica é ler os dois primeiros capítulos do livro Design Patterns: Elements of Reusable Object-Oriented Software, de Gamma e demais, e depois ler esses padrões citados. O primeiro capítulo do livro explica o que são padrões de projeto, enquanto que o segundo exemplifica seu uso no projeto de um editor de textos complexo.

O livro da GoF é leitura obrigatória para qualquer engenheiro de software comprometido com sua carreira. Subindo um pouco o nível de abstração, seguem Pattern-Oriented Software Architecture: a System of Patterns, de Buschmann e colegas, e Patterns of Enterprise Application Architecture, de Fowler. No nível mais abstrato, Software Architecture in Practice, 2nd edition, de Bass, Clements e  Kazman. Catálogos de PP online:

Comment (1) | Tags: ,