主题：【原创】乱侃软件工程师的素养 1 -- poorfat

不过我是写文档，然后被自己骂的那个。。。经常会忘记文档不是用来充数，而是给别人看的。。。

幸好我们公司小，测试和设计都是我做的，所以，经常是2个月之后再翻文档都忘了是什么东西。。。然后自己骂自己。。。呵呵，后来那一批文档，几乎全是重写的

我们那时候整个学期就两个作业，一个是个人完成的，读取两个位长很大（大约是填满半个9吋屏幕）的自然数，完成加减法，输出结果。另一个是由3-4人的集体完成，读取一个文件，用海明码压缩，生成新文件，再解压缩。最后解压缩的没做完。

90年代初，上机时间少，大部分工作是在纸上完成的，用的PASCAL，加上解释行的语句，简直就是写作文。

为什么不直接用sdk直接提供的方法呢?

按照他的说法：sdk又不是我写的，我怎么知道里面有什么方法。

由于“工作态度不正确”，试用期一结束就让他走人了，后面来的人给他擦屁股又擦了1个月。

可读性更好，更优雅一点，呵呵。

不至于这就让人滚蛋吧。

这个bug，其实QA的责任一点不比这个Developer小，显然没有边界条件这个test case，或者没测啊。

如果所有地方都加log，一定会影响程序效率。而且log file会变得庞大无比和饱含太多冗余信息而几乎无用。

通常的做法是

1)log分级，通常是DEBUG, INFO, WARNING, ERROR.

2)关键地方log，而不是所有地方log。

3）其他地方尽量多用assert。

出问题，可以让客户降低log level，或送个debug build过去。

用户拿到的是什么东西？如果是已经编译过的机器码，写成一行和写成三行没有区别吧。 如果是源代码，用户自然知道怎么跟踪。

而且，既然这三个函数是你的实现，你当然可以把它们封装起来，用户连到底和几个函数相关都用不着知道。用户知道出错了就可以了。就像你说的，

我不认为

里有任何好作用。

唯一可能有作用的是

可是这个完全是接口设计的责任，而不是程序员的责任。为了便于排错，正规的做法是使用不同级别的log.

如果坚持某个级别的exception safety，你所反对的代码完全是合法的。

感觉你们编程部门水平不成呀，log都不分级？

这个写法实际上是有performance上的好处的，这是因为C里面对if中条件处理的编译优化决定的，如果这些func123比较expensive的话还是挺不错的。分在三个嵌套的IF里面的话也可以，但是只要返回码一样对你还是没什么帮助。

当然你说到可测试性等等确实是一个很好的点，我只是说事情的因素有很多，最后的实现是一个综合考虑的事情。

其实QA和程序员之间的误解和战斗在过去，现在，将来都是一个永恒的话题。你的帖子给我的印象是带了一个预设的前提就是可测试性是对你来说最重要的，但是显然程序员有别的因素要考量，因此不见得同意你的观点。

推卸责任,熟悉sdk是从事该工作的基本素质.自己不具备还不虚心接受,这会让愿意帮他的人也泄气的.