似乎作为一个软件开发者，就注定要背着沉重的行囊，穿行在茂密的热带丛林里，酷热，没有风，只有腐烂的植被、浓浓的瘴气、不时从肩膀上爬过的毒蜘蛛和从脚背上“嗖”地窜过的毒蛇。汗流浃背，疲惫不堪，却不能休息片刻——因为这是一个软件开发的混乱的时代！

充分的前期需求分析？严格的开发流程控制？严密的后期测试？这些都做到了啊，可是为什么软件还是有bug？特别是用户频繁地提出新的要求，软件要不断地修改，每一次修改都胆战心惊几近崩溃，这到底是为什么？神啊，到底要怎么做才能获得好的软件设计啊？

人们一直都没有停止思考如何能够获得好的软件设计。软件工程风行了几十年，“没有银弹”的咒语还没有解除。人们不禁要抛弃所有的“软件工程”带来的规制，回到软件开发的源头寻找答案。如下就是笔者看到的火烧云的形状，像猫像虎任凭端详。

1、要有技艺高超的开发者

软件是人的思维活动的产物，软件开发首先需要的是人的创造性。就如同其他一切人类创作一样，人是占据核心地位的。恐怕再过一百年，也没有哪个自动化的工序可 以代替金庸先生的妙笔写出《笑傲江湖》这样经典的小说。所以，当前软件工程企图用其眼花缭乱的流程控制来达到“软件工厂”的目的，是方向性的错误。人，只 有人，技艺高超的开发者，才是产生好的软件设计的核心因素。

技艺高超的开发者，应当有丰富的软件开发经验。有了丰富的软件开发经验，才会培养 出对软件设计中的各种“坏味道”的敏锐的嗅觉，才能熟练地绕过软件设计中的种种陷阱；有了丰富的软件开发经验，才会对各种软件体系结构模式烂熟于胸，才能 运用成熟的设计模式解决那些普遍的设计问题；有了丰富的软件开发经验，才会对各种语言、工具的特长和限制了如指掌，才能选择针对当前问题的最合适的编程语 言和设计工具；有了丰富的软件开发经验，才会对各种平台和环境的特性和差异有所了解，才能在设计的过程中最大程度地利用平台和环境的特性，并可充分考虑到 程序的可移植性。

技艺高超的开发者，应当有专业的领域知识。软件总是服务于某一领域的应用，各个领域的专业特性不同，使得软件开发也产生了许 多分支。从事某一专业领域的软件开发，必然要对该领域的专业知识有深入的了解，才能在软件设计中正确地把握对概念的抽象。随着软件的复杂性的转移，领域建 模越来越受到重视。在此强烈推荐《领域驱动设计——软件核心复杂性应对之道》（Eric Evans著，陈大峰等译，清华大学出版社出版）一书。

技艺高超的开发者，应当有求真务实的技术作风。在这个浮躁、虚华、官僚化的社会里，“求真务实”显得太可贵！这也是对开发者提出的很高的要求。求真务实的技 术作风，就要求开发者不要盲从技术风潮，软件开发的技术发展飞快，也产生了不同技术流派，各个流派都想扩大自己的影响，这时候就需要开发者自己去识破各种 幌子，吸收真正对软件开发有所助益的好方法；求真务实的技术作风，还要求开发者实事求是地看待各种非技术机制对软件开发的影响，看看这些机制是否对软件设 计质量的提高有帮助，有则批判地采纳，无则无情地抛弃，不要抱有“这个流程是某某认证所必须的，且其他很多公司都这样做了，所以它一定有它的道理”的想 法，这些目前看不到好处的东西，不要指望将来给你带来什么好处；求真务实的技术作风，更要求开发者抛弃官僚主义作风和自大的姿态，在技术面前人人平等，以 开阔的胸襟对待不同技术观点和反对者，友好地同其他人合作，以把软件设计做好为要旨。

技艺高超的开发者的成长需要长期的磨练，代价很 大。且人的因素确实是一个很不确定（流动性很大）的因素，软件工程减少不确定因素的初衷是好的，但是人的地位毕竟不可替代。“软件蓝领”是又一个软件工程 产生的畸形儿，软件工程宣称，只要几个月的短期训练，就可以胜任软件开发的工作。真是可悲！

2、要有合理的软件过程

