|
|
|
|
|
|
by usr1106
1616 days ago
|
|
|
Not convinced. Unmaintainable code is the big problem. He is right that the future is unforseeable. That's why code needs to he maintained. A weird non-local bug is detected. The developer who wrote it found greener meadows. Sales has sold a feature we don't have yet. We notice that we do business with some different functionality that we originally envisioned. There will always be reasons why code needs to be maintained, whether it has worked for 3 days or 3 years. Now if the code is unmaintainable and every change takes 5 times as long as soon it should and introduces 3 new bugs we are in trouble. Shitty code is almost always unmaintainable. (Unless the shittyness is local inside small functions, but I doubt that's acommon case.) Of course over-engineering and needless optimizations also lead to unmaintainable code. If the company policy were "Write shitty code" I would run away. I am sure it would lead to absolutely horrible results. At my work we stress the value of good code. Still we end up with shitty code regularly. We just didn't know better when we did it. And we do not rewrite everything once we believe to know better. It's hard enough to struggle with that level of shittyness, I don't want to have it increased fully intentionally. I do that for scripts I will never use again, but not for anything I merge to the code base. |
|
|
I was going to write something similar, so piggybacking. The shittiest code I've seen has always suffered from this.
Sometimes it was shitty (in this sense) because of an assumption that it was "throwaway" code, but it was never thrown away. Gross copy/paste throughout, highly redundant code (same variable, or variable with the same intent, created in many local blocks), mostly existing in mega functions (thousands of lines long) with complex conditional logic to navigate to specific desired sections from the entry point at the top. If it was really throwaway code, then this can be tolerated. But it doesn't require much thinking into the future to replace a 10-line block that's repeated 50 times with one change at each location into a single function. If, in the future, some of those 50 uses of the function need a different function, change it then. Better that than having to keep 50 locations in sync with each other because "making a function now is premature optimization" or "YAGNI!!!". Well, programmer time and delivering quickly has value too. When what would have been a 5-minute task (read function, change function, rebuild, rerun) becomes a 5-hour, 5-day, or 5-week task then everyone is losing out because of the shittyness that was trivially observable and correctable early on.
The other big example of shitty code that is unmaintainable (or becomes unmaintainable) is tight integration between IO and business logic. Without a clean separation, you typically end up with similar repetition to what I described above, or something where a "small" change ends up having massive knock-on effects. This brings maintenance to a crawl as you have to tease out the consequences of that small change, which is non-trivial. That's what makes the code shitty. Corrections and clean separation are often forestalled for the same reason that the previous example often ends up with a mega function instead of a nice, often small, set of utility functions: YAGNI. If your project is going to last more than a few months and has even a modest level of complexity, you will need that clean separation. Otherwise, you end up with increasingly complex (but unnecessarily) code that works around the initial self-inflected hamstringing, or you waste weeks or months cleaning it up and delivering nothing to customers, who become impatient so the cleanup gets cut short and you now have a hybrid mess: half-good code (that will decay rapidly) and half-shitty code (that still can't be maintained).