Uma das coisas infelizes que o LibreOffice herdou, após várias décadas valendo uma dívida técnica em aberto, é o código sem uso que ficou largado por ai indefinidamente. Isso realmente não ajuda quando misturada ao peso e profundidade do código válido que temos. Caolán McNamara da Red Hat escreveu uma bela ferramenta callcatcher que identifica esses métodos sem uso, e recentemente ficamos com um arquivo unusedcode.easy na raiz de nosso código com uma lista de métodos a remover. É muito fácil achar e remover um método ou dois, basta um git grep, e criar um patch para a lista dos desenvolvedores. Para fugir de uma pilha de tarefas administrativas recentes, arranjei um script Perl para mastigar a saída do git numstat para ver como é que ficamos nessa história. O resultado foi o seguinte gráfico:
Parece que mais da metade de nosso código sem uso já ficou pra trás. Infelizmente, enquanto varremos o lixo pra fora, mais lixo aparece, bem observados nos pinotes pra cima no gráfico, ainda que a tendência é claramente ladeira abaixo. Se você quer se envolver com o desenvolvimento do LibreOffice, não pode ser mais fácil do que isso, faça o checkout do código e mande ver a sua vassoura.
Se não for no LibreOffice, por que você não roda o callcatcher do Caolán no seu projeto para ver as rebarbas e bolas quadradas que sobraram dos requerimentos?
Tradução voluntária: Olivier Hallot
Fonte: Post de Michael Meeks no blog da The Document Foundation
Olá Pessoal,
ResponderExcluirEmbora um intrigante artigo este, preciso dar um alerta oriundo de minha experiência de alguns bons anos como desenvolvedor... antes de sair tirando código, é essencial conhecer os padrões de projeto utilizados e os detalhes arquiteturais do programa, para que se conheça a natureza do código sendo removido. Ou seja: este código é mesmo inútil?? Será que não se trata de um código que não está em uso no momento mas poderá com grandes chances vir a ser usado?? Talvez um código que possa ser chamado externamente, por um plug-in?? Embora possivelmente haja mesmo código obsoleto no programa, nem sempre responder a estas perguntas é fácil e nem sempre um método que nunca é chamado deve ser retirado do código do programa...
Contudo, vejam que interessante: muitas vezes, há dois métodos que estão sendo usados, porém ambos realizando a mesma coisa, porém com códigos diferentes. Uma boa refinada no código elimina os métodos duplicados e diminui a quantidade de código do programa.
Em suma, gostaria de dizer que refinar e otimizar código não é uma coisa simples nem automática, de forma que necessita de muita intervenção humana e especialmente um bom conhecimento da arquitetura do sistema.
Olá Pajé
ExcluirSua preocupação é perfeitamente compreensível, quem já desenvolveu código sempre pensa que uma coisa descartada pode servir um dia no futuro. O x da questão é "Será que o lugar para deixar um código morto é no meio de um código 'vivo'"?
Eu cito Eric Raymond na "Catedral e o Bazar" no capítulo 2 (http://pt.wikisource.org/wiki/A_Catedral_e_o_Bazar/II)
"3. ``Planeje jogar algo fora; você irá, de qualquer maneira. (Fred Brooks, ``The Mythical Man-Month, Capítulo 11)
Ou, colocando de outra forma, você frequentemente não entende realmente o problema até depois da primeira vez que você implementa uma solução."
e no capítulo 6:
'13. "A perfeição (em projetar) é alcançada não quando não há mais nada a adicionar, mas quando não há nada para jogar fora."
Quando o seu código está ficando tão bom quanto simples, é quando você sabe que está correto'
Afora a menção da literatura, o código do LibreOffice é oriundo do OpenOffice.org que tem mais de 15 anos de idade. Não só houve evolução tecnológica nos recursos de desenvolvimento, como houve rotatividade de programadores e de voluntários. Um código morto feito por outra pessoa não ajuda, é mal comentado, incompleto e não se preservou a memória de sua necessidade. Muitas vezes é mais fácil repensar do que tentar entender o que o colega quiz fazer e decidir se é util ou não.
Há precauções, no caso da remoção:
* o patch de remoção será avaliado pelo time central dos desenvolvedores,
* o controle de versão (git) sempre permitirá voltar algum código descartado (mesmo que não seja trivial localiza-lo). O LibreOffice tem todo o histórico do projeto no git.
O projeto LibreOffice quer ser uma oportunidade para novos desenvolvedores entrarem e trabalharem no software. Para conseguir este objetivo, foram elencados uma série de "easy-hacks", tarefas muito simples que permitem um novato se familiarizar nas 10 milhões de linhas do código. Remoção de código morto é uma delas, e estará sob supervisão de desenvolvedores sêniors.
Abraços
Olivier
Boa tarde Olivier,
ExcluirAcredito que o Pajé está dizendo não é a mesma coisa.. dependendo da estrutura do sistema, ele deve ter alguns métodos definidos que nem sempre será utilizado no programa de uma forma simples de encontrar.
Por exemplo no padrão template, os métodos são chamados em tempo de execução, e não em tempo de compilação.. ou seja.. dependendo de como vai ser executado o programa ele pode requisitar a chamada de um método ou não..
Rodrigo
Uma pena que a integração com o ms office esteja tão ruim... Muitas formatações de docs não são preservados.
ResponderExcluirConcordo!!
ExcluirOlá Olivier,
ResponderExcluirNo fundo, você acaba concordando comigo: refinar o código é uma ação humana e não pode, sob pena de significativas perdas, ser delegada a programas automáticos, por mais sofisticados que sejam. Estes programas existem para varreduras mais simples e pontuais.
Creio que a grande discussão é "como estratificar um código morto de um vivo". Um código morto não é simplesmente um método que não é chamado, porquanto métodos que não são chamados ainda assim têm utilidade, como sobrecargas de métodos e construtores, ou códigos de classes helpers, pois estão sempre na eminência de serem úteis a qualquer momento ou no mínimo ajuste do programa.
Contudo, um código vivo pode não ser um método sendo chamado e rodando, ainda que funcione, pois existe sempre a possibilidade de duplicidade de código e erros de implementação e arquitetura derivados desta problema, o que não é tão incomum em projetos grandes, por mais atenciosa e qualificada que seja a equipe.
Bom, não estou lançando críticas ao Open Office ou ao Libre Office, mas estou mostrando como a questão é bem mais profunda e complexa do que aparentou no artigo inicial. As referências citadas zelam pela qualidade do código, o que certamente tende a diminuir problemas como estes citados. Contudo, duplicidade de código, reciclagem de código, rigor arquitetônico, qualidade e otimização são para o programador muitas vezes algo próximo ao que a perfeição da arte é para o artista: mais um grande ideal a ser mirado do que uma meta concreta a ser plenamente exaurida.
É uma pena que a MS não abra seu código para que possamos resolver essas pendências, porque no momento precisamos fazer "engenharia reversa" para melhorar a compatibilidade com a MS.
ResponderExcluir