软 件开发早已不是单兵作战，而是一项有组织的集体活动，但是跟修水库和建筑施工等“工程活动”不同，软件开发需要集中团队中每个人的智慧。软件开发的过程 中，最终要达到的目标在最初往往并不十分清楚，所以需要不断地去探索。软件开发的核心复杂性在于对应用领域的抽象与建模，很多时候，软件开发也是一个建立 模型、验证模型、改进模型的一个不断迭代的过程，所以一个合理的软件过程至关重要。

一个合理的软件过程，应该能获取准确的需求。软件需求据行 业领域和客户的要求不同而差异很大，没有一个通行的模板可以套用，那么就需要对行业领域的充分研究以及与客户的充分沟通来获取到真实的需求。客户把自己的 需求表达清楚本身就是一件困难的事，开发者理解用户的表达又增添了困难，语言会产生偏差，我们注重点的不同也会产生偏差所以往往我们“按照”客户的需求做 出来的东西并不是客户真正想要的东西。再者，很多用户的需求随着时势的变化会发生改变，这都是很正常的。因此，我们不能“苛求”一开始就能全盘获得准确的 需求，要想获得准确的需求，就要保持一直与客户的沟通，允许在我们的开发的过程中客户提出变化，随时表达和强调他们真正想要的“软件”，只有这样，我们的 开发才不会偏离客户的初衷，一切设计才有意义。

因此，合理的软件过程应该将客户需求的表达穿插在软件过程的全部环节中，而不是指望在开始设计之前跟客户订好需求的“契约”就以为万事大吉。

一个合理的软件过程，应该快速的反馈软件构思。软件设计是开发者思维活动的产物，这种思维是建立在领域建模和软件构建的基础上的。建模的过程中，需要开发者 极大地发挥自主性和创造性，不同的人，在不同的知识背景下思考的方式会不一样，所以设计过程迫切需要验证当前的思路是否正确，需要一些反馈信息来证明当前 的模型是准确地满足了某一需求。并且，构思是一个不确定、不严密的脑力活动，对开发者的经验有很强的依赖性，而经验的运用往往会产生不知不觉的错误或疏 漏，所以需要及时的反馈来验证构思的正确性，从而避免“错之毫厘，谬以千里”。

快速的反馈是保证设计构思不会“离题”的必要手段，所以合理的软件过程需要提供一个快速反馈的机制，而不是一味地想象，直到如梦初醒。

一个合理的软件过程，应该保障团队成员的沟通顺畅。团队成员合作开发，共同完成一个软件系统，成员各自的思路之间是有“缝隙”的，要将每个人的设计联结成一 个整体的设计，就需要充分的沟通来填补这些“缝隙”只有充分的沟通，才能保证各个成员各自完成的部分组合起来的协调性，才能避免牛头对个马嘴。Brooks在 其《人月神话》中曾描述过一种情况：往一个效率低下的软件开发团队中增加人员，不但不能提升其开发效率，反而会降低其开发效率。这说明团队成员越少越好， 同时也说明团队成员之间沟通的时间耗费是巨大的。团队成员交流的主要是对系统的理解和自己对模块接口的划分，因此需要的是直接的“对话”，是随时展开的是 “辩论”，是立竿见影的对设计者思路的冲击，这样才高效。而多余的文档、图表、流程或任何其他形式的沟通媒介，不仅耗费了开发者宝贵的时间，更可能引起传 递“信号”的失真，带来歧义。

一个合理的软件过程，应该提倡“Work smart, not just hard.”（笔者借用这种说法，其本义可以参考http://www.jorydesjardins.com/pause/2006/05/what_does_that__1.html），软件设计是一项智力劳动，其核心成果来自开发者发挥自己的聪明才智和创造性。（google就是一个很好的例子。）开发者的创造性来自对行业领域的钻研和领域以外的借鉴，所以，开发者应当有丰富的领域外的知识的涉猎，在行业领域之外也有多姿多彩的阅历和思考素材，发展自己的个性。这样思路才不会呆板，思维才更活跃。

合理的软件过程，应该给开发者营造一个轻松的工作氛围，允许开发者的个性化，才能让开发者身心愉悦地投入到软件设计的虚空间中去，激发设计创意。

回 头审视一下传统的“软件工程”过程。在软件工程中，十分强调“流程”和纪律，追求软件过程越是“自动化”越好。希望需求是被稳固下来，事先就做好，可以作 为“原料”输入到一连贯相互独立“工序”中，通过控制开发人员在每个工序中的作为，使得产品严格按照预先期望的模子生产出来；希望开发者都安分守己地努 力，所有的沟通和交流最好都文档化，以分清责任减少争论，同时以文档为驱动，规规矩矩按部就班地做上一个流程的文档给自己规定好的事情。呜呜，正在焦油坑 里挣扎的猛犸象还少么？

