Applying clean code and SOLID principle take me so much time: normal? [closed]

Question

I'm new to programming, 11 months to be exact. I really want to be a professional programmer and produce quality code, so I'm learning clean code, SOLID principle, and OOP design. What I've notice is that it takes me time to design code that follows clean code and solid than not following those.

This is my first paid project and I really wanted to produce quality code. What I realize is that it took me days just to write some components of my app that follows clean code and SOLID whereas only less than a day if not following clean code.

I think I'm not going to reach the deadline if I continue to apply clean code, but I have to because I know the business will grow and requirement will change. I'm developing a beach resort billing and reservation system, and I know in future it will need to handle online reservation.

I can say that it is easy to learn new technologies like ORM, WCF, etc, but clean code, SOLID and design pattern is different.

I'm a beginner programmer, what is your advice to me, how long does it take to learn this pattern, and is it true that applying clean code and SOLID takes more time to develop app than not applying those?

Answer 1

For a different perspective on things, don't focus on writing clean code up front.

Write code that solves the problem first, then go back and clean it up. The only caveat there is don't go too long without going back to clean it up. And by clean it up I mean go back and implement the SOLID principles only for the abstractions that define the intent of your system.

Most code I read, from professionals or not, you can pretty much tell when they tried to write the perfect code on the first pass, because they always fail to do so and they never go back to clean it up. Actual clean code is the result of iterating drafts of a block of code only the original writer could understand until it's easily understandable by anyone familiar with the patterns used.

It is premature optimization to try to write perfect code up front.

First, you'll end up with a ton of abstractions you don't actually need just to satisfy some dogma about maintainable code. Often times you'll spend so much time on the structure of the solution that the actual problem you are trying to solve gets lost in translation. In reality, the fewer the number of abstractions, the easier it is to figure out the core responsibility of a piece of code. It's better to build abstractions only at the highest level first, and only build more when it is absolutely necessary.

Second, you often design the wrong abstractions based on the parameters of the current requirements than you would if you knew exactly how the requirements were going to change in the future.

I have a great example of this from the Careers candidate search project. Originally our requirements were to load search results and candy data (statistical charts and such) for the result set. We implemented this all using sql and separated out the process of loading candy and getting the search results into different services. A couple of years later we decided to try implementing this all using elastic search. As it turns out, our idea of separating the candy generation from the search results is not necessary using elastic search because it can do both at the same time.

What happened to us is that we were over zealous in having classes be responsible for one thing. In fact, we had different services for generating the sql for the search and saving the search parameters to the database. When we implemented this using elastic search, the parameter saving service came in handy, but it was still unnecessary work done up front. In fact, much of the extra time we put in up front for maintainability was pretty much a waste because we ended up having to rework a core abstraction mistake to work with the new requirements.

If we could do it all again, we would have instead written all the code in one giant search service. During our drafting we would have broken out each of these other services we implemented into simple private functions on that service. When we created a second implementation of the search 2 years later, all we would have had to do in order to break out the shared services is copy the private functions to a new service and make the shared functionality public on the new service. This is a much more pragmatic approach than trying to write the "perfect" code out of the gate.

---

Don't misunderstand me, having clean code will make your code more elegant and maintainable; you just can't write it on the first pass. You cannot truly understand what makes code clean simply by reading a book or looking at source code that people consider to be clean. In addition to that stuff, it takes a lot of time running into mistakes like the one I described above in order to realize the full intent of the principles that make up clean code. Don't be afraid to make those mistakes, they will make you a better programmer. Being afraid of mistakes is an intolerant view that makes you a worse programmer.

Answer 2

Learning things takes time. You're not an experienced professional (since this is impossible to become in 11 months; nothing to be a shamed of) so obviously it takes time to grasp what SOLID is about and apply it correctly. It took me years!

I'm now at the point that developing SOLID applications doesn't take much more time for me, while it pays back big time in the long run, and it often even pays back within a few iterations.

My advice: go to your boss and explain what you're trying to do and try to get more time and explain why this is important for you and (very important) for him! It's up to him to decide whether you get time to learn on the job.

And if he refuses to give you this time, start learning these things in your own time, and in the meantime... start looking for a new job where there are professionals that value these patterns and managers that facility room to learn and grow.