Mais si pour ça il faut refactoriser car le code est trop bordélique et que si on améliore sans refactoriser on y passe 10x plus de temps, et qu'en même temps l'idée même de refactoriser n'est pas acceptée, je comprend parfaitement le fork face à cette réponse qui ne veut pas voir le problème.
new bugs introduced
Pour éviter les bugs, c'est simple : on ne code pas. Si j'ai bien compris c'est d'ailleurs le reproche fait (que ça n'évolue pas très vite).
what's the gain for the end user exactly?
Plus de fonctionnalités implémentées car les développeurs seront alors libérés d'un code qui est devenu trop complexe au fil des ans et n'est plus adapté?
[^] # Re: La réponse de Bram Moolenaar
Posté par Zenitram (site web personnel) . En réponse au journal Neovim : vim's rebirth for the 21st century. Évalué à 6. Dernière modification le 26 février 2014 à 08:10.
Mais si pour ça il faut refactoriser car le code est trop bordélique et que si on améliore sans refactoriser on y passe 10x plus de temps, et qu'en même temps l'idée même de refactoriser n'est pas acceptée, je comprend parfaitement le fork face à cette réponse qui ne veut pas voir le problème.
Pour éviter les bugs, c'est simple : on ne code pas. Si j'ai bien compris c'est d'ailleurs le reproche fait (que ça n'évolue pas très vite).
Plus de fonctionnalités implémentées car les développeurs seront alors libérés d'un code qui est devenu trop complexe au fil des ans et n'est plus adapté?