Quem nunca pegou um quebra-cabeça na infância e se aventurou em montá-lo. Certamente alguns não lembram dos quebra-cabeças de 20 peças que pegaram quando tinham apenas 3 ou 4 anos. Quando crescemos queremos um desafio maior, queremos aumentar o número de peças, queremos de 100 peças, depois 200, 300, e finalmente chegamos a 1000, 2000 e assim sucessivamente.
Na computação, podemos ver a evolução das linguagens de programação e de seus respectivos paradigmas e filosofias. Nos cursos de computação, até pelo menos quando paguei Linguagem de Programação I (o primeiro contato com linguagem de programação) onde estudamos pela primeira vez a linguagem Pascal e as primeiras noções de algoritmos. Ver que um algoritmo é um conjunto de ações sequênciais e estruturadas para fazer alguma coisa bem definida. Depois estudamos a programação estruturada, usando geralmente a linguagem C. Aprendemos na programação estruturada a lidar com funções e procedimentos(sem contar nos benditos ponteiros), e evitar duplicação de código e melhorar a legibilidade do código (Não pretendo discutir as características dos paradigmas, apenas comentá-los). E finalmente aprendemos o paradigma do momento, OO (Orientação a Objetos), onde conseguimos através dela modelar de forma mais eficiente os problemas da realidade, e modelá-las de forma mais consistente e fácil através de conceitos de classes e instâncias.
Atualmente no mercado usamos além da OO, os chamados frameworks . Frameworks são soluções que implementam uma série de operações que podemos utilizá-las para acelerar o nosso trabalho. Certamente o conceito e as características de frameworks vai muito além disso. Não é difícil ver no desenvolvimento de sistemas atuais uma solução que contenha uma série de frameworks onde cada um soluciona uma parte do problema.
Você pode estar pensando: “O que tem haver os benditos quebra-cabeças com esse assunto afinal?”. Simplesmente porque estamos tratando de resolver problemas. Resolver quebra-cabeça e desenvolver um sistema com certeza não têm nada haver entre si, mas levam objetivos semelhantes, montar uma solução com as peças que têm. Com certeza você deve ter ouvido que o desenvolvimento de uma solução de software pode quebrar a cabeça de alguém.
Quando estamos aprendendo programação, nossas peças são simples e limitadas, são arranjos , variáveis de inteiros, reais ou strings e comandos de repetição e decisão. Quando chegamos em programação estruturada trabalhamos com funções e procedimentos e aumentamos o tamanho e número de peças. Na OO temos peças inteiras como classes que levam dentro de si métodos, variáveis e comportamentos próprios. O tamanho das peças está crescendo a cada dia. Temos agora as peças gigantes, os frameworks. Tudo isso junto gera o maior quebra-cabeça do mundo.
Existe uma discussão até que nível programação é arte, e a partir de qual ponto passa ser uma atividade metódica e planejada (onde teoricamente a criatividade some). Talvez a visão tenha mudado, pois as peças com quais lidamos também mudaram. O desafio hoje para o exercício de nossa arte, seja além dos algoritmos eficientes que tenhamos criado no passado, nossa arte está também em sincronizar todos os recursos da tecnologia atual na construção da solução do cliente. Solução essa que não pode somente funcionar, e sim também permitir a extensão e a facilidade de manutenção conciliada a um desempenho desejado.
A arte na programação não sumiu, ela só teve suas peças ampliadas e diversificadas. Cabe a nós, profissionais de informática conhecê-las bem para sabermos a melhor hora e o melhor lugar de encaixarmos nossas peças.
Sucesso nos quebra-cabeças computacionais a todos.
