西西河

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

共:💬71 🌺108
分页树展主题 · 全看首页 上页
/ 5
下页 末页
    • 家园 【原创】素养 2 - 留下痕迹

      另一个和程序可测性相关的问题是,无论你的程序怎么写,一定要记住要想尽办法留下痕迹(trace) ,以便将来可以方便地排查错误。

      请看这样一段程序:(以下用伪码表示)

      function_one( ... );

      function_two( ... );

      function_three( ... );

      够了,我又要骂人了。这个比上面的例子更糟糕。你连着调用三个函数,却没有作任何检查。 你根本不可能知道会发生什么事情,就连出错了你都不知道。

      如果你的程序是一个大项目的一部分,而且已经有了一个标准的日志函数(logging function), 那么你最好不仅要加查错语句,还要加日志语句。

      比如像这样:

      log("calling function_one ...");

      if ( !function_one(...) )

      {

      log("calling function_one failed.");

      return OMG_WE_FAILED_AT_ONE;

      }

      另两个以此类推。

      如果你的项目里已经定义过异常类,那更好了。你可以用try-catch语句, 像这样:

      try

      {

      function_one( ... );

      function_two( ... );

      function_three( ... );

      }

      catch (e)

      {

      log("an exception is caught. "+ e.message);

      }

      总之,你要想尽一切办法留下痕迹。将来你排查错误的时候,你会明白这些都是值得做的。

      • 家园 log太多不是好事

        我以前的项目组就碰到过因为log级别设置错误和程序本身的debug级别log太冗余,造成log文件1分钟100M+的速度吃掉硬盘,导致磁盘被塞满的事故。

        • 家园 应该可以配置的

          典型的如Log4J里的Level设置。最可恨的是“出错贪污”

          catch (Exception e) {}

      • 家园 这段代码有很大问题

        try

        {

        function_one( ... );

        function_two( ... );

        function_three( ... );

        }

        catch (e)

        {

        log("an exception is caught. "+ e.message);

        }

        你把异常给吃了,这个很糟糕。

      • 家园 建议你search一下 exception safety

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

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

      • 家园 加一条

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

        通常的做法是

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

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

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

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

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

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

      • 家园 【原创】素养 (3) 永远不要许诺你完不成的任务

        很多人说过这个问题了,但我还是要再次强调这一点。因为还经常能看到有人犯类似的错误。 切记,永远不要许诺你完不成的任务。

        说一件真事儿。大学的时候我们学软件工程课。全班分成几个组,合作完成几个编程的项目。一个小组大约5到6个人,每个人负责写一个项目的一个模块,然后整合在一起作总体测试。 我的小组里有一位公认的编程高手,我们决定把一块主要模块分给他做。每星期小组开会交流各自的进度。每次他都说没问题。其实他其他课程很忙,没有足够的时间可以花在这个模块上。学期临近结束的时候,其他小组成员都完成了各自分配的模块,就他还一点没动。 我们问他有什么困难,我们其他组员可以抽时间帮他。他拒绝了,说保证按时完成任务。 然后就是期末考试,大家忙得一塌糊涂,没人过问这事儿。等到项目要上交的前一天晚上,他赶到机房,写了一通宵的程序,终于把他的模块做完。 然后我们几个做总体调试,发现一大堆错误。改了几个主要的错误,后来小的错误就没改。 卡在预定时间匆匆上交了。

        毕业以后,我没再和他联系。想必他一定在某个IT公司高就。祝愿他不会再犯同样的错误。

        几年来我一直想这件事情对我们教训是什么。我认为,教训就是: 永远不要许诺你完不成的任务。

        然后还有一个推论: 如果你发现你完不成任务了,要尽早通知其他相关人员,并且立刻寻求帮助。死撑是没有用的。再强的程序高手也有玩不转的时候。

分页树展主题 · 全看首页 上页
/ 5
下页 末页


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

Copyright © cchere 西西河