给产品经理和开发经理的一封信:关于系统的灵活性设计

（中文用Google翻译翻译了下放在英文之后, 英文writing一直是我的短板, 大家凑合看吧…）

背景: 写这封信的时候我已经做好被卷入可能的政治斗争然后被挤兑走跑路的打算了。但是这些话我得说，在一个需要快速迭代开发的探索型部门，SDE才更要参与到决定“做与不做”, “做什么”的决策中去。原则性有关大局的问题要及早达成共识，才能塑造好的team环境和文化，而这其中最重要的，就是对flexibility的取舍。

There is no theoretical reason that anything is hard to change about software. If you pick any one aspect of software then you can make it easy to change, but we don’t know how to make every-thing easy to change. Making something easy to change makes the overall system a little more complex, and making everything easy to change makes the entire system very complex. Complexity is what makes software hard to change. —— Martin Fowler Who need Architect

It’s not only the dev team’s responsibility to make things flexible, our PM/TPM/SDMs also need to help:

• Please, stop telling SDE to make system flexible without deep talk to clearly tell them which direction you want the business to be flexible, please do review/guide them in business view in detail instead of say that very generic, and take responsibility for your flexibility domain decision; Please notice one wrong flexibility decision implemented in code can cause understand obstacle for the lifetime of the software, until it being refactor/deleted by responsible tech team to make things direct and clear, and that is not always happening, and that’s one of the reason why software corrupts.
• Please justify your flexibility idea works on concept/business model first, then ask SDE to build it, otherwise when SDE find implementation gap, and if they hesitate to contact you or could not find you, then they will just build that flexibility according to their understanding/expectation/prediction of business, and with very large possibility, it’s wrong.
• Please clearly tell them what flexibility is “we must have”, and what flexibility is “nice to have”, and what flexibility is “I personally think we may need”, to give them space to trade-off which “flexibility” to give way to the other “flexibility”, and to trade-off current goal, SDE resource, with this maybe unsure “flexibility”
• Please allow them to do things more direct/simple (even as simply as seems stupid) instead of putting more and more indirection/complex logic into the system, obscure our business model.
• Please understand we refactor our system is not purely due to we don’t do a good job to predicted future, or we made wrong decision where we should make better decision. But can also due to we don’t have enough information when we made those decisions. as we always don’t know “what we don’t know”. We can always make the system better tomorrow than today, that’s because tomorrow we will have more data/info to use; so please understand, it’s a will-to-learn team, instead of a incompetent team, will refactor the system continuously.
• Please tell dev team your intention instead of your solution/design, I understand sometimes this is hard to distinguish what is a solution and what is the intention and requirement, as a system design begins when customer have their requirement appear in their mind(then they ping related team what they want to do). But please try your best to separate what is the intention, with what is your solution. As only in this way, dev team can obtain what is essential problem we need to handle, capture the essential thing in domain model and build evolutionary architecture.
• Please understand dev team should do their job to separate technical concerns with business concern, allow delay critical tech decision, and flexible to change tech decision easily to support business change; but they are not the domain expert, who knows, e.g.:
• Those two things are similar things because in essential they are one same thing? or they are just accidentally similar, and different business force shall definitely drive them to diverge in future, so in future they should be different things;
• Those business rules in one domain has no problem to reuse in other domains.
• We really can invent a proxy here, so the difference of this business and that business can be hidden, and reuse.

Best dev team can make the business/concept model in PM/TPM/SDM’s mind clearly map to their code, so a little concept model change shall only lead to a little code change. However, they are not the correct guy to predict business and leave placeholder/abstraction/indirection for business; we understand the world, the env and our competitors are continuously changing, and we need to hug the change; however, we should make the system evolutionary to react to change, instead of adding complex flexibility based on the totally unreliable prediction; and this is why we want to apply Agile process to the team, and learn as much as possible, as quickly as possible(no matter it’s domain knowledge or new tech skills), refactor instead of predict/predesign the system, right?

========基于Google翻译修改的翻译,文理不通的话都是Google翻译的锅=========

让一个系统灵活可变，不仅仅是开发团队的责任，我们的PM / TPM / SDM也需要提供极大的帮助和担当起应有的责任。

