共计 2172 个字符，预计需要花费 6 分钟才能阅读完成。
尽可能让一切变得简单，用最简单的方式完成工作
能用最少的概念，最精简易懂的概念模型来抽象系统，多一个概念就多一份别人了解系统以及维护系统的复杂度，别人也会质疑多一个概念的意义所在，自己如果没想清楚就容易被 diss。
特别是在类的设计中，会发现其实很多时候用一个类就可以表达要干的单一职责了，每个类职责清晰，类于类之间关系易于理解及维护。
设计系统时某些功能只在需要它时构建
对于这点深有体会，特别是在对设计此类系统没有业务经验的时候，不要尝试第一次就构建一个所谓“完美”系统，系统是要面向迭代的，永远都是随时准备修改或增加功能，所以设计系统的目标不在于追求一次性构建完美全面的功能，而在于追求系统对功能支持的扩展性，是否能具有快速 cover 新业务需求，从而分秒迭代自身的能力。
并且业务是多变的，设计时满足好当前的功能需求，并预留扩展点，即使目前功能不完备，也能在未来快速构建它。
没必要过度设计，特别是在自身经验不丰富的情况下，意淫的美好都是太自我，虽然多思考敢于尝试是好事情，但还是要找高手明确好要做的事情，否则对开发人力的浪费。开发暂时不需要的功能会导致最“重要且紧急”的需求 delay 或 bug 风险
敏捷迭代思维
先学会爬，然后再学会走，最后学会跑。换句话说，先保证能够正常运行，然后优化它使其更好，最后逐渐让它变得完美。为每个功能制定一个开发周期（最多 2 周），然后不断迭代。
注重投资回报率
工作中会发现任务都是排着队的，至于任务队列的 compare 方法怎么写，对于事情的四象限法则，事情的投资回报率是评估是否重要的重要考量。
功能的设计和测试尽可能独立。如果在设计时考虑到这一点，长远来看，它将省去很多麻烦，否则只有一切构建完成时你才可以开始测试整个系统。很多时候直到要测试某个功能的时候，才发现代码相互依赖，而无法独立测试某模块。
推行 MVP（最小可行产品）
该理念的核心在于：先制定一些用例，完成用例所涉及的相关功能，立即发布产品，然后根据反馈和经验对产品进行优化。
在需求评审阶段尽可能明确要做的事情，知悉 pm 需求的业务意义，才能更好更明确的带着目标做事情，技术评审阶段，尽量想清楚需求边界及所需的技术和业务资源来评估好开发时间，并乘以一个系数作为交付时间（主要是为后期突然插入的事情留 buffer），从项目生命周期开始，直到上线期间，和相关人员经常进行 关键步骤同步和确认，大家不会天天盯着你在做的事情，要主动同步进度，寻求反馈，可以避免方向走偏，同时方便对于领导也能掌控全局信息。
在多人协作过程中，流程规范化的意义，比如结论文档化，分支管理按照契约。大家都有了 common sense，办公效率也是极大提高。
试想微服务系统节点较少，俩人协作的时候，信息的沟通等价于最简单的的 Pub/Sub 模型，信息的传递较为简单，大家都会把对方同步给自己的事情处理好，甚至还闲着没事儿催促你好几遍，因为每个人只订阅对方的消息，来源单一，处理起来不会遗忘。后来的后来系统复杂了（同事多了），你作为生产者有了好多个消费者同事，比如你要改一个接口，涉及到好几个其他模块开发者，你推动这次升级需要每阶段都 push 各方同事这时候有个问题：
除了其它端，发现 支付端 也需要升级你的接口，然后屁颠屁颠跑人家那又巴拉巴拉描述如何升级——每个消费者接入，都需要生产者开发适配新消费者的消息发送代码。
学会解耦
别忘了工作中你本身作为生产者同时也在订阅别人，总之你作为一个节点，你的所有 peer 消息你都要处理，消息量大还处理不过来，容易遗漏。要么是 push 消息，要么是处理别人的消息，对于 push 别人的消息，你还要做好“降级”，因为你告诉别人这样做了，你确保不了别人一定按你说的做，消息一多这个时候人脑子会很容易乱的，别人如果做错了，如果不承认你给他 push 过消息怎么办？你要背锅嘛。。。
怎么办呢？引入业务消息中间件～
所以人多了就得学会解耦，每个模块都有人专门负责，模块间的沟通工作，需要一种协议来确保沟通准确性和解耦，上面说的是典型的同步 rpc 协议，意味着你要了解所有的消费者，还要处理新来的消费者，没有消息落盘，不可追溯。如果这个时候有一些文档或消息群来承载结论性的消息变更，大家都只需要跟踪这个文档或这个群就可以了，生产者就往里 push 消息，剩下的分布式消息处理一致性让别人来保证就可以了，哪一端没处理好，怪不了你了可。
首先不用处理对别方的降级，都按文档约定的来的，也同步给你了，对于新的消费者接入，看文档就好了。每个人就只需要 push 消息到文档落盘，订阅别人的文档 watch 变更，大量消息落盘，个人可以异步消费，而不会丢消息，落盘的消息可重复消费，可记录历史，避免沟通的扯皮，确保研发环节的有条不紊。当系统更大的时候，每个人工作消息模式复杂度保持不变，这也是 消息中间件 消息消峰 解耦的意义。
还没关注我的公众号？
- 扫文末二维码关注公众号【小强的进阶之路】可领取如下:
- 学习资料：1T 视频教程：涵盖 Javaweb 前后端教学视频、机器学习 / 人工智能教学视频、Linux 系统教程视频、雅思考试视频教程；
- 100 多本书：包含 C /C++、Java、Python 三门编程语言的经典必看图书、LeetCode 题解大全；
- 软件工具：几乎包括你在编程道路上的可能会用到的大部分软件；
- 项目源码：20 个 JavaWeb 项目源码。
