Hi Everyone,
Since I'm always fighting for better code quality on the projects I'm working for I'm curious how satisfied are you with the code quality on the projects you are working for?
Hi Everyone,
Since I'm always fighting for better code quality on the projects I'm working for I'm curious how satisfied are you with the code quality on the projects you are working for?
For further actions, you may consider blocking this person and/or reporting abuse
It's absolutely abysmal. It's an old Zend 1 project that has seen at least two attempts at a rewrite fail,and at one point went off to another agency for a year or two before coming back. Until I started on it, it had no tests, and the JavaScript was all spaghetti jQuery. Almost everything was crammed into fat controllers, and there was a huge amount of duplication (12% if you didn't include the view layer, according to PHPCPD). The models were used as both domain objects and repository-style classes, so to find an item by ID, you had to create a new object, then call find() on it to get that item.
But, it's teaching me a LOT about working with legacy code, refactoring and implementing design patterns.
I'm pretty much a novice.
My first real project is on GitHub here; I'm sure it's horrible...!
But I'm learning and am confident that I'm gonna be able to improve...
Any advice would be great though...
I took a look, it is not so bad, especially if you are a novice.
What I would suggest is to split up the complex functions for multiple ones.
On the other hand I suggest you the page exercism.io, there you can write code and the mentors on the page are giving you reviews with suggestions.
Thank you very much for your advice!
Thanks for the answers.
As I expected most of you is unsatisfied.
I wrote a short post about the topic:
dev.to/rlxdprogrammer/how-to-handl...
In the future I plan to write more about the topic if I find time.
It's by far the worst code I've ever seen in production. It's a huge legacy system started by college devs, then moved offshore, then back into the college devs team. They do not allow time to write tests, there are basically no tests at all, and almost every function is 100+ lines long of spaghetti with lots of shortened or single letter var names. There are bugs everywhere, unreachable statements, loops that immediately return, unsafe comparisons, the whole shebang. It's php 5.6 but written as if its php 3 or 4. I'm seriously thinking about jumping ship as I can't work on it since we are never given the chance to refactor or add tests. It's only getting worse and I don't want to be here when the ship sinks.
For me, happiness with (my) code-quality on a given project is inversely-proportional to the length of a given project. The longer the project, the greater the probability that I will have learned new techniques or improved on existing techniques. Further, if a project is longer, I'm more likely to have reason to revisit earlier code — even if I'm not accorded the time to fix said code. Thus, the longer a project goes on, the more-glaring the poorer quality of the earlier code becomes.
A real exacerbator of the preceeding is that the longer a program goes on, the more the project demands, change:
I don't think anyone is ever satisfied with the code on their project. There's always going to be technical debt, misalignment of the architecture with the present requirements, "old" code that should be replaced with more modern libraries or coding styles or whatever is popular with you today, more unit tests, etc.
I think the more important thing is to aim for the most cost effective code, not some arbitrary quality level. That gets you thinking about things in terms of dollars, which aligns you with your business.
Sometimes the most cost effective thing is to slow down a bit, do code reviews, and write tests for that new code. And sometimes the most cost effective thing is to "hack" something together and get your site back online now.
Getting things in dollar terms allows you to have intelligent conversations about the merits of various approaches to quality and schedule with the stakeholders of your software.
Could be better, but could be worse too.
Have a code base with a few minor (known) bugs.
Most of them are based on the fact that the back-end lies to me, haha.
I will inprove the API client next. No more trusting error codes.
In my next projects I'll also try stuff like TypeScript with strict null checks and Storybook. These tools seem to solve most of my refactoring problems.
I'm mainly working on maintaining legacy applications written in various flavors of the Microsoft stack from VB6 to WCF. It was written and patched by 20+ programmers over the past 22 years. It is a mess.
The good thing is that we are moving forward on replacing it with better quality code. It's just going to take a while because the "keep the lights on" maintenance takes up a lot of time.
...that, after 20 years of patching, some other developer will be calling a mess! =)
To be honest, our code could ~should~ be a lot better. Architecture is just a monster and has changed twice since we started the project.
To clarify, "our" project is just a piece of a much bigger project, and things have changed a lot around here.
Also, can't deny that I have learned a lot about developing, code quality and javascript in general, so now I have more tools and knowledge to improve old code.
What keeps us from improving more, is probably IE support and the constant changes to the bigger project's structure.