O trabalho em questão era criar um highlighter de design
patterns ruins que um desenvolvedor poderia usar na
IDE. Era específico para uma biblioteca de testes, mas a
ideia era esse algoritmo dar um highlight em
vermelho toda vez que o desenvolvedor fizer algo que
acharmos que é ruim.
Um exemplo: na nossa biblioteca, o desenvolvedor tinha que
chamar uma função chamada sync para atualizar o
código no aplicativo e de fato aplicar as mudanças. Essa
atualização é necessária, porém lenta e custosa.
Com esse detector de design patterns, poderíamos
alertar se o desenvolvedor fizer alguma má prática, como
colocar esse sync dentro de um loop, por exemplo. O
alerta era basicamente marcar a linha de má prática de
vermelho, que nem as IDEs fazem normalmente. Isso era o
motivo e o resultado do projeto.
Como ele era implementado: Nós fazemos uma árvore baseada no
código que o desenvolvedor faz: Abstract Syntax Tree
(AST). Assim, a gente pode andar pela árvore (utilizando DFS
e BFS) e procurando APIs específicas (como o sync) e
sair voltando para checar que esse sync está dentro
de um loop (por exemplo, um for é algum ancestral da
API). Nesse trabalho, eu fiz diversos patterns. Em
geral, o principal era saber andar (...) pela árvore
corretamente, (...) que era não-binária para mais contexto.
Acredito que o conhecimento de árvores da faculdade
realmente ajudou nisso!