Mailinglist Archive: yast-devel (73 mails)

< Previous Next >
Re: [yast-devel] Why not place refactoring in backlog
On 31.7.2014 10:33, Josef Reidinger wrote:
On Thu, 31 Jul 2014 10:21:35 +0200
Arvin Schnell <aschnell@xxxxxxx> wrote:
In general I agree with the article but it doesn't apply to YaST
since we already have years of backlog for refactoring. So for us
making it correct does not take a "little bit longer" but likely
several times as long. Also doing a bit refactoring always has
the risk of regressions and without unit tests *and* integration
tests these are hard to discover so often I just do not dare.

In this case it is not so easy, but there is ways.
E.g. one of possible ways is to write test as part of change, then
refactor as you are more brave to do it.
There is also parts which is very hard to test as it have many
side-effects or keep states. I think in such situation you can do
minimal modification to make it more testable, write test that proves
it and then refactor it more deeply. e.g. in this pull request -
https://github.com/yast/yast-bootloader/pull/127 I at first modify
changeOrderInDeviceMapping to not modify directly @device_mapping, but
have it as parameter, write tests for it and then add functionality I
need with additional tests. In general any change that improve
isolation of method greatly helps with testing of it.
Another think I am trying to do, is to break it more in earlier phases
( like when I implement features as my impression is that each feature
contain at least one bug :), so I made bigger changes and were more
brave, writed tests for it and when some regressions apeared, then I
improve tests to prevent it and also can refactor more aggressive this
new code when it is needed.

We can also look at it from the other point of view: What do we lose if we actually do not refactor anything? Obviously, we will lose the possibility to implement anything easily in the future or fix things properly.

Anytime we add something, we make the code a bit less understandable and a bit easier to break. Especially with years of coding and fixing, most of the code already looks like spaghetti. The code is more and more complex and cleaning it is vitally important to our own health.

It's similar to cooking: Anytime you want to cook something, you need to cleanup the kitchen desk first, wash the dishes etc. Oh, sure, even better is to do it while cooking or after it's finished. Now imagine that you come to a messy kitchen where everything is dirty and at strange places and you have to make something very good and very fast. Almost impossible.

So, from this POV, refactoring (most probably using smaller steps) is the only way to go - obviously while writing tests for everything. Nobody can see the future, nobody can tell what will happen tomorrow, but we can be almost sure that there will be bugs to fix and features to implement in Yast.

Bye
Lukas

--

Lukas Ocilka, Systems Management (Yast) Team Leader
Cloud & Systems Management Department, SUSE Linux
--
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >
List Navigation