Refactoring the new approach to revamp systems and software. Refactoring in my opinion is very powerful concept and instrumental in technology. It is the only way to keep your customers loyal to your technology! It is by doing small updates and not major tweaks without major changes or disruption. Think Facebook, think IBM think twitter, think google, think HP, think apple – All of these innovative companies push tiny updates to the users without disrupting the system. But Notice 1 year ago facebook functionalities look how different it is today – Same for Google – Apple – IBM etc. and they went through small changes!
Continuous Small updates to the software and hardware to improve the system is very important. It will not require to make major changes and wait for the next release which can take years. In contrast with continuous tiny updates you as an IT company are keeping up with the speed of change and aligning yourself directly with the user.
Refactoring the process that IBM and major IT companies use to get innovation into the field faster. It refers to making lots of tiny changes to a set of source code that doesn’t modify its external function, but improves how that function is delivered. To do this refactoring function, you have to break down code into functional units and iteratively improve them as you can. This sounds dirt simple, and was done by many forward-thinking programmers, but refactoring wasn’t really even discussed academically until the early 1990s. The idea is to make many small tweaks that don’t disrupt the code, do them quickly and do them often, instead of trying to do a big-bang version upgrade with a feature dump and all of the woes that creates for development and test. The canonical book on refactoring, called Refactoring: Improving the Design of Existing Code, is written by Martin Fowler, Kent Beck, John Brant, William Opdyke, and Don Roberts.In technology and Hardware world refactoring is Making systems more modular so they can be tweaked more frequently instead of being revamped every couple of years.
Refactoring is changing the structure of a program without changing its functionality. Refactoring is a powerful technique, but it needs to be performed carefully. The main danger is that errors can inadvertently be introduced, especially when refactoring is done by hand. This danger leads to a common criticism of refactoring: why fix code if it isn’t broken?
There are several reasons that you might want to refactor code. The first is the stuff of legend: The hoary old code base for a venerable product is inherited or otherwise mysteriously appears. The original development team has disappeared. A new version, with new features, must be created, but the code is no longer comprehensible. The new development team, working night and day, deciphers it, maps it, and after much planning and design, tears the code to shreds. Finally, painstakingly, they put it all back together according to the new vision. This is refactoring on a heroic scale and few have lived to tell this tale.
A more realistic scenario is that a new requirement is introduced to a project that requires a design change. It’s immaterial whether this requirement was introduced because of an inadvertent oversight in the original plan or because an iterative approach (such as agile or test-driven development) is being used that deliberately introduces requirements throughout the development process. This is refactoring on a much smaller scale, and it generally involves altering the class hierarchy, perhaps by introducing interfaces or abstract classes, splitting classes, rearranging classes, and so on.
A final reason for refactoring, when automated refactoring tools are available, is simply as a shortcut for generating code in the first place — something like using a spellchecker to type a word for you when you aren’t certain how it’s spelled. This mundane use of refactoring — for generating getter and setter methods, for example — can be an effective time saver once you are familiar with the tools.
