On Tue, 24 Jun 2014 11:59:21 +0200 Arvin Schnell <aschnell@suse.de> wrote:
On Thu, Jun 12, 2014 at 04:30:06PM +0200, Lukas Ocilka wrote:
- Which parts deserve the refactoring (e.g., those that we often touch, those, that are not understandable anymore, buggy, ...)? Which are your most-favorite ones?
Every module I have seen has code that needs refactoring.
Nothing is perfect. I think we can use rule 80:20. Goal is not perfect code, but better code.
- How deep should the refactoring be, we have to keep the current "API", but what should be considered the API as we might be the only users?
Very deep, e.g. the target map of storage is a error prone interface.
I absolutelly agree. And it is often used in various code. If it is used only from ruby, we can create quite nice object, which is encapsulated, linked together and have good methods. Then you can have code like disk = Storage.find("UUID=123123123123") biggest_swap = dist.partitions.max_by { |p| p.swap? ? p.size : -1 } or can_boot = Storage.find_by_mount_point("/boot").primary? I know how it looks now using target map, so I think this will be nice improvement and also easier to keep backward compatibility
- Where and how to run automatic integration tests? Will openQA help? We could build our own installation image the same way we did it for the New Installer, testing this image automatically is just another logical step.
This is the most important point I see. So far adding testcases (which is required!) is often not done because we don't have existing testsuites or changing the code to be testable requires a big rewrite.
Agree. And I hope that even if we change code to be easier to test allow us to improve code quality as code that is easy to test is usually - more separated - less coupled - more isolated - motivate to reuse existing code as it is already tested ;)
Regards, Arvin
Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org