一天，在工作中…
Bug #3890 来自客户：
有个程序出现了错误，程序提示说“SpeedCalculator::compute()里出现了除零情况”。
请尽快修复！
你打开SpeedCalculator.php，发现：
简单！是谁写的这段代码，他怎么不用一点脑子！
你就这样修改完了，这个bug只用了你2分钟。
后来，同样的bug又出现在了RatioCalculator和MoneyCalculator中，当把它们也修正后，团队中的所有人都认为，再也不会有这样的问题出现了，这是最后一次！代码现在又是坚固无比了！
一个月后，另外一个bug出现了。这次程序没有崩溃，但客户在报表中发现了错误的计算结果，是因为那句return 0;的代码修改。
如果，我们不是匆匆忙忙的修改，而是退后一步，以更宽广的视野看待些问题。
为什么这种事情会发生？
因为$this->time被赋值成 0.
简单！让我们阻止这种事情发生。
这样，修改的效果不是更好吗？你保证了数据的正确性。但这样客户并不是很高兴，因为当他输入0时，程序会跳到一个错误页面。
那么，你应该在控制层捕捉这个错误，让用一个漂亮的错误页面显示它们。
当做完了这些，你认识到，在RatioCalculator和MoneyCalculator中，你也应该这样做，于是你拷贝/张贴，修改了它们两个。
稍等一下，客户更喜欢让错误信息显示成橘黄色的，而不是红色的。于是，你再次拷贝/粘贴，再次修改一遍。
如果，我们不是修复这个不过，而是发现了一个普遍的要求？
为什么客户会输入 0 ？因为他犯了个错误。
这对我们的要求是什么？
我们只需要这次防止用户输入 0 来避免“speedCalculationForm = 0”吗？
我们只需要让“speedCalculationForm”里的数据合法就行了吗？
还是，我们要对所有的用户输入继续校验？
为什么不开发一个校验工具包呢？
且慢！不要自己去开发一个！请退后一步想想，深呼吸，去使用现有的第三方校验框架。
我们，程序员，热爱计算机技术。当你的客户或老板，大声的脱口说出他们想要的东西时，我们无法阻止，我们只能想象如何去实现它们。
但是，我们需要用更全面的眼光看问题。如果我们想对自己的工作更负责，我们应该去理解为什么他们会提出这样的需求，而不是着急着去寻找解决方案。当然，这可能会占用你更多的精力。
是客户真的需要“一个会躲避鼠标点击的闪光的按钮”吗？还是他们需要的是另外一个功能——他们不了解的功能，需要你去帮他们定义的功能？这种事情同样会发生在你自己身上！你真的需要用程序打开一个文件，往里面写入一些信息吗？还是，你真正需要的是一个日志系统？
退后一步看问题，看更大的蓝图、更完整的信息。虽然你是一个很优秀的编程高手，但编程的目的是为了解决问题。
感觉有收获，点赞留言分享一下吧！！
