阻碍改善设计的常见观念

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

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

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

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