Lukas Ocilka write:
Yasties, Developers and Friends,
According to the feedback I've got recently and what I've been feeling for a longer time, there is a chance to make YaST development cleaner, simpler and more enjoyable just with little tricks learned from the other projects we've been working on recently.
Here you can see a list of unsorted ideas that came into my mind thinking about the other project and reusing experience with them in the YaST development:
Code Reusability - Usually the code is written for one purpose, but maybe we should start thinking before the development: Isn't the code reusable from anywhere else? Can the code be more generic? Think about CWM.
One of my goal for workshop is to introduce well defined api for reusable things in YaST.
- Additionally, a lot of the code is in "include"d files or even in "client"s which makes the code almost impossible to be tested. That's also why we get syntax and/or runtime errors.
Agree, include is pain. Module is better/
- Fix|Easy: Develop code in reusable libraries and write simple and understandable tests.
write simple and understandable tests for ycp is not easy task ;)
Testing - Connected to the previous point. Most of the current code is not tested because it actually cannot be tested. - On the other hand, sometimes we think that writing testsuites is for dummies. But untested code causes bugs that need to be fixed later and thus is doesn't save the time at all. - Fix|Medium: Write tests, make sure they are called during build.
Coding Standards - The code should be not only understandable to ourselves but also to the others. Using the same coding standards make it easier to understand the code structure, parameters, expected return value and so long. - Examples: * Package::IsValid(package) -> returns boolean (maybe only Valid()) * Package::Install(package) -> do you need to read any documentation? * Using hashes with parameters instead of twelve parameters, eight of them optional * Indentation * No more "include"s if not necessary * Useful comments * Useful documentation of all the public functions * ... other ideas? ... - Fix|Medium: Define the standards and use them (let's learn from other projects)
I think we already have some code standards.
Cooperation - When the code has tests and it's mostly in compiled libraries, it's quite easy for more developers to work on the same project in the same time. The only thing they need to define is the API and using the same standards they can understand the API almost instantly. - Better cooperation is usually useful when someone needs help from the others: too many features and bugs and to few time. - Fix|Depends: ...
One of fix is to move to git for easier implementing features for same module and then easy merge it.
Code Reviews - In the SLMS team, we've found out that all the commits should be reviewed by someone else. This helps to identify potential issues in time. All the commits are public anyway.
It helps if commits are reasonable small. If commit is more then 20kB it is hard to review it. and I think that git helps there also, as you can hack in more commits and then sent it in one wave.
- Fix|Easy to Medium: Either someone is always assigned to review everyone's code (takes too much time) or developers usually check code of someone else only.
I think that there should be pairs for module, so second one know module and be backup and also do review.
Shared Task List - There are often even smaller tasks that need to be done by anyone in the team but they don't have their priority high enough (so called easy-hacks) - and that's why we forget them quite easily. - Fix|Easy to Medium: Use some of the task managers, e.g., http://www.producteev.com/ anyone can pick a task and try to implement / fix it.
No, no new program. Just create account in bugzilla, so you can query it for easy (low priority) tasks. This also helps team members who has more then 100 bugs to organize it.
I believe that you have other ideas how to improve the development - how to make the development and maintenance easier for you and/or the others. Or you maybe have an opinion on the ideas I just presented. Share them with us, please! :)
I have prepared something which I want introduce and discuss on workshop. But I think that we should at first try small prototype in real work if it is useful or just nice theory. Of course the biggest idea is to focus on what we do best ( high level configuration ) and try to "outsource" everything else like own language, parsers, RPC, test framework. Split high level configuration and UI presentation. Pepa
Thanks in advance and Bye Lukas
-- Josef Reidinger Appliance Toolkit team maintaining parts of webyast and SLMS author of rubygems - studio_api and net_observer (coauthor) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org