荒诞不经的十个软件工程真相
文摘
科技
2024-05-01 08:25
美国
软件界的炒作也不差！工具和技术改进总被夸大成天翻地覆的变革，可实际效能和品质提升也就是5%到35%。引入新工具和技术就像培养一颗小幼苗，得经历一段学习期，期间可能会损失一些效能和品质。唯有耐心等到学习期结束，才能见到正面效果。所以，引入新玩意儿得三思而后行，得看看能不能给你带来实实在在的回报才好下定决心。有些开发人员天天吹嘘各种工具，说什么公司非得买这买那，但真正在项目中用到的却寥寥无几。这不是叶公好龙是什么？软件估算常常在错误的时间（项目前期，需求及方案不明确）由错误的人（管理人员、市场人员而非开发人员）进行，所以往往是不靠谱的。而且，在项目进程中，这些不靠谱的估算往往不被及时纠正，而偏离了估算目标被管理层视为严重的失误。大家都在谈论软件复用，却很少有人知道复用的“三法则”：开发可复用模块的投入是开发单应用模块的三倍；可复用模块在发布前，需要在三个不同应用中被成功使用。修复生产环境中发现的需求错误需要付出巨大的代价，而修复开发前期发现的需求错误则是最经济的。然而，大部分需求错误都是在部署和使用过程中才被发现的。需求转设计时，往往会暴露出大量隐含的扩展需求。一个需求条目可能对应多达50个设计条目，可我在评估时看到的设计文档规模常常和需求文档规模差不多。缺乏领域知识的开发人员在开发这样的设计时，大概率会造成遗漏需求的错误。研发认为被充分测试过的程序，其实也就是跑了60%左右的逻辑路径。如果用些自动化测试工具支持，如覆盖分析工具，路径覆盖率也许能提升到90%。所以，别轻易相信逻辑路径100%的测试覆盖。严格、有效的技术评审可以清除90%植入的缺陷，也就是说测试只需要发现10%的Bug。然而，90%以上的中国CMMI五级企业，在评审中发现的缺陷不到总数的一半。软件维护占据软件总成本的大约60%，然而在开发过程中，维护需求往往被忽视。CMMI中针对维护的实践似乎被置于一边，成了被遗忘的角落。项目软件工程开发做得好，后面会带来更多产生价值的维护。许多人并没有理解二者之间的关联关系。
![]()
三尺讲桌就在这小小二维码，长按二维码“识别”关注
