阻碍改善设计的常见观念 推荐

既然软件设计如此重要，那么忽视它就是一种战略短视行为。软件工程师最重要的工作内容理应是进行真正的、创造性的软件设计，而不是只忙于简单地修补漏洞。漏洞是得补，但得补得有艺术、有深度，而不是头痛冶头、脚痛冶脚地补。那种没有深度的修补方式注定是在为将来埋下更大的定时炸弹，也可以预见未来的软件维护工作将愈加的困难。
重视软件设计的首要条件是相关人员（包括软件工程师、项目管理者等）真正明白什么是软件设计，造成忽视软件设计这种现象的原因正是相关人员不明白什么是软件设计，而不是知道什么是却故意不重视它。为此，做好软件设计的关键要素是人 —— 项目组拥有掌握软件设计方法和设计思想的软件工徎师，以及项目团队是在理解和倡导软件设计之重要性这类管理者的领导之下。
软件开发似乎总是容易进入混乱状态，而要从这种混乱状态中走出，应当通过逐步改善设计的方式，而不该是等待那种一次性的“颠覆性时刻”的到来。之所以出现不少项目安于现状，受尽煎熬却无意通过改变走出困境，是因为存在几种常见的观念，这些观念阻碍着项目组去改善设计。

测试可以成为替罪羊或测试是救命稻草？
测试是软件质量保证非常重要的一个手段，是验证软件功能是否与需求相一致的必需方法，但是千万不能将其当作是软件质量的唯一保证方法，更不应当让测试成了软件缺陷的“替罪羊”或质量的“救命稻草”。
现实工作中存在这么一种现象，只要软件发现了新的缺陷，就有人会指责测试部门“为什么没有测出这个问题？”。理论上测试部门应当对最终的产品质量负责，因为它们是质量卫士，但实际上要做到这一点并不容易。原因在于测试部门无论如何努力工作，他们不可能构造出所有的异常测试用例，对于大型系统和分布式系统更是如此，这也是为什么软件行业存在“测试只能证明失败”这种观点的原因。提出“别让测试成了替罪羊”这种观点的目的不在于为测试工程师没有通过测试找出缺陷进行责任开脱，而在于提醒软件开发工程师应更多地从设计的角度去审视“这种缺陷能否通过设计避免？”，或者思考“是不是现在的设计注定了会出现这么多的缺陷，真正有效、彻底的解决方法应当是重新设计（或称之为重构）！”。
作为开发软件工程师，应当明白，如果软件设计没有做好，测试工程师也很难单方面保证最终的软件质量。最终的软件质量一定来源于开发工程师所做出的优良设计，以及测试工程师别出心裁的测试用例设计。设计没有做好却将测试当作“救命稻草”是件很可怕的事，不光项目最终做不好，参与其中的每一个人都将背负沉重的包袱。对于软件工程师来说，在这种项目上工作很可能是在浪费时间。试想一想，一个根基不好的建筑，我们将其装修得再好也不能说这一建筑质量就好，而软件设计如果建筑的根基、测试如同装修。千万不要将质量保证的口号变成“测试，测试，再测试！”，而应当是“设计，设计，再测试！”。
一个设计很糟糕的软件，开发工程师可以试着想一想，如果自己是一名测试工程师，是否能通过设计出完善的测试用例去保障软件的最终质量呢？如果自己觉得也不行，那说明只能通过改进设计去尝试着改变这一问题的答案。

