Thread by @mcarlson_sb

Here is a big "secret" to better code. Writing tests first *doesn't guarantee better code* (it does make sure code is testable, can give better hints at intent, and often makes code safer to change)...

Refactoring also *doesn't guarantee better code* (it's much more likely you'll have better code if you clean it up as you go, it's more likely to be changeable if separate out responsibilities, it's more likely be readable if you improve names as you have insights about intent)..

But the actual "secret" to better code is being able to recognize how code can be made better. Understanding how to see if you are using the wrong abstraction (primative obsession, logic in your head outside of the code, other "code smells")...

Seeing that a thing is trying to do too much. Or that code could be simplified by removing/not adding...

Once you recognize it can be better you have a direction. Then you can use techniques to get you there (read by refactoring, refactoring to patterns)...

At that point leaning on tests and automated tools allows us to safely modify the code...

Refactoring allows us to improve the design without changing the behavior...

But it all starts with knowing what better looks like...

Getting a concrete handle on some of the concepts you've all heard before but never quite think about in the moment..

Fundamental OOP concepts:
Abstraction - is the code organization such that you can think about it in terms of the real world system it models. Is the important logic of that system expressed in the code or held in your head?...

Inheritance - if code is used repeatedly do you "get it for free" or is it duplicated? Is shared logic shared (when appropriate)...

Polymorphism - can a single message provide multiple behaviors?...

Encapsulation - is data bound with code such that objects know there state and how to act on themselves rather than having "spooky actions at a distance" change the state in unknown ways out from underneath them?...

(Bonus) Information Hiding - is only the data you want accessible visible through a public API making it safer to change implementation in the future?...

GRASP Principles -
Is your code Cohesive? Are things that belong together close to each other? Does every (or most) methods in a class use every (or most) attributes...

Does your code have low Coupling? Few if any direct dependencies. Could you extract it easily into its own microservice/module/object...

Does your Controller code know who to delegate to *and only delegates* leaving the business logic to more easily testable Experts?...

Do you encapsulate complex building logic into Creators such as factories and other builder patterns?...

Does your code avoid talking to strangers? Limiting itself to only interact with it's direct dependencies rather than digging deeper with feature envy?...

Do you limit the use of Pure Fabrications - those things such as creator methods that don't reflect the real world. But are instead purely code constructions outside of our abstractions...

Does your code assign responsibility to experts rather than relying on barnacles of logic that grew because it was "convenient" or the smallest change that grew the largest mess...

SOLID Principles -
Do one thing and do it well, be extensible without changing existing code, don't break your parent class's contracts, make fine grained interfaces specific to clients needs, avoid dependencies by relying on abstractions...

Design Patterns - take a look at the ways others have repeatedly solved the same problems and learn from their experience..

These fundamentals are the "secret" to better code...

Tests help us by making it safer to change code as we learn more/see ways to make code better. Refactoring helps us get there. But the secret is having the knowledge of fundamentals and experience using them to shape our code with intention