I fear that I am heading towards a dead-end in my career.
After 28+ years of programming, I’m beginning to question everything I have learned. I am losing my trust in the idea that design patterns and interfaces are all for the better.
For the last 3 years, I have worked with two companies that both had huge code bases that used a ton of design patterns and interfaces. Interfaces were used to the point that most of the code was abstracted away. The rule was that you had to dig deep, following long trails of interface implementations, to get the code that actually did some work.
I used to be (20 years ago) a big proponent of design patterns, but then I got a job where nobody cared about design patterns or how to do proper object-oriented programming. It was a shock, so much so that I lost my appetite for design patterns.
Is it just me or can design patterns and interfaces be used too much?
My manager said the other day that we had to rewrite an entire project with about 5000 lines of code and 28 files. The reason was that we did not follow all the design patterns that were used in other parts of the code base. Thats fair. Code style consistency counts. We are 25% done and now we have 9000 lines of code and 99 files. Not counting all the auto-generated files. Just before we started rewriting the code, my manage said “and hopefully we will end up with less lines of code”.
How is this better and easier to maintain?
I can not think of any project that used interfaces and design patterns that reduced the lines of code. Is this a common belief?
Just an absolute novice here with less than a year of low-intensity study in web dev.
I think you asked a good question. This is something I think about a lot when I plan/dream of large projects I want to build in the future. What’s more important, making your code compact, or making it readable? Of course, it depends on the situation, but I definitely lean on the side of making code readable most of the time. Why? Because of the nature of software. Software is something that usually needs to be maintained, updated, upgraded, restructured — basically, it’s an ever-evolving machine we build and never stop building. And when code is neatly organized, clearly structured and each function is sorted into its proper place in a way that’s easy to grasp the logic behind its purpose, that’s so much easier to scale, maintain and update.
This is especially true for gigantic projects, like you mentioned, with 5,000, 50,000 or even millions of lines of code. At that point, it’s impossible for someone to build and maintain the system alone. A team has to work on and maintain the massive piece of software, and you’re having experts with different specialties working on the different components of it. It all needs to make sense as a whole, so that the different team members can collaborate as one, with the purpose of the software in mind, even with the diverse skillset of the team. Sure, the back-end sever programmers don’t have to know all the intricate parts of the front-end UI the front end devs built, but they need to be able to easily understand the structure of the site, how users submit and request data, where they do that, and what the core components of the site are so that when, for example, updates come along, there’s seamless meshing with the back-end, and perhaps the back-end needs no modification at all.
I mean, it’s all about efficiency, and in the long run, for maintainable software, it’s more efficient to have larger but organized code than high performance compact stuff that no one can read except for the engineer who wrote it. Otherwise you’ll get those software “makeovers”, where you’re basically rebuilding the whole thing over again, and that’s definitely not efficient.
I believe strongly in code readability. I’ve outgrown that stage of early programmers who think it’s cool to have complicated code. (I guess they want to feel like hackers, lol?!) I think code should so readable that any person with basic coding skills would be able to read through it and understand it like a book.
That being said, that doesn’t mean you should chop up and compartmentalize code to the point of stupidity. I’ll give it a name: code mincing. No, the whole art of it is to find that balance between performance and maintainability. When uncertain, err on the side of maintainability.
No, design patterns don’t generally reduce code size. I mean, that’s kind of like the price to pay for opting for a software design pattern: it’s easier to scale, but it’s bigger. That being said, there are exceptions. For example, as a beginner programmer myself who writes bad, bloated and redundant code on a daily basis, using someone else’s generic design pattern is probably going to be somewhat better and more compact than mine for the simple reason that it was written by a better programmer, and thus the code is better than mine even though it was written with generalization in mind.
Also, some design patterns are just so good, so classic, that you can’t get much better than that. But those are rare, and don’t bloat code files that much anyway.
I mean, this definitely sounds like a little too much “code mincing”, as I said above, but I guess, in some sense, it could be worth it. I don’t know. It depends on how much updating and maintaining is intended for the software’s lifetime. But your manager saying
is the perfect example of why managers actually need to be good coders themselves if they’re leading a software team.
Anyway, those are my thoughts. Reading back, my ideas must smack terribly of inexperience and programming naivety! Just a perspective from someone entirely green and inexperienced.
I think that some people have the abillity to say “this is less code” even when the code is growing in front of thier eyes. Then arguments become redundant.