资源永远不足？
或许读者也深深地认同软件设计的重要性，但一定有人其内心深出会发出这样的声音 —— “可是我们没有这么多的时间去做设计啊！人员本来就不足！”，这种想法说到底就是提出资源不足。
对于提出时间不足的读者，有一点笔者需要提醒的是，请确保你的项目组的确存在具备设计能力的人，否则时间不足不是最为紧迫的一个原因。在此姑且假设项目组存在这类人，否则获得这类人应当是项目组的当务之急。
人的欲望是无限的，但资源却是有限的。时间是有限的、人员是有限的、开发设备是有限的等等，当然归根结底都是因为项目资金是有限的。项目也很有可能因为资源不足的因素而进入混乱状态，但是走出这些混乱状态的途径不应是一味的要求投入更多的资源，而应当考虑在现有资源配置条件下尝试着“乱中求冶”。进入混乱相信有资源缺乏的客观因素，但也很有可能是人为造成的（笔者认为这是绝大多数情形），比如不良设计就会造成软件项目成为一个资源“黑洞”，在这种情形下无论投入多少资源可能都是于事无补（推倒重来是一个特例），谁能保证资源投入多了设计就一定好了呢？另忘了资源与行事方式是正交的！如果行事方式不对，投入更多的资源那将意味着更大的浪费。相反，在相同的资源配置条件下，如果每次尝试着“扣”出一点资源来进行设计改进，时间长了就会出现量变到质变的飞跃，从而有可能最终走出困境。
对于一个已经投入使用的软件，当缺陷已让项目组觉得负担沉重时，请不要幻想有一天上司对你说“接下来的半年我们不再增加新的功能，而是专门改进设计以提高质量”。即使有人说了，那很有可能是指其它的意思，或许想表达“因为我们的软件质量太差了，客户都不愿意用了，只能等质量好一点他们才再考虑使用”。等到这种时候再去考虑改进设计，团队的压力反而大了，为什么不平时多花一点努力去做一些微小的改进呢？在投入更多的资源时一定要确保项目组对资源的使用是正确的，如果只是简单地增加时间或人力而在思路或方法上并没有改变那很有可能意味着这种资源的投入是一种盲从。
资源不足不应成为阻碍改善设计的永远借口，也不应指望对系统进行一次性的颠覆改进。“乱中求冶”的方法其实能有效地控制风险，也给了项目组更大的自由空
间。一件事情如果是在“非做好不可”这种压力下进行的，那很容易出现“瓦伦达心态”，那结果很有可能是做不好，因为很有可能瓶颈在于团队的能力，而能力是
在短期内无法获得突破性提升的。而“乱中求冶”的方法不同的是，可以有选择性地让能力更强的人去做改进工作，这样团队能力的不足与“非做好不可”情形相比
不会太明显。当然，“乱中求冶”的方法也有一定的副作用。本来资源已不足了还得抽出一些资源来做改进之事，这会让项目组在短期内承担更多的工作量。但是，
这也是考验项目组的机会。项目组应当清楚地认识到，这种短期的压力是有回报的，它意味着项目在朝更好的方向发展，也意味着会拥有一个更好的将来。另外，乱
中求冶能为项目组提供一种持续锻炼能力的机会。如何在混乱中找到问题的根结并通过设计进行解决是很具挑战性的，每克服一个困难，项目组的能力可能就获得了
一定的提升，而且这类提升将随着时间的推移产生放大效应。除了软件设计质量的提高，乱中求冶还可以帮助打造团队的文化，一种积极面对混乱的创造性文化。

不改变就可以规避风险？
另一种阻碍项目组进行设计改进的思想来源于风险控制意识，具有这种意识的人通常是担心因为改变而增加了风险，且担心过了头。
风险与创造性似乎是一对矛盾，很多组织大力提倡创造性但却严格控制风险。严格控制风险意味着很难获得改变的机会，那创造性也很有可能被扼杀。风险应当有大小之分，如果严格控制所有的风险那意味着所有的风险都是一样的，间接的否认风险有大小之别。控制风险固然重要，但应当有个度，对于小风险的事情应当倡导团队去尝试。什么都不做、不去改变就没有风险了吗？处于混乱状况的项目，其风险不会因为不去改变而消失，运用复杂度守恒定律去理解的话，现在不去改变那将意味着将来会有更大的风险。显然，现在不改变可能短期不会暴露风险，但从长远来看必暴无疑。支持不选择承担短期风险的原因很有可能是“过了两年以后不知这个项目还做不做”，或者是“管它呢，过了几年再说，到时也不管我的事了”。
过度的风险意识很多情形是来源于项目管理者，就作者的工作经验来看，大部分的软件工程师都勇于去承担一定的风险，因为那样的工作对于他们来说才变得有趣且能学到更多的东西，也有不少工程师甚至为了学习技术而不顾风险的存在。作为管理者控制风险是对的，只是要注意方法和度。比如，在做设计改进之前是否可以考虑先引入单元测试的方法以防改出另一个“噩梦”，等等。一定可控的风险，对于项目组的健康是有益的。别忘了除了控制风险，管理者很重要的一个责任是培养团队，一个没有一定风险存在的团队，其工作一定很无趣，也无法激发团队的工作激情和创造力。每个团队或多或少都存在能力强的工程师，如果不给他们一点具有风险性的工作（这类工作通常更具挑战性），那很有可能留不住这些人。
控制风险的一种有效方法就是运用前面提到的“乱中求冶”的思想，通过不断的小改进可以做到让团队在一定的风险刺激之下，同时风险也不至于过大。这么多的好处，为什么不尝试这种方法呢？反之，如果一定要等到整个组织从上到下都关注意（设计）质量改进，那时压力一定很大，风险也一定很高，实在是应当避免出现这种让团队没有退路的境况。
最后，管理者担心改变的风险很有可能是对团队的能力不信任，或者团队的能力真的让人不信任。但能力是通过改变和犯错积累的，就这个角度来说，也应当放手让团队去做一些小小的尝试，因为只有这样团队的能力才有可能提高。因为不信任团队而害怕改变所带来的风险，或许是在为自己制造一个悖论。