No dia 20 de janeiro assisti a uma palestra no IME-USP do Petr Mitrichev sobre algoritmos e como as equipes russas fazem seus treinamentos para a Maratona de Programação da ACM (ICPC). Quando saí da apresentação lembrei de um post que vi em um site de um norte-americano criticando campeonatos e competições de computação, mostrando, para isso, vários pontos que, para o autor, são irrelevantes ou até prejudiciais para um desenvolvedor, profissionalmente falando. Partindo disso, criei este artigo, para dizer o que acho sobre essas duas visões.

Para quem não conhece, Mitrichev é um dos mais bem sucedidos programadores na Maratona de Programação, tendo participado algumas vezes e sempre ficando entre os primeiros colocados na final mundial. Participa, também, de outras formas de competição de algoritmos online, como TopCoder e Google Code Jam. Ele foi formado com honra na Universidade de Moscou, onde hoje ensina alunos suas técnicas, para que os russos continuem entre os primeiros do mundo em algoritmos. Ah, sim, ele também é desenvolvedor do Google na Rússia, faz artigos de algoritmos de todos os tipos e é palestrante. E, sim, esse é um dos caras que eu mais respeito nessa área.

Resumidamente, o artigo que era contra competições tinha como base os seguintes pontos:

Campeonatos de programação:

• tornam os programadores inflexíveis

• estimulam o competidor a criar códigos ilegíveis

• não desenvolve o lado de orientação a objetos dos competidores

• criam competidores, não profissionais

Cada um desses pontos possui algo que não condiz com a realidade, já que o próprio Petr poderia ser um exemplo de profissional que é excelente, possui o oposto de cada um desses itens e é um dos maiores competidores do mundo. Mas, ao invés de dizer apenas isso, vou mostrar o porquê de cada ponto ser inválido.

01. Inflexibilidade, neste caso, seria a postura de um programador diante de uma proposta melhor que a dele, ou uma discussão de como determinada atividade deve ser realizada. De acordo com o texto, um profissional deve ser aberto a propostas melhores para os desenvolvedores e para o cliente, não um profissional que somente aceita uma forma de se fazer algo ou, pior, apenas a forma que ele mesmo tenha feito, que por algum motivo ache que é a melhor.

Claro que o profissional precisa ser flexível, mas essa visão de que a competição torna os desenvolvedores inflexíveis não é válida. Primeiramente, porque a maratona de programação é realizada em grupo de três participantes para apenas um computador, o que obriga os participantes a discutirem as melhores soluções, já que são problemas bem complexos; muitas vezes os participantes têm afinidades com partes diferentes do problema, que deve ser resolvido no menor tempo possível, o que é exatamente o que acontece em uma empresa.

Outro motivo de a inflexibilidade não ser uma característica da competição é que cada integrante estuda diversas formas de se resolver um problema, nesse estudo ele precisa ser flexível quanto ao que ele sabe e está vendo de novidade, já que precisa mesclar o novo com o que ele já sabe ou, muitas vezes, excluir o que ele já sabe para implementar apenas o novo para esse problema em específico.

02. Muitos algoritmos feitos durante uma competição de programação possuem códigos difíceis de ler, isso é verdade, mas generalizar a característica do desenvolvedor sobre criar códigos ilegíveis está totalmente errado. Os motivos de esses códigos serem ilegíveis após a maratona são muitos, mas o principal é pelo tempo disponível para a competição. São cinco horas para resolver o máximo de problemas possível, isso faz com que a equipe pense de forma minimalista, apenas com a proposta de resolver a proposta, muitas vezes uma idéia geral é colocada em grupo pela equipe e um dos participantes começa a desenvolver da maneira que vem a cabeça, no meio do problema algum participante encontra alguma idéia errada sobre o algoritmo, fazendo com que o mesmo seja refeito ou modificado, criando novas variáveis e estrutura de dados diferentes. Essas mudanças, somadas ao tempo curto e à complexidade do problema, tornam o código muito difícil de ser lido posteriormente. Mas, de forma nenhuma isso implica no dia-a-dia do desenvolvedor na criação de seus códigos profissionalmente. Uma coisa muito importante dos principais desenvolvedores e competidores é que, após a maratona, eles pegam a prova feita e refazem tudo, desde os problemas que foram feitos com sucesso até os que não foram possíveis. Assim, criam a solução para o mesmo problema, mas de forma mais elegante e clara, até mesmo criando ou adicionando métodos genéricos à sua biblioteca de códigos.

