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

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

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

换手机了。

因为电池的问题，决定买一部新手机，在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.

 

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

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

这几天在做一个项目的移植工作，将其从原来的6.0移植到VS2008上，因为采用了新的unicode字符集，所以在处理字符串的时候遇到了很多问题，转载一篇文章，有帮助。

从第一堂C语言课上的那个printf开始，格式化字符串就成了我的梦魇。此后我还在很多地方遇到过它们：fprintf，sscanf以及 CString的Format成员函数……。除了能记住%s（String的缩写）代表字符串，%d（Decimal的缩写）代表整数之外，每次用到格式 化字符串的地方我都要求助于MSDN。
    直到我看到C++的字符串格式化方式后，我决定从此抛弃C的那套格式化字符串的方法。
    在C++里格式化字符串，用到的最多的类是：ostringstream以及它的宽字符版本wostringstream。

    话不多说，如果要将一个整数n格式化成字符串以便输出之用
    CString的方式是这样的：


 CString str;
 str.Format(_T("%d"), n); 
    ostringstream的方式： 


ostringstream ost;
ost<<n;
string str = ost.str();
    抛开效率不谈，起码不用再去记%d代表整数，%f代表浮点数，当然还有更复杂的格式控制输出的那些%（此处省略200字……）。
    稍微复杂一点，如果要将整数以16进制的格式输出（这个恐怕是整数输出中最常用的功能了）


ostringstream ost;
ost<<hex<<showbase<<255;
    如果以16进制大写的格式输出：


ostringstream ost;
ost<<hex<<showbase<<uppercase<<255;
    可有时候希望以32位整数的方式来输出的时候，在前面通常要补上多个0，这时可以这样做：


ostringstream ost;
// 也许有更好的写法
ost<<"0X"<<hex<<uppercase<<setw(8)<<setfill(''0'')<<255;
    比起格式化字符串来输入的字母更多，但我觉得这种以人话写出来的方式比较好记:)

    对于浮点数，最长用的格式化功能莫过于在小数点后保留X位的做法。
    比如在小数点后保留6位：


ostringstream ost;
// 将输出1234.567800
ost<<fixed<<setprecision(6)<<1234.5678;
    保留3位


// 将输出1234.568，已经替我们做好了四舍五入
ost<<fixed<<setprecision(3)<<1234.5678;
    实现机制
    C++使用一种称为操控符的技术来控制格式化的输出。

    经典的Hello World的C++版本大概是这样的：   


std::cout<<"Hello World"<<endl;    这将在标准输出上输出Hello World后附带一个换行，并且刷新cout流。一个简单的endl包含了模板和运算符重载两个C++中极有分量的技术。

    对endl的输出将引发下面这个重载了的<<运算符的调用（摘自VS2008的ostream文件）：


_Myt& __CLR_OR_THIS_CALL operator<<(_Myt& (__cdecl *_Pfn)(_Myt&))
    ...{    // call basic_ostream manipulator
    _DEBUG_POINTER(_Pfn);
    return ((*_Pfn)(*this));
    }    而endl正好满足了这个重载的运算符的参数的格式：


_CRTIMP2_PURE