老早就想读《Refactoring》，但是几次三番都没有能够成功，现在项目不太忙，同时也正好抽空开始对已经完成的代码开始改善，提高代码的质量，所以重新下载了《Refactoring》，开始阅读，希望这次能够坚持下去，完成这本书，提高自己的代码和设计能力。

今天阅读了开篇第一章，其中讲到了一个重构原则。

when you find you have to add a feature to a program, and the program's code is not structured in a convenient way to add the feature, first refactor the program to make it easy to add the feature, then add the feature.

这个原则打破了工程界的一条古老准则“如果还可以运行，就不要尝试去修改它”，也就是说，只要你的程序没有知名的问题，就不要花时间去修改它。既然重构是改善既有代码的质量，所以，即时代码可以运行，也要不断地尝试改变他的质量。

继续阅读。

 

 

前日和友人聊天，其间说到张爱玲，他给我讲了了一个张爱玲关于白玫瑰，红玫瑰的理论。大概意思是这样子的：

如果你的身边有两个女人，一个是白玫瑰，一个是红玫瑰。如果你钟情于红玫瑰，那红玫瑰就是你的心头肉，而白玫瑰就像你华丽外衣上的一个饭粒，是令人讨厌的，总是想着把它弹掉。如果你钟情于白玫瑰，那红玫瑰就是被拍死的蚊子的血，是令人作呕的，而白玫瑰，却依然是那圣洁的白玫瑰。

我当时听完，真是如雷贯耳，想想这张爱玲真是太深刻了，有时候甚至有些恶毒的意味，揭开世人...

换手机了。

因为电池的问题，决定买一部新手机，在Nokia 6300和Moto U9之间比较了以下，最后还是决定买Nokia 6300. 一是因为操作比较熟悉，二是外形我也比较喜欢，其实主要是被他的广告所蛊惑。

别了，我的6030；别了，毕业后买的第一部手机；别了，陪伴我四年的6030；别了，贴满无数贴纸，传递无尽爱语的对讲机。

 

 

最近在一个项目中，发现同事总是希望在类中，或者是项目中添加一些不必要的方法或者功能。他给出的理由是：你可能会用到这个功能。

实际上，在软件设计中有这样一条准则：

You ain't gonna need it

对于这些你可能用到的功能，如果不是用例的必须，另可不要。所以，坚持适可而止的设计，让你的类和项目尽量的保持苗条，这样，省时又省力。同样的，还有KISS原则。

"You aren't gonna need it" (or YAGNI for short) is the principle in extreme programming that programmers should not add functionality until it is necessary.^[1] Ron Jeffries writes, "Always implement things when you actually need them, never when you just foresee that you need them."^[2]

Contents [hide] 1 Rationale 2 Balancing concerns 3 See also 4 References 5 External links

[edit] Rationale

According to those who advocate the YAGNI approach, the temptation to write code that is not necessary at the moment, but might be in the future, has the following disadvantages:

• The time spent is taken from adding, testing or improving necessary functionality.
• The new features must be debugged, documented, and supported.
• Any new feature imposes constraints on what can be done in the future, so an unnecessary feature now may prevent implementing a necessary feature later.
• Until the feature is actually needed, it is difficult to fully define what it should do and to test it. If the new feature is not properly defined and tested, it may not work right, even if it eventually is needed.
• It leads to code bloat; the software becomes larger and more complicated.
• Unless there are specifications and some kind of revision control, the feature may not be known to programmers who could make use of it.
• Adding the new feature may suggest other new features. If these new features are implemented as well, this may result in a snowball effect towards creeping featurism.

[edit] Balancing concerns

Judging to omit a feature due to the YAGNI viewpoint should be balanced against other concerns, such as benefits of refactoring code, anticipating upcoming features, team expectations (or fears), availability of part-time expert assistance, and providing for completeness of functionality.

Note that the concept of avoiding unnecessary work with the YAGNI principle must be tempered against the potential need for refactoring software modules to make them simpler or faster in the future. If a software module, or an entire software product, represents a dead-end effort at the time, then any further modifications (such as refactoring) can be viewed as YAGNI issues. However, this concern is somewhat obviated by the effects of YAGNI itself - that is, it is always easier to refactor simpler code.

Another restriction is the potential for enhanced features for the customer. A feature which might seem unnecessary, at an early point, might become part of a vital future enhancement adding value to the product. Such judgments, assessing current and future features, should probably involve discussions with multiple people to help determine a "yes" or "no" decision about implementing such features. Of course, YAGNI only applies to features that are known not to be needed.

Also affecting the decision is the impact of fear or confusion for the people involved with a new feature. An individual or team working on a new enhancement might face disappointment if the new work is denied, or demanded, against their personal expectations, either excited about the new work, or dreading the anticipated workload, associated with a particular feature. This concern should obviously be handled well prior to YAGNI principles being applied.

Yet another conflicting factor is the access to expert assistance, which might be limited. For example, experts might be available to design features X, Y, or Z, and also recommend another, but currently unneeded, feature W. A judgment call is needed to determine whether such expert design of an unneeded feature should be encouraged, while the expert is available, to support potential product enhancement in the future, where enhancements would be implemented by junior personnel after the expert has left. Perhaps a bigger concern stems from depending on outside expert assistance at all.

A logical conflicting factor is the notion of completeness, which tends to define missing options, or facets, mostly likely to be needed: for example, among features which allow adding items, deleting items, or modifying items, completeness could be used to also recommend "renaming items". The critical impact of completeness can be seen in some types of wiki-collaboration software which can add or delete image-files, but not rename images. Of course, YAGNI, by definition, would not apply to features that are needed to "complete" the project.

In general, the YAGNI viewpoint must be balanced against the other concerns, such as those of refactoring, upcoming vital features, team expectations, part-time expert assistance, and logical completeness.

 

今天在网上找一个将菜单项置灰的方法，结果方法没有找到，却找到了Joel Spolsky对这种“标准做法”的反对意见：

A long time ago, it became fashionable, even recommended, to disable menu items when they could not be used.

Don't do this. Users see the disabled menu item that they want to click on, and are left entirely without a clue of what they are supposed to do to get the menu item to work.

Instead, leave the menu item enabled. If there's some reason you can't complete the action, the menu item can display a message telling the user why.

 

恩，看完之后，表示赞同！

告诉用户原因会有较好的可用性：因为我知道了为什么这个菜单不可以用，总比让我去猜测好。