结果readonly一席话让自己明白了许多:
我的桌上正好摆着《重构》,我引用一下:
如何确定该提炼哪一段代码呢?一个很好的技巧是:寻找注释。它们通常是指出[代码用途和实现手法间的语义距离]的信号。 如果代码前方有一行注释,就是在提醒你:可以将这段代码替换成一个函数,而且可以在注释的基础上给这个函数命名。就算只有一行代码,如果它需要以注释来说明,那也值的将它提炼到独立的函数去。——《重构》中文版77页
标红的这段翻译得有问题,原文是:
How do you identify the clumps of code to extract? A good technique is to look for comments.
They often signal this kind of semantic distance. A block of code with a comment that tells you
what it is doing can be replaced by a method whose name is based on the comment. Even a
single line is worth extracting if it needs explanation.
偶觉得这样翻译比较准确:"如果注释是告诉你一段代码在做什么,可将这段代码替换成一个函数,而且可以在注释的基础上给这个函数命名"
Refactoring书上有一段关于注释的解释,可以看出作者对注释的态度,并不是"如果你要加注释,就说明这部分代码需要重构"
Comments
Don't worry, we aren't saying that people shouldn't write comments. In our olfactory analogy,
comments aren't a bad smell; indeed they are a sweet smell. The reason we mention comments
here is that comments often are used as a deodorant. It's surprising how often you look at thickly
commented code and notice that the comments are there because the code is bad.
Comments lead us to bad code that has all the rotten whiffs we've discussed in the rest of this
chapter. Our first action is to remove the bad smells by refactoring. When we're finished, we often
find that the comments are superfluous.
If you need a comment to explain what a block of code does, try Extract Method. If the method
is already extracted but you still need a comment to explain what it does, use Rename Method.
If you need to state some rules about the required state of the system, use Introduce
Assertion.
is going on, comments can indicate areas in which you aren't sure. A comment is a good place to
say why you did something. This kind of information helps future modifiers, especially forgetful
ones.
我想首先是有看书的需求,然后看书,信服了书里所说的——以前没想过的、或是因为这是大师所说的,这是书上说的。。。总之信之而不加多思考,于是渐渐融入自己思维之中,形成了一种定势——这是大师说的,这是书上说的——于是就一直这么干了,我想这也许会为自己埋下什么,也许也无妨,但终归埋下了。