• 请不要在没有深入讨论细节的情况下，告诉SDE一定要使系统灵活，请明确告诉他们您希望业务灵活的方向，您希望那里业务能够灵活，请用你们的业务视角来详细指导他们，而不是说的非常抽象和high level。而且请您能够对这个业务上的灵活性决策负责; 因为请注意在代码中实现的一个错误的灵活性决策可能会导致整个系统，在整个软件生命周期里的复杂度上升，直到它被有责任心的技术团队重构/删除，才能让逻辑简单直接和明了起来，然而这并不是总会发生的事情，所以大量的造成理解困难的错误灵活性往往决定会残存在系统里，这也就是为什么软件会腐坏的重要原因之一。
• 请首先证明您的灵活性想法适用于概念模型/业务模型，然后再让SDE构建它，否则当SDE发现有些逻辑无法实现(比如逻辑相互冲突或者某些情况没有被业务模型cover)，如果他们比较忧郁去联系您或找不到您，那么他们很可能将根据他们对业务的理解/期望/预测来对系统进行修改和建造，而他们的业务判断有非常大的可能性是错误的。
• 请明确告诉他们，哪些是“必要的灵活性”，哪些是“能有最好的灵活性”，以及​​哪些是“PM您个人认为我们可能需要”的灵活性，这样可以给予他们空间来权衡哪种“灵活性”需要让位于另一个“灵活性”，从而使得他们可以在当前目标，SDE资源，和这可能不确定“灵活性”中进行取舍。
• 请允许他们更直接/更简单地做事（即使看起来很愚蠢），而不是将越来越多的间接/复杂逻辑放入系统，这会掩盖我们的业务模型，混淆清晰的Domain Model。
• 请理解我们SDE重构我们的系统，并不纯粹是因为我们没有做好预测未来的工作，或者由于技术不足，使得在我们应该做出更好的决策的时候做出了错误的决定。但也可能是因为我们做出这些决定时我们还没有足够的信息。因为我们总是不知道“我们不知道什么”。我们总能在“明天”作出比“今天”更好的决定，因为“明天”我们将有更多的数据/信息可供使用; 所以请理解，一个不断重构系统的团队是一个愿意持续学习进化的团队，而不是一个无能的团队。
• 请告诉开发团队您的意图而不是您自己理解的解决方案/设计，我理解我们有时很难区分什么是解决方案，什么是意图和要求，因为系统设计在客户的需求出现在他们的脑海中就他们自己就已经开始设计了（然后他们会告诉我们想做的事情而不是他们的真正需求）。但请尽量将本质意图与您自己理解的解决方案分开。这样开发团队才能更本质的把握业务问题，按照业务的骨架搭建可进化的系统构架。
• 请理解开发团队能做到的灵活性是将技术问题与业务问题分开，允许延迟关键技术决策，并灵活地轻松更改技术决策以支持业务变更; 但他们不是领域专家，他们很难对业务灵活性进行决策，他们很难知道，例如：
  1、 有两件事情是相似的，那因为在业务本质上它们是同一个东西？还是因为他们只是偶然相似，那么不同的业务力量肯定会使他们在未来发生分歧，所以将来它们必然是不同的东西;
  2、 哪些业务逻辑可以在其他领域中重用，而没有任何问题。
  3、 我们真的可以在这里对业务逻辑抽象，从而对我们所目前理解的高层业务隐藏这些业务逻辑的不同么？

最好的开发团队可以使PM/TPM/SDM的脑海中的业务/概念模型清晰地映射到他们的代码上，因此一点概念模型上的小更改，只会导致一些代码上的小改动。然而, 他们不是能够预测业务发展，从而为未来的业务变化在code里预留逻辑/抽象/indirection的正确人选; 然而我们理解世界在变化，环境和竞争对手也都在变化，所以我们也要拥抱变化获得成功；但是，我们应该让系统进化来应对变化，而不是尝试去依赖靠不住的预测来对系统预先按我们猜测的方向加入flexibility，这就是为什么我们希望将敏捷发开应用于团队，并尽可能快地从实践中学习，通过每天不断获得的新数据，信息和知识(不管是domain的还是技术的)来重构系统，而不是预测/预先设计系统，对么？