Why is writing clean code so hard?


"The business logic is too complicated to simplify the code." 


Could there be anything more frustrating to hear? Why do so many of us truly believe that? Sure, some code gets to that point, but its not because its solving the Vaught conjecture, but because some basic code organization tricks weren't followed. So what's the deal? I follow these few steps to help me simplify my code.

Step 1- PLAN!

If I had eight hours to chop down a tree, I'd spend six hours sharpening my ax.


 Basically, write a flow diagram... pretend like you're explaining the flow to a child; they will keep asking: "Then what happens? Then what happens..." over and over until you give them the pieces to solve the puzzle. This should be your process boxes in your flow.  Now, each of those boxes need to be a method your main public method will call them in the same way your diagram presents them.

Step 2 - Organize your parameters!

I'm not going to go into the proper naming of variables and parameters (which you should do anyway), but more so in what you pass back and forth from one method to another. Instead of passing bits and pieces from one method to another try creating a document message and updating properties as you go. Think of it as a Strongly typed property bag that encapsulates all the data needed for the entire flow without having to pass them one by one or to make them variables in the class. This will let you test cleanly and carve out

Step 3 - Organize your files!

Partial nested files...use them... a lot! Try avoiding multiple classes, instantiating multiple objects to do mundane things doesn't always scale. Instead, if your logic is huge, make the main method the root file and nest all the other portions in their own partials named appropriately. In other words:

                        BigComplicatedFile.cs
                                      |_BigComplicatedFile.FirstLogicBranch.cs
                                      |_BigComplicatedFile.SecondLogicBranch.cs

Already easier to decipher, right?

Step 4 - Test Test Test!

This isn't what you think it is; its a way to make sure your code is well organized and understandable. For example, stop creating virtual methods unless logically needed... they are a way to cheat when your testing. If you have to override a virtual method in order to write a test, then your logic is probably to opaque and hard to understand and therefore test.
Now, doesn't this contradict with Step 1? In the sense that we should break our logic into multiple logical private methods? No it doesn't, but I understand how it can seem to be. Testing should be primarily against your public methods, and the method will utilize the private ones as it needs them. But if you do need to test them, there are many ways you can do so using either InternalsVisibleTo
or private methods accessors.



I have been doing this for a while, and haven't found a scenario where the following these four steps didn't make the logic simpler to write, easier to debug and quicker to finish. So, next time you've got a complicated piece of code in front of you, take a breath and try to follow these few steps and let me know what happens.






Comments

Post a Comment

Popular posts from this blog

How to unit Test Entity Framework

So, now we have the picked the best ORM for our purposes, chances are, you want to test it. We all test our code all of the time with close to 100% coverage, right? Yea, that's what I thought. Throughout the years, I've found that most developers don't test their code thoroughly because a handful of reasons: The tests written are too brittle and break with every new feature. It's too tedious to try to and mock out every little thing Its just too difficult; things are abstracted out way too much nowadays and I cant get them to pass  You know, they're not entirely wrong; I've seen code written to perform CRUD on a table that could only be described as 'awful'. Firstly, the amount of code to do that simple operation was just absurd. Secondly, the repository pattern needs to go; it just doesn't make any sense to me to try to anticipate every possible request that's needed and create a member for it (read over-complicating things). Thi
Read more

//TODO: Tackling Technical Debt

This isn't the first article you’ve read about Technical Debt, nor will it be the last. Technical Debt is here, whether you like it or not, and that’s OK, but if you don’t pay it off it will just keep ballooning bigger and bigger until you are under water. The reason it's called debt is not just a catchy play on words, but because for a software product, it acts exactly like financial debt; at the beginning, it's manageable and taking on small amounts of it is not only an attractive thing to do, it can be the right thing to do to get where you need to go. Now, if you pay it back quickly, the debt hasn't accrued much interest and is relatively easy to pay off, but the longer you let it sit, the more interest it will accrue and the more expensive and difficult it will be to pay off.   Let's take this metaphor further and consider a couple of examples: High interest rate Technical Debt: Let's say that we have a data-access component that acts as the te
Read more

The Yin and Yang of software

Image
As I was looking out of the window of my flight, I looked on to see the house and neighborhoods below and couldn't help but admire the beauty of the organization intertwined within the chaos and randomness of the surrounding environment. I couldn't help but draw parallels to my own world, as a software architect for almost the last decade, as to how similar that world is to mine. I have always struggled trying to clearly explain the difference in rules between a software architect and a software developer. Even more difficult has been trying to explain the difference between the different types of architects themselves. Barcelona Spain. Bing Maps A lot of people tend to think that an architect is something one becomes after they are the top level developer they can be, the next step up so to speak. That might be because the salary structure in our industry rarely values nor can properly price developers to begin with. That's a whole other blog post in i
Read more