How do you deal with, avoid, or accept complexity — differently than you might have earlier in your career?
For further actions, you may consider blocking this person and/or reporting abuse
How do you deal with, avoid, or accept complexity — differently than you might have earlier in your career?
For further actions, you may consider blocking this person and/or reporting abuse
Latest comments (31)
As long as the unit tests are readable, I give up caring about the code readability
Complexity is reserved for business logic. Complication is acceptable for technical concerns.
When I was younger, I tended to avoid complexity, or always tried to go on it with some support (either colleague or internet).
But now with some more experience, I'll always deal it the same way with ~3steps :
I recommand having a look at "refactoring guru", the website with the badger mascot, as it explains a lot of it, with detailed examples both theoric and with code.
Some more advices :
Maybe the best advice I can give is that it will never be flawless the first time, and don't try to make 10+ classes for a start.
Most of the time I do a big old "index.php" or "script.js", code on the fly, and when things are finally starting running flawlessly, and your file is 500+ lines : it's a hint that it is time to split your code into multiple folders/files.
Got client stuff ? Create a "Client" classe.
Need to create a new client ? Create "Client->create( )" method
Client needs name and email ? Update your class : name & email properties. "Client->create(name, email)"
And so on.
Once you feel good and confortable about this, to get to the next level go check Unit Testing, and after that TDD > Test Driven Development.
It will help you thinking about your code as input/outputs and stuff, and can really improve code reliability, maintenance, avoid regression, and also make your code really faster.
Sorry for the big block and the approximate english.
Feel free to ask questions if you have some ;)
Have a nice day
I've learned to manage it. I do so by using abstractions and "Bounded Contexts" that closely represent the business domain. If a certain abstraction is too complex to maintain, "grok" or reason about, I "encapsulate it" and defer all its complexity to a consumable contract. This often applies to classes, modules, libraries as well as feature teams! I wish I'd had learned this "domain-focused" approach much earlier in my career. It would have made me more effective at maintaining codebases and designing larger systems.
I have personally become more complex as I age, my code less so.
Turning to have Code as documentation has allowed me to not only simplify it, but make methods and steps easier to understand with good naming.
I see complexity arise when people try to fit square pegs in round holes, use tools for purposes they were not intended for and for which they are mismatched. I think complexity can be reduced by 'going with the grain' of tools we use rather than against. Have written more thoughts here: dev.to/yawaramin/reducing-system-c...
Complexity is always accidental.
We need to avoid it all the time.
Forget about code complexity and software complexity. they are a myth
It's...
Complicated.
I've always strived for simplicity, as it is beautiful to look at and to work with. And it works.
I find that inexperienced developers often overcomplicate simple things. I've made peace with that as everyone needs to learn sometime. It is frustrating though to look at a project, codebase or architecture that is 10x times more bloated and convoluted than it should be.
Will never forget this from one of the authors here at dev: