我反复回想起Fred Brooks在1986年写的一段话。他的论点很简单。没有任何单一发明、工具或技术能让构建软件变得 dramatically 更容易。进步确实在发生但它永远是局部的永远留下某些未解决的问题。四十年后我认为他是对的。而我认为我们一直在忘记这一点。1、两种困难Brooks将软件的困难分为两类。第一类是构建过程中产生的所有摩擦环境搭建、配置、在接触实际问题之前必须编写的样板代码。他称之为偶然复杂性accidental complexity。不是因为这不重要而是因为它不是来自问题本身而是来自过程。第二类是问题本身。系统需要做的三十件事情。没人想到直到它们发生的边界情况。单独看合理但组合在一起就冲突的业务规则。他称之为本质复杂性essential complexity。它的存在是因为问题本身确实很难没别的。软件史上大部分进步都在削减第一类复杂性。这种进步是真实的。但一旦你清除了偶然摩擦本质复杂性仍然在那里纹丝不动。2、我们以前也庆祝得太早了有一个值得注意的模式。Rails在2004年出现确实改变了格局。在此之前构建一个Web应用意味着要从头写很多东西认证、会话处理、数据库访问模式。Rails说别再做了我们来处理。开发者可以更快地行动把更多时间花在真正重要的部分。那是真实的进步。有一段时间人们说话的语气好像软件的难题终于被我们抛在身后了。并没有。本质复杂性仍然存在。改变的是你到达它的速度。JavaScript世界后来经历了类似的事情。多年来作为前端开发者的很大一部分工作就是在管理工具链的工具链。新的构建系统、新的框架、不断的变化。最终事情稳定下来。又一次进步。每一次如释重负的感觉都是真实的。每一次核心困难依然存在。3、构建东西的真实感受编写软件主要是弄清楚代码应该说什么而不是编写代码这个动作本身。你给一个概念命名然后发现名字有点偏。你把一个东西拆成两个然后发现这两个东西从头到尾其实是同一个东西。你试图表达一个行为却发现很别扭而这种别扭告诉了你关于你设计的一些信息。慢慢地通过所有这些一个真正适合问题的词汇表浮现出来。没有人能在开始之前完全知道解决方案的正确形态。形态是通过构建过程揭示的。第一个版本始终是草稿即使它能运行因为它反映的是你开始时的理解而不是结束时的。好的软件往往来自接受这种节奏的人。他们知道理解会随着进展而加深他们保持开放倾听工作本身告诉他们什么。4、困难的部分为什么一直困难软件中真正困难的事情几乎与语法或工具无关。它们关乎理解人们实际需要什么这往往与他们要求的不同。它们关乎以没有人注意到的方式冲突的规则直到生产环境中出了问题才被发现。它们关乎一个为单一目的构建的系统慢慢变成了负责五个其他目的的系统。还有一个脆弱的地方是理解如何在团队中存在。为什么以某种方式构建的心智模型做了什么权衡什么被刻意排除。很多这些存在于人们脑海中而不是文档中。当这些人离开时即使代码完好无损一些真实的东西也丢失了。这就是为什么本质复杂性不断出现。问题很困难而我们对问题的把握总是比我们想象的松一点。5、进步仍然重要以上这些并不意味着事情永远不会变好。它们会的。每一波减少偶然摩擦的工具浪潮都改变了什么是可能的。当你在搭建上花的时间更少你就能更快到达有趣的部分。你可以尝试更多想法。你可以让以前无法参与的人参与进来。这很重要。麻烦开始于人们期望某项特定进步能做超出它能力范围的事情。当承诺是这一次终于本质复杂性也会消失。这种期望往往导致一种特定的失望——工具被指责未能弥补一个它永远无法弥合的差距。6、Brooks真正说对的地方Brooks是精确的不是悲观的。他说的是软件的困难部分是软件本质所固有的。你会找到减少周围摩擦的方法。你找不到绕过核心困难的捷径。你必须穿过去。穿过去的方式和以前一样仔细思考问题小步构建诚实地面对你理解了什么和你还在猜测什么随着学习不断修正。这不是令人兴奋的建议。但它经受住了四十年的考验。7、不变的东西构建好软件的人往往已经与这一点和解了。他们不是在等待那个最终消除困难的东西。他们在变得更好的是穿越困难的能力。区分真正理解一个问题和只是觉得自己理解了那种特定的技能不来自更好的工具。它来自专注、犯错以及足够在乎去弄明白为什么。Brooks在所有技术论证之下指的就是类似这样的东西。软件的复杂性不仅存在于问题中还存在于导航它们所需的判断力中。而判断力是慢慢建立的。没有任何捷径改变过这一点。原文链接没有银弹从来就没有 - 汇智网
