Autora: Marina Joranhezon

Commits

Em geral, achei que os commits dados foram bons, no sentido de que passavam a idéia do
que estava sendo adicionado em cada um deles. Porém, achei que algumas mensagens
escritas neles poderiam ter sido mais bem detalhadas, de maneira a mostrar não só o que
foi adicionado, mas o seu propósito(Ex: Acho que nesse commit poderia ter uma explicação
do propósito da calculadora
https://github.com/nuk/codemood/commit/fc3e83bea8ac39080ed4b4aff199cc6d4f72633e​.)

Além disso, notei que algumas linhas de códigos foram adicionados dentro de comentários,
mas que nunca foram retiradas de lá, pelo menos até a versão atual do repositório. Acho
que, nesse caso, seria interessante talvez nem commitar tais linhas de comentário, visto
que não foram utilizadas antes e não estão sendo utilizadas até o
momento(Ex:​https://github.com/nuk/codemood/commit/6fccea4912a0cfdeca87d48b29f7019f
82aa0641#diff-e31bdf70b15c8f84344c332efe06900d​ no arquivo database.yml, linhas 1 a 5).

Código

Analisando o código, mais especificamente os arquivos: github_collector.rb,

lastfm_collector.rb e mood_calculator.rb em relação à alguns princípios de clean code, tive
as seguintes considerações:
● Keep it simple: As funções das classes respectivas de cada arquivo são bem
objetivas, seguindo bem esse padrão;
● Don’t Repeat Yourself: O código está bem escrito e não se repete, chamando
funções que realizam outra atividade quando necessário, evitando repetição no
código;
● You Aren’t Gonna Need It: Além disso, em alguns arquivos, notei a presença de
inserção de código comentado, que não foi utilizado anteriormente e nem foi
utilizado posteriormente, o que me leva a crer que não era necessário a sua
inserção;
● Favor readability: Cada função do código está bem objetiva, fazendo com que sejam
pequenas e de fácil leitura. Porém, senti falta de alguns comentários em relação ao
propósito de cada função, mais detalhes na seção de sugestões.

Também notei que o código segue boas práticas em relação ao SOLID, em especial
gostaria de destacar os princípios Single-responsibility principle e open-closed principle, que
senti estarem bem utilizados no código. Cada função realiza apenas uma ação específica e
as classes estão separadas de maneira a poderem ser utilizadas por outras classes, mas
não modificadas.

Além disso, gostei da criação de testes toda vez que foi escrito mais uma parte do código.
Isso ajuda a minimizar a frequência em que erros são commitados e levados para o
repositório. Apenas uma dúvida, por que os testes estão na pasta spec e não na test?
Inicialmente, acreditei não ter sido feito testes para o código, mas com uma análise mais
detalhada do commits consegui ver e fazer uma pesquisa inicial sobre spec.

Sugestões

Acho que seria interessante adicionar mais comentários aos componentes do código, de
maneira a explicar não o seu funcionamento, mas sim o que ele representa, que tarefa ele
realiza no fluxo do projeto. Dessa maneira, imagino que seja mais fácil para que
desenvolvedores que não estão familiarizados com a aplicação entendam o funcionamento
do projeto mais rapidamente. Além disso, creio que o projeto se beneficiaria disso a longo
termo no quesito da escalabilidade. No momento, ele é pequeno em termos de arquivos e
linhas de código, mas se por um acaso seja necessária a expansão desse projeto, pode-se
causar confusões mais na frente sobre o entendimento do fluxo de diálogo do sistema.