In the world of computing, many computer users have been in a state of cleaning up code whenever it is a task, a project, or even just for the sake of the product. This state is called refactoring in which I have decided to read about. So for this first week of blog development, I have chosen to read “Refactoring is About Features” from Code Simplicity. The reason that I have chosen this blog post because as a programmer, I have only heard the word refactoring a few times from doing coding projects in classes and the questions on my mind was: why is “refactoring” important and how does the word come into the ideals of coding. I wanted to know more on how the concept of refactoring and the ideas around it.
This blog post basically goes over the ideas of refactoring and principles of having to refactor. So, by the definition providing by the author, refactoring is an organizational process that you go through in order to make production possible. When it comes to refactoring, you want to be sure the service from it is really making progress. Variety of problems will occur if refactoring isn’t going into real production. On the other hand, if a system was produced and reorganizing was never done, production of the actual product becomes difficult or impossible. Both of these tasks have to be done in order for the product to be produced reliably and quickly while having the system be organized in an effective way. The principles are to refactor a feature service, have the system be in better condition and not worry about being “perfect” but better designed for an intended purpose. If organization is left out, the product is not as envisioned, and if production is left out, then the reason for doing refactoring is not even there anymore. So the overall message is while it’s nice to add new codes, clean up the real obstacles for the intended design to be a reality.
So based on the content the blog post provided with analogies of the real world experience, I would say this was great to read. The author provided some ideas of knowing what purpose of the overall product would be from refactoring and giving tips that shows cleaning development directly and indirectly. From my experience when it comes to cleaning up coding, my mindset would be writing the implied codes that is needed to be clarified and then write a bit of documentation that which shows as much the code is used up to a certain point. In this way, it gives an insight on the structure of the overall design and then like discussions can be made when I ask peers if the piece of code can serve this purpose or even help in finding the real problem.
From this blog about refactoring, I learned is that always be aware to change the design from being not serving an uneventful state to a design with the very current purpose can do with the piece of code it has as it leads to greater productivity and less redundancy. Learning the ideas about refactoring from this blog gives me the reality of seeing that for myself, there should be a boundary in cleaning up coding as I see fit. The reason I say this is while my experience seems to work, I must be aware there should be consistency with using this method and sometimes people do not want to see the same method repeatedly. So I hope to use the knowledge I learned from this blog and build upon it to be flexible within my skills in coding.
-Dennis Tran
Link to the blog: http://www.codesimplicity.com/post/refactoring-is-about-features/
From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.
