本文选自《专业嵌入式软件开发——全面走向高质高效编程(含DVD光盘1张)》一书 《专业嵌入式软件开发——全面走向高质高效编程(含DVD光盘1张)》一书已由电子工业出版社正式出版 李云
著 阻碍改善设计的常见观念既然软件设计如此重要，那么忽视它就是一种战略短视行为。软件工程师最重要的工作内容理应是进行真正有创造性的软件设计工作，而不应当只忙于简单地“修补漏洞”。漏洞是得补，但得补得有艺术、有深度，而不是采用头痛治头、脚痛治脚这样的方式。没有深度的修补方式注定是在为将来埋下更大的定时炸*，也可以预见未来的软件维护工作将愈加困难。 软件开发很容易进入混乱状态，要从中走出必须采用逐步改善设计的方式，而不是等待
“颠覆性时刻”的到来。之所以出现不少项目安于现状，即使受尽煎熬也无意通过改变走出困境，是因为存在几种常见的错误观念。 测试是替罪羊或救命稻草测试是软件质量保证的重要一环，是验证软件功能是否与需求相一致的必需方法，但是千万不能将其当做软件质量的唯一保证方法，更不应当让测试成了软件缺陷的“替罪羊”或质量保证的“救命稻草”。 现实工作中存在这样一种现象，只要软件发现了新的缺陷，就有人会指责测试部门“为什么没有测出这个问题？”理论上，测试部门应当对最终的产品质量负责，因为它们是质量卫士，但实际上要做到这一点并不容易。原因在于测试部门无论如何努力工作，也不可能构造出所有的测试用例(test case)，对于大型系统和分布式系统更是如此。这也是为什么软件行业存在“测试只能证明失败”这种观点的原因。 提出“别让测试成了替罪羊”这种观点的目的不在于为测试工程师进行责任开脱，而在于提醒软件开发工程师不要忘记从设计的角度去审视“这种缺陷能否通过设计避免？”，或者思考“是不是现在的设计注定了会出现这么多的缺陷，是否可以通过改善设计来真正有效、彻底地解决问题？” 软件开发工程师应当明白，如果软件设计没有做好，测试工程师也很难单方面保证最终的软件质量。注意：他们也只能保证用户级的软件质量。最终的软件质量一定来源于开发工程师所做出的优良设计，以及测试工程师别出心裁的测试用例设计。 设计没有做好却将测试当做“救命稻草”是一件很可怕的事，不光项目最终做不好，参与其中的每一个人都将背负沉重的包袱。一个根基不好的建筑，再怎样通过外部加固也不能成为优质工程。而软件质量的根基即是设计质量。千万不要将质量保证的口号变成“测试，测试，再测试！”，而应是“设计，设计，再测试！”。 最后再指出一点：对于一个设计很糟糕的软件，开发工程师可以试着问“如果我是测试工程师，能否通过设计出完善的测试用例去保障软件的最终质量呢？”。如果自己也觉得不行，那说明只能通过改善设计去尝试着改变这一问题的答案。 资源永远不足很多项目的困境是由不良设计所造成的。当项目处于困境中时，不能一味地指望投入更多的资源。“资源不足”在很多情形下是我们不愿意改变现状和承担风险的一个借口。 当我们身处困境时，不能幻想有一天上司说“接下来的半年我们不再开发新的功能，而是致力于改善设计以提高产品质量”。即使听到这句话，那很有可能是指“因为我们的软件质量太差了，用户都不愿意用了，只能等质量好一点他们才考虑使用”。在这种“非做好不可”情况下再考虑改善设计，团队的压力就更大了。我们必须选择更好的途径——“乱中求治”。 “乱中求治”是指在现有资源的配置下，长期**“抠”出一点资源来逐步改善现有设计，以期最终实现设计质量质变的方式让项目走出困境。 “乱中求治”的方法是为了避免重写软件这种颠覆性时刻的到来，既能有效地控制风险，也可以给项目团队更大的余地。 我们不能乐观地认为重写软件就一定能做出更好的设计，设计做不好的瓶颈可能在于团队的能力，而能力在短期内是无法获得突破性提升的。“乱中求治”能为项目团队提供一种持续锻炼能力的机会。如何在困境中找到不良设计的根源并通过改进加以解决是很具挑战性的工作内容，每克服一个困难，项目团队的能力就获得了一定的提升，而且这类提升将随着长期**而产生放大效应。 除了软件设计质量的提高外，“乱中求治”还可以帮助打造团队的文化，一种积极面对困境的创造性文化。资源不足不应成为阻碍改善设计的永远借口！ 不改变就可以规避风险另一种阻碍项目团队进行设计改进的思想来源于风险控制意识，具有这种意识的人担心因为改变反而增加了风险。 风险与创新似乎是矛盾的，很多组织大力提倡创新但却严格控制风险。严格控制风险意味着很难获得改变的机会，那创新也很有可能被扼杀。风险应当有大小之分，如果严格控制所有的风险，那就是间接否认风险有大小之别。控制风险固然重要，但应当有个度，对于小风险的事情应当倡导团队去尝试。 处于混乱状况的项目，其风险不会因为不去改变而消失，运用复杂度守恒定律去理解的话，现在不去改变那将意味着将来会有（更大的）风险。现在不做改变可能短期内不会暴露已存在的风险，但从长远来看暴露是必然的。不选择承担短期风险的原因可能是“过了今年后不知这个项目还做不做”，或者是“管它呢，过了今年再说，到时也不关我的事了”。 过度的风险控制意识大多来源于项目管理者。就作者的工作经验来看，大部分的软件工程师都勇于承担一定的风险，因为这使工作变得有趣且能学到更多的东西，甚至有工程师为了学习新东西而不顾风险的存在。作为管理者控制风险是对的，只是要注意方法和度。 让团队处于一定可控风险的压力之下对于团队的发展是有益的。别忘了除了控制风险外，管理者很重要的一个责任是培养团队。一点风险都没有的工作一定很无趣，也无法激发团队的工作激情和创造力。团队如果不给工程师一点更具风险性的工作，那很难让工程师得到成长，也很难将他们长期留在团队中。控制风险的一种有效方法就是运用前面提到的“乱中求治”思想。 管理者担心改变的风险很有可能是对团队能力的不信任，或者团队的能力真的让人不信任。但团队的能力从何而来？能力往往是通过改变和犯错积累的，就这个角度来说，在可控的前提下管理者应当放手让团队去做一些小小的风险性尝试。因为不信任团队而害怕改变所带来的风险，或许是在为自己制造一个悖论。 | 
楼主
标题置顶
标题高亮
