“永远不要“ 修正” 任何 东西，除非它真的是一个问题，而且有证据表明问题确实存在。
如果相当多的用户认为某个行为是bug，它就是bug；如果只是少数用户（比如一两个）认为它是bug，那么它就不算bug。
在你的程序中，真正需要关注速度的部分，应该局限于你可以证明的、真正让用户体会到有性能问题的那些部分。对程序的其他部分，最主要关心的还是灵活和简洁，而不是速度。
有些开发人员想让速度尽可能快，所以，他们还没弄清楚速度到底慢不慢，就花时间来优化程序。这就好像做慈善事业时，一边把食物送给富人，一边说“我们只是希望帮助他人。
在动手解决之前，真正拿到证据，证明问题确实存在。
-- 来自《简约之美：软件设计之道》”
作者强调了在解决问题之前应该先确认这个是不是问题。如果确认了是问题才需要去解决。
关于bug：有多数用户反馈的bug才是bug，如果极少数用户反馈的bug，就不应算作bug或者优先级可以排到后面，它不应该属于我们首先解决的问题。
关于性能优化：只有可以证明的，用户体会到性能上有问题的部分才需要去优化性能。
其实这就是“把钱用在刀刃上”在软件开发中的实践：我们的开发资源永远是紧张的，因为无论是现在还是未来都要有很多事情要做。因此我们需要解决的是那些明确的，有证据证明的，真正需要解决的问题。
如果相当多的用户认为某个行为是bug，它就是bug；如果只是少数用户（比如一两个）认为它是bug，那么它就不算bug。
在你的程序中，真正需要关注速度的部分，应该局限于你可以证明的、真正让用户体会到有性能问题的那些部分。对程序的其他部分，最主要关心的还是灵活和简洁，而不是速度。
有些开发人员想让速度尽可能快，所以，他们还没弄清楚速度到底慢不慢，就花时间来优化程序。这就好像做慈善事业时，一边把食物送给富人，一边说“我们只是希望帮助他人。
在动手解决之前，真正拿到证据，证明问题确实存在。
-- 来自《简约之美：软件设计之道》”
作者强调了在解决问题之前应该先确认这个是不是问题。如果确认了是问题才需要去解决。
关于bug：有多数用户反馈的bug才是bug，如果极少数用户反馈的bug，就不应算作bug或者优先级可以排到后面，它不应该属于我们首先解决的问题。
关于性能优化：只有可以证明的，用户体会到性能上有问题的部分才需要去优化性能。
其实这就是“把钱用在刀刃上”在软件开发中的实践：我们的开发资源永远是紧张的，因为无论是现在还是未来都要有很多事情要做。因此我们需要解决的是那些明确的，有证据证明的，真正需要解决的问题。
展开
评论
16