``Surely an accounting package is trivial next to the complexity of an operating system,'' he said. The warlord uttered an exclamation of disbelief. ``An operating system,'' replied the programmer. The warlord asked the programmer: ``Which is easier to design: an accounting package or an operating system?'' There was once a programmer who was attached to the court of the warlord of Wu. Minimalism as an art form not the same as minimizing the cost function of different uncertain factors.Īnyway, this reminds me of a story from the Tao of Programming, : That's one reason I believe that programming-as-art metaphors don't really apply. I suspect most would say the second is minimal, but the first is what Python uses, because it's measurably and distinctly faster than the second, and that extra performance is worth the extra maintenance overhead. More seriously, of these two implementation for Python's str.lower(), which is "minimal"?:
#Sleeping dogs hacking codes code#
It is also said: "Adding new members to a late project, makes it later" That's because of the overhead of managing those peoples and the added code does not always add to project speed. The problem: The number of employees and the number of code lines grew faster than the company could manage them.
The next version came out much much later than expected and was first a bug ridden chaos. The first 2 or 3 versions where great and the company grew out of 4 developers to a horde. I remember an old, but once famous database product. Many companies start fast with a superior product, but than comes the time of growth and growing demand, new employees are rushing in. The maintenance of a program is directly dependent on the number of code lines. This reduces (often, not always) the runtime, the amount of memory needed - and (most importantly!) the amount of maintenance that is needed. The art in computer programming is, to find ways to bring the problem to the point, to find out what is really necessary to solve the problem (and not more). Some said: "A piece of art is only finished, when there is nothing left, that can be taken away." Yes, I was trying to be "cute" also, but I was too young to realize that was a bad idea.
I wrote a lengthy essay explaining the above facts, and used commented-out excerpts of that essay as padding in the file. (Get it? Metamorphosis? Transformer? Never mind.) It occurred when a certain buffer filled up, and the exact length of the XSLT input file affected that, so adding a few lines of commented-out content would make the error appear or disappear. (It wasn't.) It was an internal exception in the transformer. Turns out, Gregor is the main character of Kafka's "The Metamorphosis" and the exception was the brilliant idea of someone who wrote the XSLT transformer and probably thought it was cute. the exception occurred at unpredictable times and who the hell was Gregor Samsa anyway, and what did that have to do with our Java application? I refer to it as "dreaded" because folks on our team dreaded it. If you didn't leave the comments in then you got the dreaded "GregorSamsaException". Yes, but in my book, that's not commented out code, that's an (undocumented) compiler directive.Īnd I've done similar things with "undocumented compiler directives" for XSLT processors before. Only then I could get the build to pass again. So if you have 10K lines of untested code, and 90K lines of very ugly, badly factored, but tested code, you just couldn't remove 10K of the bad, well tested code, because that would sink coverage metrics.Īfter much arguing for relaxing the rules, as I didn't think that adding tests after the fact to bad UI code seemed like a good use of our time, I fixed it in the only sensible way I could: Added an extra ten thousand lines of well tested code that didn't actually run in production, but made the metrics happy. But my commits were rejected by the build. I cut the size of the backend in half, and all the tests kept passing. So to keep the application in order, I started doing a bunch of refactoring. So my predecessors often left some chunks of frontend relatively untested, while making sure large amounts of business logic was well tested. Swing has it's qualities, but being easy to write meaningful tests for isn't one of them.
So I inherited a large, rather terrible application, which included a whole lot of UI code using Swing. However, as a way to improve code quality, management decided to make the continuous integration server demand 90% test code coverage minimum, including branches, and no loss of code coverage over half a percent from maximum, as measured by Sonar. My favorite anecdote on code removal comes from using Sonar, a static code analysis tool.Īt a previous job, a pretty smart architect decided that Sonar was a pretty good tool to gauge code quality.
0 kommentar(er)
