Becasue we have to constantly change our code. You may ask, "is it possible some computer genius can implement a software just for once, then the software works perfectly and it requires no further efforts?" The answer is NO. If it is a real software, not just a simple programming exercise task, this kind "once forever" story never happens. In this cruel world, we must be ready to change the given code, perhaps quite often, for example fixing new bugs, adding new features or porting to other programs.
The structure of software becomes more and more complex, even a simple 'notepad' program has hundreds of lines. It is a nightmare for a programmer to changing a spaghetti code mess to make the software work as you wish. Thusfore, we need a good program struture. It can only save a lot of time, effort and money, but more importantly, it makes the software is maintainable, scalable and reliable against to modifications.
Is it possible that architecture can design a nice structure from top to bottom at the beginning, then programmers just write the code execatly according to this perfect design? Theoretically maybe, in pracice almost IMPOSSIBLE. The truth is that you can only more clearly understand your problem, as you have start to tackle it. In a design phase of a software project, it is diffcult for architectures and developpers to fully understand all requirements, to see all aspects of implmenetation and design a perfect structure, until the implementation really is ongoing and people meet one unexpected problem after the other and little by little have a better idea to implement the software. Don't be frustrated, we are human with a limited perception, even the best programmer.
As we constantly update our understanding of project and decide to improve the structure, refactor comes into the play. Refactor is a work that make the program have a better inner struture, but doesn't change it external function and behavior.
"What is a better structure?" I think a good structure is a realization of a right design pattern, so that people can esily understand the code and easily change the code in future.
Personally, I like to refactor before I have to change the code. For example, I want to implement a new feature of software and I find out that I need to change more than ten classes. It is a smell of bad structure. I'd better refactor the program at first. After refactoring, the program has a better inner strucure, perhaps I only need to write a tiny subclass to implement the feature. Summary: Before you want to change the existing code, think about at first the possiblity of refactor. Believe me, you will largely benifit from this good programming habit.
Sometimes, if I don't have too much time pressure, I'd like to spend some hours to investigate whether some classes in the project are too big or too complicated. The command below could be useful to show the line number of class files:
>find -type f -name '*.qml' | xargs wc -l | less
A class with huge size may be a candidate of refactor, more specifically, decomposition: sperate it into several small classes. Small classes are better, easily to understand and easily to maintain than big ones.
No comments:
Post a Comment