- 程序有所改变。发帖如还有问题请报告
- 【征集】西西河的经济学，及清流措施，需要主动参与者，『稷下学宫』新认证方式，24年网站打算和努力目标
主题：【原创】乱侃软件工程师的素养 1 -- poorfat
我以前的项目组就碰到过因为log级别设置错误和程序本身的debug级别log太冗余，造成log文件1分钟100M+的速度吃掉硬盘，导致磁盘被塞满的事故。
看看我也受影响了不是。
你的观点对于企业的应用那是相当有道理的，但仍然不排除开发底层驱动，游戏等对那一点点运行效率的追求。在海量数据时代，对效率的追求重又引起重视。
但对于绝大部分的IT工作，尤其是以企业的应用为目的，则你这个的观点具普遍性，而且所反映的指导思想，比如对软件工程与编成技巧的不同重视程度，也是老印的软件业能够在欧美横扫千军，而老中的软件业发展出低级蓝领程序员与微软研究院共存的尴尬局面的最大原因。
两年后自己再读了一遍这篇旧文，感觉还是很适用。
顶上来自勉。
细节缺失是可怕并容易忽略的事情，大量的细节缺失导致的结果只有失败，并且关键细节的缺失往往是致命的。
否则你会得到手下写过来的五花八门的代码
如果你作为甲方带外包团队,不做code review,到了后期维护有99.9999999..%的可能性会成为会走路的杯具
我是88本科,那时候上机时间很少,只能是在教室写好程序带到机房去打,当时指法都很差,键盘上一个字母一个字母的找啊
可怜编译原理的大作业,2000多行的PASCAL 也是这样慢慢的敲进去然后再调错误.并且还不能单步调试 只能提交上去再看错误提示
return error_code_1;
} else if(!function_2()){
return error_code_2;
} else if(!function_3()){
return error_code_3;
}
这样写清楚点。
{
return OMG_WE_FAILED;
}
这个隐含的问题是，当第一个表达式不为0时，后面两个函数是不会执行的，这样写很容易造成后面维护的人理解出现歧义
了工作的50%一样，否则，剩余的过程让人提心吊胆，牵肠挂肚！！
送花。注：送花、宝推可能得宝 关闭
送花成功，可取消。有效送花赞扬。感谢：作者获得通宝一枚。
参数变化，作者，声望:1；铢钱:16。你，乐善:1；铢钱:-1。本帖花:1
血泪经验：程序的可测性（testability）是非常重要的。。。
典型的如Log4J里的Level设置。最可恨的是“出错贪污”
catch (Exception e) {}