西西河

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

共:💬71 🌺108
全看树展主题 · 分页首页 上页
/ 5
下页 末页
家园 你说得很对

不过对我来说,由我的职业地位决定,我必须把可测性放在第一位。没法测的东西我可不敢签发布许可。

家园 我们程序的日志都不分级的

无论什么事件全都写进日志里,就怕漏了什么。

有好处也有坏处。

家园 请教如何解决这样一个基本问题

客户反映,你的产品出错了,错误代码是0xDEADBEEF.出错前的操作步骤是如此这般如此这般,此外没有其它信息了。你将如何排查错误的来源呢?

我能想到的,就是在程序里多留下线索。还有哪些更好的方法?

家园 以前我负责的程序是这么做的

在一个设置文件里,有个Debug设置,如果Debug=True,程序就会把除错信息写到一个文本文件里,再发电邮给开发人员检查。用户可以通过程序来Enable/Disable Debug.

不过,决定什么信息应该写到文件里,还是挺花脑筋的。太多的话,检查起来麻烦,太少的话,信息又不足。

家园 他把这一通宵安排在分工后的第一个晚上就成了

这说明,如果一项工作一定要加班才能够完成,那就在第一时间加班。

家园 做过一个程序的代码级效率分析

所有用例跑过之后,log占用了CPU时间的1/3还多,log分级很重要啊。

家园 Enterprise级的Software

这么做是绝对不行的,Log本身会成为瓶颈。软件不会scale。

家园 有理!
家园 whoever wrote this should be

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的函数中可以有错误日志也可以没有。

其实在任何情况下,将几个函数联到一条语句中都会造成检测的困难,并且降低程序的可读性。虽然将函数写到一个判定语句中确实能够提高效率,但是就现在的系统性能而言,这个效率不算也罢。

家园 WEB/JAVA的分级日志

还是可以借签,而且是系统级的开关控制

家园 有点不同一点。

对于一个稳定的商业软件,必须考虑系统维护成本,系统运行中的细节应该能够通过日志等技术手段追溯。尤其是一些关键分支的堆栈情况。

在我的团队中,我是要求通过单元测试保证这种分支的情况能被覆盖到,虽然实际上也很难保证达到要求。

家园 另外这种情况的性能优化是没有必要的。

性能优化的3个规律

1.往往80%的性能问题出现在20%的代码中;

2.往往我们认为是性能瓶颈的地方,偏偏不是瓶颈;

3.往往细节上的代码优化会导致更多的微妙问题出现。

所以,根本意见是:[SIZE=3]不要优化,或者不要过早优化。[/SIZE]

家园 此人不适合做技术,早点走人对大家都好。
全看树展主题 · 分页首页 上页
/ 5
下页 末页


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河