2 A tale of two values

每个软件系统提供两个不同的价值：行为和结构。开发者有责任确保这两个价值一直高，遗憾的是，他们常常只关注其中一个，而完全忽略另一个。更遗憾的是，他们往往关注的是两者中价值更低的那个，最终导致软件系统变得毫无价值

行为

软件中的第一个价值就是行为，股东雇佣开发者让机器对他们来说表现地更省钱，我们通过帮助股东明确具体需求，或者写需求文件然后写code来满足这些需求。
然后机器可能不满足这些需求，开发者来debug然后修改这些问题。
很多开发者坚定地认为这就是他们整体的工作，他们认为工作就是开发需求然后修改bug，但是这是错的。

架构

软件的第二重价值，就藏在 software 这个词本身里 —— 它是由 soft（柔软 / 可灵活改变）和 ware（制品 / 产品）组成的复合词。ware 意思是 “产品”；而 soft…… 正是第二重价值的所在。
软件被创造出来，就是为了 **“软”。
它的初衷，就是让机器的行为能够被轻松地改变 **。如果我们希望机器的行为难以修改，那本该叫它 hardware（硬件）。
要实现它的使命，软件必须柔软—— 也就是说，必须易于修改。当利益相关方对某个功能改变想法时，这项修改应该简单易行。修改的难度，应该只与修改的范围成正比，而不取决于系统的结构形态。
正是范围与结构形态之间的这种差异，常常导致软件开发成本飙升。这就是为什么成本增长会远超需求变更的规模。这也是为什么第一年开发很便宜，第二年更贵，第三年贵得离谱。
从利益相关方的角度看，他们只是提出了一系列范围大致相当的需求变更。但从开发者的角度看，他们拿到的是一连串拼图碎片，必须塞进一个复杂度不断攀升的拼图里。每一个新需求，都比上一个更难嵌入，因为系统的结构形态与需求的形态不匹配。
我这里用的 shape（形态 / 结构） 并非传统术语，但我认为这个比喻很贴切。软件开发人员常常感觉自己在强行把方榫头塞进圆卯眼。
问题的根源，当然是系统架构。架构越是偏向某一种固定形态，排斥其他形态，新功能就越难融入这个结构。
因此，好的架构在实践中应该尽可能做到 “形态无关”（shape‑agnostic）。

价值

功能还是架构？这两者哪个价值更大？软件系统是能跑起来更重要，还是容易修改更重要？
如果你去问业务管理者，他们通常会说：系统能正常运行更重要。开发者也往往附和这种观点，但这个观点是错的。我可以用一个简单的逻辑 ——极端反证法，证明它是错的：
如果你给我一个运行完美，但完全无法修改的程序，那么当需求一变，它就不能用了，而我也改不动。最终，这个程序会变得毫无用处。
如果你给我一个暂时不能完美运行，但极易修改的程序，那我可以把它改到能用，并且在需求变化时一直保持可用。因此，这个程序会持续有用。
你可能觉得这个论证不够有说服力。毕竟，不存在完全不能改的程序。但是，确实有很多系统在现实中几乎改不动—— 因为修改的成本远超收益。很多系统在某些功能或配置上，已经到了这个地步。
如果你问业务管理者：“你们想不想以后能方便地改需求？”他们会说：当然想。但紧接着又会补充：当前能用，比以后灵活更重要。
可反过来，一旦业务管理者提一个变更，而你给出的预估成本高到他们无法接受时，他们又会暴怒，质问你：为什么当初要把系统做成现在这样，连个简单改动都做不了？

为架构而战

要履行这份责任，就意味着要主动去争取、去抗争—— 或许用 “博弈” 更恰当。
坦白说，事情向来如此。研发团队必须为他们认为对公司最有利的方案去争取，管理层、市场团队、销售团队、运维团队也一样。凡事都需要博弈。
高效的研发团队会直面这种博弈。他们会以平等的姿态，坦然地与所有利益相关方讨论、争辩。
记住：作为软件开发人员，你本身就是利益相关方（stakeholder）。你对自己开发的软件负有守护责任，这是你角色的一部分，也是你的职责。这也是公司雇佣你的重要原因之一。
如果你是软件架构师，这份责任就加倍重要。根据岗位职责，架构师理应更关注系统结构，而非单纯的功能与特性。架构师的工作，是设计出能让各类功能易于开发、易于修改、易于扩展的架构。
请一定记住：如果架构被放到最后考虑，系统的开发成本会越来越高，最终部分甚至整个系统将几乎无法修改。如果出现这种局面，就说明研发团队没有为他们明知必要的架构据理力争。