Ainda sobre códigos ilegíveis, precisa ser explicado o parâmetro de ilegibilidade… já que existem algoritmos extremamente complexos que só podem ser feitos de uma forma, podemos dizer, bem matemática, ou seja, esses algoritmos possuem em sua natureza propriedades bem matemáticas, muitas vezes muito incomuns aos olhos da maioria dos programadores do mercado. O que, de forma alguma, faz com que esse algoritmo possa ser considerado ilegível, muito pelo contrário, são algoritmos bem eficientes e eficazes. Nada impede que esses algoritmos sejam encapsulados em métodos que apenas sejam chamados para resolverem os problemas sem nunca ser preciso sua mudança. É o que acontece com as bibliotecas que usamos no dia-a-dia e até mesmo nas linguagens de programação. Se estiverem com dúvidas, vejam a classe String do Java (uma das classes que acho mais interessantes), essa classe tem todos os métodos de string como replace, concat, indexOf, etc… cada um desses métodos foi escrito com algoritmos bem eficientes, porém poucos nem mesmo sabiam que teorias estavam sendo aplicadas em cada um deles para isso.

03. Sobre orientação a objetos pode-se falar o mesmo que sobre os códigos ilegíveis (tempo de resolução muito curto). Mas, mais importante que isso, é que orientação a objetos são apenas paradigmas para melhor organização de códigos, facilidade de manutenção, etc. Sim, tudo é importante, mas a orientação a objetos não resolve o problema em si, mas sim a implementação dos próprios algoritmos que resolve. A orientação a objetos é bem mais simples do que a lógica que será implementada para a resolução, escalonamento, regras de negócio, etc. Continuando… a hipótese de o profissional que sabe muito sobre orientação a objetos não saber resolver determinados tipos de problemas bem úteis é muito mais provável do que o inverso. E para finalizar essa parte, grande parte das linguagens de mercado utilizadas atualmente já forçam a utilização de orientação a objetos no próprio uso da linguagem.

04. Essa última afirmação é bem genérica, dizendo que o profissional que os campeonatos ‘formam’ não é o profissional que o mercado espera. Hmm, veremos… O competidor para atingir certo grau de entendimento do problemas propostos precisa se dedicar bastante, já que a estrutura dos enunciados é bem específica, o conhecimento das maratonas de programação abrange cálculos, otimização de dados, geometria etc, no mínimo o competidor precisa se dedicar e ser auto-didata, para resolver os problemas precisa-se velocidade, bastante lógica e prática, quando algum problema não passa nos testes, o competidor precisa entender e reler o enunciado e corrigir o problema do algoritmo, requer prática com testes e bom entendimento do enunciado, os problemas têm tempos-limite muito curtos, o que força o competidor a fazer o algoritmo da melhor forma possível. Por fim, esses competidores participam de listas de e-mail, fóruns de discussão, encontros nas faculdades e sites técnicos para discutirem sobre seus problemas e soluções, o que requer boa comunicação e participação de equipe. Será que não é esse o profissional que as empresas querem?

Esse blog que eu li sobre isso não se encontra no ar (deve estar na estatística dos blogs que nascem e morrem antes dos 5 anos rs), mas algum motivo o fez escrever aquele post, talvez por não ter participado na maratona, talvez por ter conhecido algum “mau competidor”. Caso ele tivesse ido na apresentação do Petr Mitrichev, talvez não teria feito isso.