Jumping into an already existing project has been a learning experience. Getting a grasp on what is going on within a project takes time, much more time than I was expecting. This is also in part due working in languages that I am not comfortable with. The trial and error that comes to fixing problems that arise in code that you are unfamiliar with is a much newer experience. Normally I have worked on code from the start and at least have a good idea of the mechanism at play.

This leads us to the prompt for this weeks post, what would I like to do better and what do I want to get away from when it comes to clean code/code smells. I will be using these resources:



One of the things talked about in Refactoring that I tend to do and would like to change is having long classes. I rarely make subclasses within my classes, I think that is in part due to inexperience, but also just part of group things together and putting it all in one bucket. That would be something I like to work on.

There is a notion brought up in Clean Code: A Handbook of Agile Software Craftsmanship that gave me pause to think about. I tend to start all coding projects doing a rough build of a single part so I can test it before moving forward. Then I build on top of that, test it, rinse and repeat. Usually I’ll go back and clean up some code, add more comments, etc. But due to time constraints I rarely fully refactor my code, which leads to heavy code. It is rarely efficient, it rarely is streamlined with up to date coding practices.

Lastly something I would like to avoid is finding myself in the Lazy Class situation talked about in Refactoring. If I am refactoring my code, I should take the time to understand what my code is doing afterwards and find if there is any need for everything or if some tweaks would allow me to eliminate no longer useful classes/procedures.

Print Friendly, PDF & Email

Leave a Reply

Your email address will not be published. Required fields are marked *