3、要面向代码

再强调一遍：源代码就是设计！

即 使在软件工程中，这一点也是不可否认的（虽然不被承认）。很多人认为，软件设计是指编码之前的“概要设计”和“详细设计”，代码只是“实现”，只是个体力 活儿。但是，代码却是软件设计最真实、准确、有价值的表现。在编码前，再好的构思也只是“预设计”，是没有被验证、没有被认可、没有被赋予现实意义的空 想。“预设计”再好也并不是设计，在所谓“概要设计”和“详细设计”阶段通常不乏玲珑的构思，但是由于轻视了代码（而去重视那些只是临时使用一下的设计文 档），往往能“化神奇为腐朽”，况且没有在代码中被验证与整个系统的协调性的神奇构思，又有什么值得称道的呢？
所以，我们的设计应该面向代码，而不是轻视它。有什么好的设计构思，最好赶紧在代码上表达出来，并很快地验证这个构思是正确的，是与整个系统相容的，而不是把很多构思都堆积在“设计文档”中，掩盖了矛盾和错误，并在编码的时候把它们放大。

设计面向代码，应该从测试用例出发。比较好的方法是采用“测试驱动开发”（TDD）（源自《测试驱动开发》，Kent Beck著） 的方法，直接面对需求，把需求用测试用例准确地表达出来，所有的设计都从测试用例出发，这样我们的设计就能够更贴近真实的需求，直接将需求和代码联系起 来，减少了中间所有的不确定的环节。明确的需求都是可以测试的，编写测试用例的过程其实是一个促使开发者对需求真正认识的过程，这也是寻找好的软件设计的 出发点，实在不应该忽略或轻视。并且有了准确的测试用例做保障，我们在改进过程中随时都可以验证所做的修改的正确性。

设计面向代码，要求在变化中保持代码“健康”。代码是在开发的过程中不停地被改变的，但是随时要保持代码的“健康”。这种改变不是往旧墙上刷新粉，整个过程也不是“code and fix”，特别是软件开发的后期，最好不要有显眼的“补丁”，而应该针对任何变化，最好把所做的修改或加强融入到现有的设计中，使之和谐不留痕迹。至于什么样的代码才是“健康”的，我想这是一个值得展开讨论的话题。

设 计面向代码，切忌盲目复用。软件开发为了提高资源利用率和开发效率，希望能够在新的应用中运用已有的设计成果，最大限度地实现软件复用，这种愿望可以理 解，但复用一定是有条件有限度的。复用别人现成的代码，天然受到别人设计的制约，要想复用，首先要充分了解别人的设计，特别考察它的“通用性”，由于不是 为我们的应用定制的，所以我们的设计要迁就这种“通用性”，这种迁就是相当有风险的，很可能使我们的设计变得僵硬。不记得哪位高人曾经说过“复用只是神 话”，我觉得是很有道理的，采用别人的代码的当时是省心省力，但是后期的维护似乎还有漫长的痛苦等着你。再者，应用是有差异的，哪怕相同的应用，削足适履 而不是根据脚的尺寸去做鞋，是不可取的。

4、要重构

不知道有没有特别厉害的软件设计高手，可以将好的设计一步到位地呈现出来？不过我想对于大多数人来说，设计并不是一蹴而就，而是循序渐进的。最初的设计可能 与最终的设计相差巨大，这是再正常不过的事情。重要的是软件设计要朝一个好的方向演进，重构的过程就是演进的过程。重构是对现有代码的设计进行优化和改 良，《重构：改善既有代码的设计》（候捷等译，中国电力出版社出版）一书指出了存在于代码中的常见的22种“坏味道”，并针对性地提供了一些很中肯实用的重构手法，很值得借鉴。其实重构应该是软件开发者的一种自觉习惯，重构手法也是经过长期实践经验已经潜移默化了的。
最 初的设计总是丑陋的，重构是使“丑小鸭”变“白天鹅”的必要手段。哪怕再巧妙的构思，也会有制肘，哪怕再谨慎的防备，也会有疏漏，所以设计的雏形总会有这 样那样的不足，或多或少地脱离现实问题。这些不足的地方都是可以改进的，关键是有意识地去寻找出这些不足，并纠正它们。因此，我们可以为了更紧密地贴合需 求，放心地让我们最初的设计粗糙一些，我们总可以用重构的方法改造它。

