Relatively stable code
Just a random thought that I had while investigating some stability issues with Job Manager. I generally try to build a lockless solution that will work performantly and stably. Anyone writing lockless code knows that it is not an easy feat. Still, I try to do it the right way. Analyzing the algorithm on paper, writing unit tests, adding stress tests, and running everything under Address Sanitizer just to be sure. I got to the point where I thought: I have a relatively stable solution, then came realisation.
"I have relatively stable code" is a funny term. So we have "good" code because it runs how we want for the majority of the time, and only in some cases is broken and does not do what we want, or just crashes. Sounds to me a little like: it works on my machine because you know I never saw it failing while I developed it.
I do not believe that code can be stable and broken at the same time. I know that for some, "I have relatively stable code" will be good enough, but for me, this is asking for trouble. That is why I believe that there is stable or unstable code, and there is no in between here.
Of course, some people can be ok with using broken code, which works the majority of the time. Or you know "pretty stable" :D
In my case, I am still investigating why my code fails because I want to get to the source of the issues I can see.
Comments
Post a Comment