3 ms·
I think the author mistakes messy code for technical debt. Even with clean code, you will have technical debt because as the business evolves, your code becomes
by eweise 7y ago
I think the author mistakes messy code for technical debt. Even with clean code, you will have technical debt because as the business evolves, your code becomes stale. For instance, your UI might start out simple so you start with just jquery. The code is clean because you didn't write crazy long methods, etc. Business keeps adding features to the page and after a while jquery becomes unmanageable. Now you have technical debt.
- Rury 7y agoYeah. I think people conflate clean code (readability) with code refactoring. For the sake of readability I don't think having clean code matters much... but refactoring I think can be important depending on the complexity you're dealing with. But even then, I'd only worry about refactoring when it comes time to worry about it. Usually I find that's when the scope of the software grows by some factor, or when you foresee it growing by some factor and you find it cumbersome to add simple features, yet a simple refactoring would make the addition of features much easier. So IMO, the importance of "clean code" depends on the complexity you're dealing with. Always having clean code just for it's own sake seems unnecessary...
- boomlinde 7y agoMaybe you experience that conflation of concepts because other people have a different idea of what clean code means. IMO readability is just a side effect of clean code, and refactoring is part of the process of achieving it.
- boomlinde 7y ago> Even with clean code, you will have technical debt because as the business evolves, your code becomes stale. Suppose the ideal clean code base. There is of course no stale code there. In the event of new business requirements, it has been reconsidered carefully and rewritten to cover the new requirements in a way that's architecturally consistent. If that was impossible with some previous iteration of the architecture, the overall architecture has also been reconsidered and changed. For your jQuery example, with unlimited resources available to address code smell, you'd of course either replace it with some existing higher level library that suits your use case, or you'd write your own high-level generalizations. I have seen a lot of code that was terrible not because they had unwieldy business requirements, but frankly because the code had poorly considered abstractions and unclear boundaries. Features were added without consideration for the architecture. Quick and dirty fixes were considered preferable to overhauls. Short term workarounds ended up being long term don't-touch-this-we're-not-sure-what-it's-doings. What worked at some thousand LOC became the guiding principle for further additions. The real problem is that rewriting or cleaning up can become unbearable for some combinations of organization and code base. It takes time and can become an organizational hurdle if people are simultaneously implementing new features or fixing bugs. Every time a developer says "this will take several weeks to implement" and the project owner successfully insists that it can't, the code base gets dirtier. In the real world some PPM of fecal matter is acceptable because getting the last few particles out is going to increase the cost by an order of magnitude.