工作中一些原则体会

• 尽可能让一切变得简单，用最简单的方式完成工作
  能用最少的概念，最精简易懂的概念模型来抽象系统，多一个概念就多一份别人了解系统以及维护系统的复杂度，别人也会质疑多一个概念的意义所在，自己如果没想清楚就容易被diss。特别是在类的设计中，会发现其实很多时候用一个类就可以表达要干的单一职责了，每个类职责清晰，类于类之间关系易于理解及维护。

• 设计系统时某些功能只在需要它时构建
  对于这点深有体会， 特别是在对设计此类系统没有业务经验的时候，不要尝试第一次就构建一个所谓“完美”系统，系统是要面向迭代的，永远都是随时准备修改或增加功能，所以设计系统的目标不在于追求一次性构建完美全面的功能，而在于追求系统对功能支持的扩展性，是否能具有快速cover新业务需求，从而分秒迭代自身的能力。并且业务是多变的，设计时满足好当前的功能需求，并预留扩展点，即使目前功能不完备，也能在未来快速构建它。没必要过度设计，特别是在自身经验不丰富的情况下，意淫的美好都是太自我，虽然多思考敢于尝试是好事情，但还是要找高手明确好要做的事情，否则对开发人力的浪费。开发暂时不需要的功能会导致最“重要且紧急”的需求delay或bug风险

• 敏捷迭代思维
  先学会爬，然后再学会走，最后学会跑。换句话说，先保证能够正常运行，然后优化它使其更好，最后逐渐让它变得完美。为每个功能制定一个开发周期（最多2周），然后不断迭代。

• 注重投资回报率
  工作中会发现任务都是排着队的，至于任务队列的 compare方法怎么写，对于事情的四象限法则，事情的投资回报率是评估是否重要的重要考量。

• 功能的设计和测试尽可能独立。如果在设计时考虑到这一点，长远来看，它将省去很多麻烦，否则只有一切构建完成时你才可以开始测试整个系统。很多时候直到要测试某个功能的时候，才发现代码相互依赖，而无法独立测试某模块。

• 推行MVP（最小可行产品）
  该理念的核心在于：先制定一些用例，完成用例所涉及的相关功能，立即发布产品，然后根据反馈和经验对产品进行优化。

• 在需求评审阶段尽可能明确要做的事情，知悉pm需求的业务意义，才能更好更明确的带着目标做事情，技术评审阶段，尽量想清楚需求边界及所需的技术和业务资源来评估好开发时间，并乘以一个系数作为交付时间（主要是为后期突然插入的事情留buffer），
  从项目生命周期开始，直到上线期间，和相关人员经常进行 关键步骤同步和确认，大家不会天天盯着你在做的事情，要主动同步进度，寻求反馈，可以避免方向走偏，同时方便对于领导也能掌控全局信息。在多人协作过程中，流程规范化的意义，比如结论文档化，分支管理按照契约。大家都有了common sense，办公效率也是极大提高。试想微服务系统节点较少，俩人协作的时候，信息的沟通等价于最简单的的Pub／Sub模型，信息的传递较为简单，大家都会把对方同步给自己的事情处理好，甚至还闲着没事儿催促你好几遍，因为每个人只订阅对方的消息，来源单一，处理起来不会遗忘。后来的后来系统复杂了（同事多了），你作为生产者有了好多个消费者同事，比如你要改一个接口，涉及到好几个其他模块开发者，你推动这次升级需要每阶段都push各方同事这时候有两个问题：

• 除了其它端，发现 支付端 也需要升级你的接口，然后屁颠屁颠跑人家那又巴拉巴拉描述如何升级——每个消费者接入，都需要生产者开发适配新消费者的消息发送代码。

• 别忘了工作中你本身作为生产者同时也在订阅别人，总之你作为一个节点，你的所有peer消息你都要处理，消息量大还处理不过来，容易遗漏。要么是push消息，要么是处理别人的消息，对于push别人的消息，你还要做好“降级”，因为你告诉别人这样做了，你确保不了别人一定按你说的做，消息一多这个时候人脑子会很容易乱的，别人如果做错了，如果不承认你给他push过消息怎么办？你要背锅嘛。。。
  怎么办呢？ 引入业务消息中间件～
  所以人多了就得学会解耦，每个模块都有人专门负责，模块间的沟通工作，需要一种协议来确保沟通准确性和解耦，上面说的是典型的同步rpc协议，意味着你要了解所有的消费者，还要处理新来的消费者，没有消息落盘，不可追溯。如果这个时候有一些文档或消息群来承载结论性的消息变更，大家都只需要跟踪这个文档或这个群就可以了，生产者就往里push消息，剩下的分布式消息处理一致性让别人来保证就可以了，哪一端没处理好，怪不了你了可。首先不用处理对别方的降级，都按文档约定的来的，也同步给你了，对于新的消费者接入，看文档就好了。 每个人就只需要push消息到文档落盘，订阅别人的文档watch变更，大量消息落盘，个人可以异步消费，而不会丢消息，落盘的消息可重复消费，可记录历史，避免沟通的扯皮，确保研发环节的有条不紊。当系统更大的时候，每个人工作消息模式复杂度保持不变，这也是 消息中间件 消息消峰 解耦的意义