3 ms·

This seems perfectly reasonable advice. However I do wonder how many people actually struggle with this sort of code quality. It's certainly more than a few, si

This seems perfectly reasonable advice. However I do wonder how many people actually struggle with this sort of code quality. It's certainly more than a few, since I've encountered bad code with these issues. But it's not exactly the most pressing issue either. As the author demonstrated, you can refactor this with a little thought. It's the code equivalent of tidying your room, sweeping the floors and putting your stuff away. Whereas the refactoring issues I'd love to learn more about are the equivalent of a sinkhole in your living room. Stuff like "you have data dependencies that go in, out, left, right, and through the code", or "the codebase is a mishmash of React combined with Vanilla JS that is hooked up to a custom PHP MVC". Basically refactoring that involves issues that cannot be cleaned up all at once, that involve deep architectural decisions and that require some amount of buy-in from the team. Mostly I'd like to know more about this because I've realized that I'm not very good at it. My inclination is to just refactor everything and that's not a feasible strategy. I also struggle to balance it with getting feature work done. Definitely something I plan on reading more about.

BurningFrog 4y ago
My opinion is that each line of code should be easily understandable. Without that, code is very hard to work with. You're right that other code problems can be worse. But that's no excuse to avoid doing the basics. To clean up system design issues, you must first know what a better system design would be. It's not enough to realize that what you have is bad. I do this a lot, and part of my approach is to always be incremental. Improve one detail/aspect at a time. The worst, very tempting, idea in this field is to throw everything away and start over... > I also struggle to balance it with getting feature work done FWIW, I like to spend 1/3 of my time cleaning up and refactoring.
theptip 4y ago
I’ve seen some engineers that think it’s clever to put everything into a one-line list comprehension where possible, even if that means rewriting named variables as letters to make them fit. The result is really hard to read. I’ve also (more common) encountered engineers that don’t actively try to be clever by being terse, but also don’t put their mind to writing clearly. Put differently, I think one has to actively try to write easy-to-read code. I agree with your point that this sort of micro-style point isn’t as big as architectural questions, but it’s definitely something you want to teach junior engineers so that it’s second nature by the time they are at the level where they are thinking about architecture. For that you can try reading Bob Martin, Martin Fowler, Kent Beck, Domain Driven Design, Hexagonal, etc. - but you also just need to build for a decade while thinking about that stuff to really master it. Sadly architecture often seems more craft than formal engineering at this level.
9dev 4y ago
What always helps me with architecture redesign projects like that is trying to define a goal to work towards: getting alway from that custom PHP MVC and to a proper Symfony application, for example. If you know where you want to go, it’s easier to stay focused and to align what you do with what you want to achieve.
brabel 4y ago
Exactly. This post is helpful to beginners, sure.... but after some experience, the problem you describe becomes much more pressing. I still don't have a good solution other than try to "keep things simple" from the beginning, then as soon as new features are introduced and everything becomes messy, mercilessly refactor the architecture itself to make things "make sense" again. I fully realize that this is not very helpful because what does "make sense" even mean in a code base? But that's the best I can come up with and I don't think there's anything more specific that can be said :(

BurningFrog 4y ago

My opinion is that each line of code should be easily understandable. Without that, code is very hard to work with. You're right that other code problems can be worse. But that's no excuse to avoid doing the basics. To clean up system design issues, you must first know what a better system design would be. It's not enough to realize that what you have is bad. I do this a lot, and part of my approach is to always be incremental. Improve one detail/aspect at a time. The worst, very tempting, idea in this field is to throw everything away and start over... > I also struggle to balance it with getting feature work done FWIW, I like to spend 1/3 of my time cleaning up and refactoring.

theptip 4y ago

I’ve seen some engineers that think it’s clever to put everything into a one-line list comprehension where possible, even if that means rewriting named variables as letters to make them fit. The result is really hard to read. I’ve also (more common) encountered engineers that don’t actively try to be clever by being terse, but also don’t put their mind to writing clearly. Put differently, I think one has to actively try to write easy-to-read code. I agree with your point that this sort of micro-style point isn’t as big as architectural questions, but it’s definitely something you want to teach junior engineers so that it’s second nature by the time they are at the level where they are thinking about architecture. For that you can try reading Bob Martin, Martin Fowler, Kent Beck, Domain Driven Design, Hexagonal, etc. - but you also just need to build for a decade while thinking about that stuff to really master it. Sadly architecture often seems more craft than formal engineering at this level.

9dev 4y ago

What always helps me with architecture redesign projects like that is trying to define a goal to work towards: getting alway from that custom PHP MVC and to a proper Symfony application, for example. If you know where you want to go, it’s easier to stay focused and to align what you do with what you want to achieve.

brabel 4y ago

Exactly. This post is helpful to beginners, sure.... but after some experience, the problem you describe becomes much more pressing. I still don't have a good solution other than try to "keep things simple" from the beginning, then as soon as new features are introduced and everything becomes messy, mercilessly refactor the architecture itself to make things "make sense" again. I fully realize that this is not very helpful because what does "make sense" even mean in a code base? But that's the best I can come up with and I don't think there's anything more specific that can be said :(