好的设计是不断地重构才显露出来的。设计应当是从需求出发，做出一些 “粗糙”的解决问题的方案，然后根据经验对该方案不断进行改进、完善，使其越来越灵活，越来越趋于稳定，得到的，自然就是好的设计。而不是从经验出发，先 想象出一些“玲珑”的构思，然后修修补补，使其符合我们的需求。前一种方式是借鉴经验，后一种方式是强求经验；前一种方式是慢慢演化水到渠成，后一种方式 是急于求成生拉硬拽；前一种方式灵活，有更进一步优化的空间，后一种方式呆板，越修补越走样。优劣自现。

设计过程中要“两顶帽子”轮流戴。“两顶帽子”是Kent Beck为 了形象地描述重构过程中的两项任务而引入一种比方。一顶帽子是改善现有设计，另一定帽子是增加新功能。提醒我们，任何时候应该只做一件事（除非你喜欢把两 顶帽子摞起来戴）：改善现有设计的时候，就立足于现有设计，用现有的测试用例可以很方便地验证改善的正确性；在增加新功能的时候（容纳一种新的需求），就 充分信任现有代码的正确性，而立足于该功能，关注在新增功能的测试用例上以保证测试用例的正确，同时修改或增加代码使得所有测试用例（包括新增的）通过。 如果觉得新增了功能设计被污染了，别急，测试用例通过后可以换戴另一顶帽子。

5、要新陈代谢

软件设计不是一劳永逸的，技术更新很快，软件设计要为应用服务，就要适应新的技术条件，新陈代谢。软件设计本身要有开放、灵活的架构，而开发者也要有与时俱进、开拓创新的精神。

软件设计要吸纳需求的变化，不断适应新的环境。软件是服务于应用的，应用的背景发生了变化，软件必然要跟着变化，所以好的软件设计要有在变化中存活和发展的 生命力，这就要求软件本身的架构是开放、灵活的。软件架构是在软件在开发的过程中，不断纳入新的需求，软件设计自身不断地进行调整，到最后稳定下来的部 分。所以软件架构是在需求不断变化的打磨下进化而来的，是软件设计的骨架。只有来自于实际应用的动态的软件架构，才方便改变自己以适应应用环境的改变。

开发者要不断学习，提升自己的眼界。软件应用的领域范围广泛，软件技术的发展也朝不同的方向在不断地提升；软件开发的本质规律还没有完全大白于 世，软件业界存在着众多的思想流派，不同流派正对一些技术方法会有一些争议。而开发者往往只能集中精力于某一特定的方向，而对其他方向的发展比较生疏；或 者开发者只信奉一个思想流派，对其他不同的意见不屑一顾——这些都是眼界受局限的表现。开发者应当了解其他领域的一些基本情况，其他流派的一些基本主张， 这有益于反思自己开发中的一些困惑，启发自己的思路。

开发者还要保持开放的心态，要革故鼎新。好的软件设计，要经受住时代变迁的考验和用户的 挑剔。所以设计者要有开放的心态，虚心接受用户的批评和建议，并积极改进软件的设计以满足用户的要求。特别是对于新的有用的技术元素（如新的软件架构理 念、新的网络技术、新的数据库技术、新兴的编程语言等），要有一定的敏感度，要从中吸取积极的启发，来加强软件设计的技术跟进。对于一些不合时宜的设计， 要更新换代，始终保持软件设计与时代同步。

开发者还要有一点完美主义情节。软件设计是软件开发者心血的结晶，是开发者思想的表白，所以开发者 往往对自己成功的作品爱不释手。就像母亲总觉得自己的孩子最棒一样，开发者会觉得自己的设计是最好的。应该对那些倾心尽力做出软件设计的开发者致以崇高的 敬意！但是也有必要提醒他们，要理性客观地对待自己作品的不足，还有不完美的地方。这些话，特别需要善意地对那些对现在的“设计”自我感觉良好的人说。相 当多的开发者，长期在设计的荒原，已经习惯了在萧瑟的秋风和飞砂走石中缉拿隐藏在荆棘中的bug，还从来没有想象过软件设计其实可以做得更好，没奢望过还有鸟语花香的春天。该醒醒了，不要安于在黑暗的屋子里窒息的命运！