Mailinglist Archive: yast-devel (121 mails)

< Previous Next >
Re: [yast-devel] Changing the Attitude to Coding YaST
  • From: Lukas Ocilka <lukas.ocilka@xxxxxxx>
  • Date: Thu, 09 Jun 2011 11:12:50 +0200
  • Message-id: <4DF08E92.5060603@suse.cz>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dne 8.6.2011 16:28, Josef Reidinger napsal(a):
Lukas Ocilka write:
- Fix|Easy: Develop code in reusable libraries and write simple and
understandable tests.

write simple and understandable tests for ycp is not easy task ;)

Yes, it's not. But we can start changing the coding style that would
make it easier. For instance, imagine you have to implement a new
feature in an existent code written in YCP.

1.) Write as much code as possible in a testable way (library)
2.) Write test for the functionality
3.) Make sure the test is 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.
I think we already have some code standards.

Yes, we do:
http://doc.opensuse.org/projects/YaST/SLES11/codingrules/index.html

But does everybody use them? Have you seen, e.g., yast2-network code?
(Please don't blame Martin for that)...

If developers do not use the current standards, maybe they don't know we
have some, or they don't care, or they don't like them. Maybe it's time
to fix/change the standards first?

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.

Yes, moving to git would help a lot, IMO.

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.

Sounds like a plan ;)

- 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.

Good idea.

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.

Also possible. I use producteev for personal and also company TODOs,
it's connected to my HTC and makes my life easier ;) It was just an
example...

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.

OK, let's invest some time in research in this area.

Lukas

- --

Lukas Ocilka, Appliances Department, SUSE LINUX s.r.o.
MD: Jeff Hawn, Jennifer Guild, Alena Hendrichova
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iD8DBQFN8I6SVSqMdRCqTiwRAnp8AJ93tpjbohkIlzHlqPAdFijq0xaQfgCgiFf6
ULJVFJ3axk3d3IbQtriuWfc=
=ie5U
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups