主题：【原创】乱侃软件工程师的素养 1 -- poorfat
不过对我来说，由我的职业地位决定，我必须把可测性放在第一位。没法测的东西我可不敢签发布许可。
无论什么事件全都写进日志里，就怕漏了什么。
有好处也有坏处。
客户反映，你的产品出错了，错误代码是0xDEADBEEF.出错前的操作步骤是如此这般如此这般，此外没有其它信息了。你将如何排查错误的来源呢？
我能想到的，就是在程序里多留下线索。还有哪些更好的方法？
在一个设置文件里，有个Debug设置，如果Debug=True,程序就会把除错信息写到一个文本文件里，再发电邮给开发人员检查。用户可以通过程序来Enable/Disable Debug.
不过，决定什么信息应该写到文件里，还是挺花脑筋的。太多的话，检查起来麻烦，太少的话，信息又不足。
这说明，如果一项工作一定要加班才能够完成，那就在第一时间加班。
所有用例跑过之后，log占用了CPU时间的1/3还多，log分级很重要啊。
这么做是绝对不行的，Log本身会成为瓶颈。软件不会scale。
fired immediately.
很重要的原则,应当将错误码报告放在函数中,即发现错误的第一时间.
有几点好处:
1. 更容易定位错误,例如function1()返回失败到底是参数错,还是检索不到结果或结果不匹配?只有在function1()内部才能给出.
2.上层模块可以从具体的错误返回中抽象出来,用楼主的例子举个具体的例,假设是个密码检测函数,那么:function1() / function2() / function3()之一返回失败,上层模块只要知道"密码错"就够了,至于是密码长度不同,大小写不匹配或是密码不同那是下层函数的责任.如故写成:
const bool OMG_WE_FAILED = false;
bool ret = ture;
if (!function1()) {log("Length Unmatched"); ret = OMG_WE_FAILED;}
else if (!function2()) {log("Passwrod Unmatched"); ret = OMG_WE_FAILED;}
else if (!function3()) {log("Case Unmatched"); ret = OMG_WE_FAILED;}
return ret;
那才UGLY
3.程序有更好的可读性,更符合人的思维逻辑
一种function这个函数是用来检测状态的，那么状态不对返回值为FALSE，这种情况下，在function中不作日志提示，而在调用function的函数中应该给出错误提示。
另一种是function函数本身就是一个过程动作，在过程中出错，在function函数内部就应该有日志提示出错原因，并且不同的错误有不同的错误码返回值。而在调用function的函数中可以有错误日志也可以没有。
其实在任何情况下，将几个函数联到一条语句中都会造成检测的困难，并且降低程序的可读性。虽然将函数写到一个判定语句中确实能够提高效率，但是就现在的系统性能而言，这个效率不算也罢。
还是可以借签，而且是系统级的开关控制
对于一个稳定的商业软件，必须考虑系统维护成本，系统运行中的细节应该能够通过日志等技术手段追溯。尤其是一些关键分支的堆栈情况。
在我的团队中，我是要求通过单元测试保证这种分支的情况能被覆盖到，虽然实际上也很难保证达到要求。
性能优化的3个规律
1.往往80％的性能问题出现在20％的代码中；
2.往往我们认为是性能瓶颈的地方，偏偏不是瓶颈；
3.往往细节上的代码优化会导致更多的微妙问题出现。
所以，根本意见是：[SIZE=3]不要优化，或者不要过早优化。[/SIZE]