Todos nós já passamos por algumas destas situações. Fazer um projeto académico é um desafio educativo, científico, mas, principalmente, de paciência. Ainda assim, o resultado é, na maioria das vezes, bastante positivo.

Ora o nosso projeto não funciona (e nós não sabemos o porquê), ora funciona (e também não sabemos como). Aqui ficam, inspirado pela apresentação de dois professores da FEUP, os 5 mandamentos dos projetos académicos.

1. Amar o nosso código sobre todas as coisas

O nosso colega de grupo não sabe o (pouco) que faz. O nosso código é muito melhor, mais conciso e auto-explicativo que o dele. Isto porque nós fomos a mais duas aulas teóricas do que ele (e as que faltamos, demos um relance sobre os slides enquanto estávamos na fila para a cantina).

Quando temos (e tentamos evitar ao máximo!) que mexer no código feito por ele, primeiro há que ultrapassar as dificuldades da formatação do código (que não estão ao nosso gosto), ao mesmo tempo que se perdem horas a fio a fazer refactoring ao código dele. Quem, no seu perfeito juízo, tem coragem de produzir código sem deixar a última linha do ficheiro em branco?

Quando ele descobre um bug no nosso código, ou sugere uma pequena alteração que permite facilitar-nos a vida, temos que garantir que ficou claro que levamos isso como um ataque pessoal. Afinal, temos a certeza que ele passou horas a testar todos os casos-limite! Depois, seguir os passos:

1. Perder horas a discutir pormenores desnecessários, utilizando expressões como “eu não percebo muito disto, mas acho que…” e “eu fiz assim porque… e da forma que tu dizes só fica mais otimizado; o output é o mesmo”.
2. Não se chegar a conclusão nenhuma, apesar de ninguém ceder (e nós já percebemos que ele tem razão).
3. Continuar a desenvolver o projeto, cada um para seu lado.
4. Aproveitar um commit grande para, no meio de tanta alteração, corrigir o tal bug ou implementar a tal pequena otimização.
5. Guardar a hash do commit e, se necessário, recuperar este assunto no próximo projeto e de como “da outra vez fui eu que cedi”.

2. Não usar o santo nome da framework em vão

“Não gosto desta framework. Nunca gostei.” Só a estamos a usar porque o nosso colega foi o primeiro a tomar a iniciativa. É muito grande, cheia de pastas, separada em muitos ficheiros com nomes complicados e nada sugestivos. Preferia a nossa estrutura do projeto anterior, que só tinha dois ficheiros (um nosso e um dele). O nosso colega queixava-se que o IDE dele ficava lento a abrir aqueles ficheiros com 2000 linhas, mas isso é porque ele é pobre, tem um computador fraco e não usa o IntelliJ.

Era só vantagens: estava tudo à mão, não tínhamos que estar à procura de nada, sabíamos exatamente onde estavam as coisas. Ou estava num ficheiro, ou estava no outro. E até já sabíamos que a função print_posts_from_db_on_screen2 (que por alguma razão imprimia em duplicado) estava entre as linhas 825 e 1337!

3. Não cobiçar os projetos alheios

A comunidade científica sempre apelou à partilha de conhecimento. Aliás, a participação em projetos open-source é algo que está na nossa to-do list já há muito tempo. Esses sim, são projetos bem feitos, arquitetados e documentados.

O outro grupo nosso amigo (sim, aquele que tem sempre 18) já fez o projeto há muito tempo. Até implementaram funcionalidades extra que não eram pedidas (mas que eles acharam relevantes), como se o professor valorizasse isso. Otários.

De certeza que não há problema em lhes pedir o projeto deles para “comparar pequenos detalhes”. Além disso, sempre nos disseram que ler o código de outras pessoas é uma atividade lúdica.

Agora que percebemos a estratégia que o outro grupo utilizou, basta esperar pela intervenção divina (ver mandamento #5) e o nosso projeto está feito! Olha, esta função aposto que vai ser igual em todos os trabalhos, mais vale não perder tempo e usá-la no nosso. Copiemos o código e os comentários, para se mais tarde precisarmos de rever aquele código, não termos de ir ver ao projeto deles de novo. Concerteza que antes de entregarmos o nosso trabalho nos vamos lembrar de retirar os comentários. Otários.

4. Não testar (nem causar semelhante transtorno, no server ou no client, neste projeto ou no próximo)

Testar é uma seca. Mas pior do que testar é ter que escrever os testes. Se fosse só carregar numa tecla, esperar uns segundos, e “aquilo” ficar tudo verde, ainda se compreendia… Para além disso, este pedaço de código é tão simples (e bem feito) que não vemos forma de futuros commits o comprometerem.

Quando na noite anterior à entrega, e depois de uma epifania da qual resultaram milhares de linhas de código (e novas funcionalidades), as funcionalidades antigas deixam de funcionar, culpamos a framework (que é bastante confusa), a linguagem (que é considerada pelos mais importantes filósofos, desde há milhares de anos, como falível) e, claro, o nosso colega. Não fazemos sequer ideia qual a alteração que foi crítica, pois o último commit tem como mensagem first commit, initial setup e o nosso querido colega está a escrever o relatório. Mais vale dar ctrl+z até funcionar de novo.

No fim, chegamos, inevitavelmente, sempre há mesma conclusão: se nem o professor vai testar, porque é que nós o haveríamos?

5. A Grande Expansão (ou o Big Bang)

O código está em expansão. Disso nenhum de nós tem dúvidas. Mas para evitar contrariar as leis da física, também esta expansão deve ser lenta e gradual, possivelmente infinita. Quando a data de entrega se aproxima, de tão pequeno e condensado que o projeto se encontra, dá-se o Big Bang, a grande explosão, numa corrida contra-relógio para se evitar o Big Crush.