什么是软件设计：13年之后
人们偶尔会问我是否对我的“什么是软件设计”文章进行了后续写作。答案基本上是“不，不是真的。”我想明确表示，这不是因为我忘记了它或改变了主意。请允许我提供一些解释。
当这篇文章出现时，我希望——实际上是期望——我会得到某种行业“专家”的某种反驳。我很期待这一点，因为我写这篇文章的部分原因是希望能激发软件行业内关于整个软件开发过程的讨论。什么都没有发生。
没有我知道的写给编辑的信，也没有直接寄给我的信。在那一期之后不久，C++杂志就解散了，我想我的文章已经进入了一片广阔的天地，它吞噬了大多数出版物。我继续做其他事情。直到1997年或1998年，我才收到Bob Martin（他刚刚接任C++ Report的编辑）的电子邮件，告诉我在Ward Cunningham的c2.com网站上有一个关于我的文章的wiki页面。这是——很确切的——我第一次知道有人读过我的文章（除了我亲自给过的人）。
我开始关注维基页面上的讨论，偶尔关注一些新闻组，但出于以下几个原因，我自己故意置之不理：a)当时我专注于某些其他事情，b)其他人很明显接受我想说的话的人同样有资格——也许更有资格——像我一样争论这些观点(我特别记得迈克尔羽毛的写作)，c)最后但并非最不重要的，在我看来，它仍然像这个概念遭到了很多反对。不幸的是，大多数论点听起来很像我当时处理了将近15年的论点(请记住，我在写这篇文章前将近10年就有了这个想法)。
我已经厌倦了试图与那些完全无法超越自己的先入之见甚至理性地考虑这个想法的人打交道。这就像试图向确信“不同语言”实际上只是意味着“不同的英语方言”的人解释说法语说的是不同的语言。不管你说什么，他们都会分析你反对他们信仰的论点，要么立即驳回你，要么用他们的反驳论点光顾你。我见过一些“在代码中设计”的项目，但即使是这些项目的人也经常拒绝接受现实。我对能够改进事物的愤世嫉俗程度非常高。
现在依然是这样，但我认为是时候尝试为自己辩护了，而不是让其他人来。因此，我将要做的是处理一些我所看到的关于“什么是软件设计？”的最常见的批评。
A.最初，我看到的最常见的批评可以概括为“如果源代码是设计，那么程序员就是设计师；但显然它们不是，因此源代码不能成为设计。”没有人说得那么直白，但是当你分析他们所说的话时，它归结为同样的事情。这些都是循环论证，首先假设编程/编码是一种制造类型的活动。在逻辑上，这被称为“Begging the Question”谬误。本质上，这些人说“你的假设（即源代码就是设计）与我的假设（即程序员是装配工人）相矛盾，因此你的假设一定是错误的。”
有人可能会建议我做同样的事情，即从源代码是设计的假设开始。我接受这一点——在一定程度上。虽然我承认很多文章读起来像是试图证明“源代码就是设计”，但这并不是我真正想要做的。以下引述来自文章开头：
“本文假设最终源代码是真正的软件设计，然后检查该假设的一些后果。我可能无法证明这个观点是正确的，但我希望表明它确实解释了软件行业的一些观察到的事实，......”
我并不是要证明“源代码就是设计”；我很容易承认什么是“设计”在某种程度上是一个定义问题。这篇文章的重点是试图展示这个假设如何导致对众多观察到的事实更好的解释。我仍在等待任何人根据替代假设提供更好的解释。
B.如今，部分由于极限编程和其他敏捷方法的兴起，人们开始（勉强）接受程序员不是流水线上的无人机。不幸的是，这并不意味着他们愿意接受"源代码就是设计”。这些论点可以通过仍然在wiki页面上的例子来总结：
“至于把整个设计的东西都扔掉，只用代码来设计……哈哈哈哈哈哈哈真的没有哈哈哈哈哈哈哈:)”
这真的让我很生气。出于我不明白的原因，有理智的人坚持将设计作为过程的概念与作为产品的设计混淆。你会认为任何读过高中的人都能理解写论文的过程和论文本身之间的区别。当然，您会期望任何具有大学背景的人都了解通常有很多不同的方法可以达到相同的解决方案。
尽管如此，人们一直坚持我的“源代码就是设计”的论点意味着“不要做设计，只做代码”。我从来没有说过这样的话。我说的是：
“在软件工程中，我们迫切需要各个层次的设计。特别是，我们需要好的顶层设计。早期设计越好，详细设计就越容易。设计师应该使用任何有帮助的东西。结构图，Booch图，状态表、PDL等——如果有帮助，就使用它。”
今天，我会换一种说法。我会说我们需要好的架构（顶级设计）、好的抽象（类设计）和好的实现（低级设计）。我还会说一些关于使用UML图或CRC卡来探索替代方案。尽管如此，我不会放弃以下声明：
“然而，我们必须牢记，这些工具和符号不是软件设计。最终，我们必须创建真正的软件设计，并且是以一些编程语言的形式。因此，我们不应该害怕像获得它们那样来编码我们的设计。”
这是最基本的。我不是说我们不应该“做设计”。无论你多想接近这个过程，我只是坚持认为你在编写和测试代码之前没有完成这个过程。
就我个人而言，我认为一个双脚放在桌子上盯着天花板的人可以像在ROSE中玩UML图一样认真地“做设计”。我一直都知道，如果你在实际做之前对你正在尝试做的事情进行一些真正的思考，你会过得更好。然而，人们在帮助他们思考的方面存在很大差异。有些人使用铅笔和纸。其他人喜欢白板甚至计算机工具。有些人喜欢从其他人那里获得灵感，有些人喜欢和平与安宁。有些人对像UML这样的图表感到很舒服。其他人更喜欢CRC卡。
他们选择什么方法并不重要；直到有人开始坚持认为这些中间设计本身就应该是产品。重要的是代码。如果你得到好的代码，它是如何产生的真的很重要吗？如果你没有得到好的代码，在人们编写坏代码之前你让他们做了多少其他垃圾真的很重要吗？
从事这项业务的每个人都见过很多这样的例子，一些人显然是坐下来编写了他们脑海中浮现的第一件事。稍后，当这种方法的缺点变得明显时，就会在代码中投入了太多的热血、汗水和“皮肤”来丢弃它然后做得更好。好吧，我们都知道一个小小的想法可以大有帮助。
另一方面，我们任何一个在传统开发项目上花时间的人，在“设计”完成、审查和批准等之前，严格的规则禁止编写一行代码，都知道你会浪费大量时间生成在实际编码开始几天后就已经过时了的文档。何必呢？
你可能想我们可以找到一些做“足够”的设计努力而不是过多的好工具。但哪有这样的工具。我们验证软件设计的唯一方法是构建和测试它。没有银弹，也没有“正确的方法”来进行设计。有时，当真正开始编码时，花一个小时、一天甚至一周来思考一个问题可能会产生很大的影响。而有时，5分钟的测试会揭示一些无论你尝试多久都不会想到的东西。我们在这种情况下尽力而为，然后再完善它。
最后一次申明：我也没有说唯一需要的文档就是源代码。我在文章中特别指出：
“……辅助文档对于软件项目和硬件项目一样重要。”
源代码可能是主设计文档，但很少是唯一需要的。
B'. 我忍不住要评论一个在与上述相关的极限编程和敏捷方法的讨论中经常出现的附带问题。这通常被表述为一个问题：能力较差的程序员怎么办？这个问题看起来似乎是说只有最优秀的程序员才能同时“设计”和“编码”。为了弥补这一点，我们必须拥有上面提到的所有中间设计步骤和产品，以克服普通程序员经验和天资的缺乏。
对我来说，这就像问“能力较差的医生怎么办？”我知道医学和软件开发的是不能类比的，但请耐心等待一会儿。太多的医学上实践几乎都是死记硬背（我们开玩笑说“明天给我吃两片阿司匹林”）。尽管如此，医学界仍然坚持需要相当高的智力、教育和经验标准，然后才能被允许称之为医学博士。换句话说，我们希望我们的医生知道他们在做什么。
在软件开发中，关于能力较差的程序员的问题实际上归结为试图用一个过程代替智力、才能和经验。显然，很多人认为，如果我们强迫人们创建足够多的UML图(或其他类似东西)，足够多的评审，以及其他详细的过程中的东西，最终他们会弄清楚他们在做什么并编码正确。没有证据表明这些方法在过去有效，我认为没有理由相信它们在未来会奏效。事实上，我自己的经验表明，正确使用诸如UML之类的工具本身就涉及相当多的专业知识和经验。
C.我看到的另一个争论是质疑工程工作的目标是某种类型的文档的论点。有些人认为工程的目标是“产品”，真正的工程师经常“构建”事物，而这些“事物”与任何文档一样都是工程产品。
这个论点试图回避“什么是软件设计？”的问题，通过暗示其他工程师构建的“事物”与软件开发人员创建的“事物”之间的平行关系。坦率地说，这是无稽之谈。我承认有些工程师会建造“东西”很少或没有正式的设计文档，我怀疑即使在这些情况下也可能有一些设计文档（即使它在信封的背面）。无论如何，我认为我们可以有把握地说，此类项目只生产一次性产品，通常由个人完成。
当“工程”工作开始涉及多个人时，或者当它具有正式的制造阶段时，文档开始作为工程工作的实际产品越来越大。你最好相信丰田或摩托罗拉的工程师制作文档，我们甚至不会考虑波音或洛克希德的工程师。因此，虽然很多工程师除了制作设计文档之外还做其他事情，但任何自称工程师的人都知道他所在领域的设计文档是什么样的，并且可能经常制作这样的文档。我们可以对“软件工程师”说同样的话吗？
顺便说一下，这个关于工程师和文档的争论最初不是我的，而是我从1979年Datamation的一篇文章中摘取的。但是我完全同意。
D.我看到的最后一个但相当次要的论点是，源代码层次太高，不能成为设计。至少有一位评论家想将源代码称为“规范”。他（或她）认为真正的设计来自编译器。在某种意义上，这只是一个定义问题，但我仍然不同意。
普遍接受的定义是“规范”说明了什么，然后是详细说明如何做的设计文档。虽然在确定目标代码的方式方面允许编译器有一定的灵活性，但肯定不涉及创造力。这就是我画线的地方。当文档足够详细、足够完整、足够明确，可以机械地解释它时，无论是由计算机还是由装配线工人，那么您就有了一个设计文档。如果它仍然需要创造性的人类解释，那么你不需要。
在软件开发中，设计文档是源代码清单。
版权所有©2005 Jack W. Reeves。
