PMF
Product Market Fit的简写，是指产品和市场达到最佳的契合点，你所提供的产品正好满足市场的需求，令客户满意，这是创业成功的第一步。
问题分层
- 用户问题（本源问题）
- 业务问题（经营视角）
- 产品问题（体系结构）
- 技术问题（架构代码）
KISS原则
架构的理念是大道至简：解决问题
- 如何让我们的系统有可扩展性和可维护性
- 如何让我们的系统能够恰到好处的解决问题
- 如何让我们的系统能够运行3-5年不重构
KISS表示的是什么？
KISS 是Keep It Stupid Simple 或 Keep It Simple,Stupid的缩写。
KISS的含义
该原则在我的多年的软件工程生涯中取得关键、巨大的成功。当今的软件工程师和开发者们有个共同的问题，那就是他们总是慢慢地使得问题复杂化。正确的做法应该是当开发者遇到一个问题后，把问题拆分成一个个能够明白的小块，然后进入编码阶段。但我会说，10个开发者中有8个或9个都没有把问题分解成足够小或可以理解的足够小的部分。这就导致了即使是一个非常简单的问题最后也变成了非常复杂的实现，另外一个副作用就是意大利面代码，在BASIC里只是一个goto语句的事情，在Java中却需要500到1000行代码，每个方法都有几百行代码。
你需要先想好问题的解决步骤一共分为几步，然后再进入编码。而不是拿到需求后，就开始一边写代码一边去满足需求。这样做的好处就是你的代码会变的足够容易理解和足够清晰。
我们能从KISS中获取到什么好处？
- 你可以更好地解决更多问题。
- 你将可以通过很少的几行代码去解决复杂的问题。
- 你将可以产出高质量的代码。
- 你将可以构建更大更易维护的系统。
- 当新的需求来了后，你的代码将会更加的灵活，易于扩展、易于修改和重构。
- 你将完成比你想象得更多的事情。
- 你将能够工作在一个大型开发团队和大型项目中，因为所有的代码都是stupid simple。
我如何把KISS原则用到我的工作中？
这里有几个简单的步骤可供执行，但有一定挑战。就像说起来的那么简单，keep it simple，主要是需要耐心，更多的靠你自己。
- 要谦虚，不要认为自己是个天才，这是你第一个误解。只有谦虚了，你才能真正达到超级天才的水平，即使不行，who cares！你的代码那么stupid simple，所以你不需要是个天才！
- 将你的任务分解为4-12小时的子任务。
- 把你的问题拆分成多个小问题。每个问题用一个或者很少的几个类来解决掉。
- 保持你的方法足够小，每个方法永远不要超过30-40行代码。每个方法都应该只处理一个小小的问题，不要搞太多uses case进去。如果你的方法中有多个分支，尝试把他们拆分成多个小的方法。这样不仅容易阅读和维护，找bug也更快。慢慢的你将学会爱。
- 让你的类也小点，原则和上面的方法是一样的。
- 先解决问题，然后开始编码。不要一边编码，一边解决问题。这样做也没什么错，但你有能力提前把事情切分成多个小的块，然后开始编码可能是比较好的。但也请你不要害怕一遍遍重构你的代码。另外行数还不是为了衡量质量的标准，只是有个基本的尺子而已。
- 不要害怕干掉代码。重构和重做是两个非常重要的方面。如果你遵循上面的建议，重写代码的数量将会最小化，如果你不遵循，那么代码很可能会被重写。
- 其他的任何场景，都请你尝试尽可能的简单，simple，这也是最难的一步，但一旦你拥有了它，你再回头看，就会说，之前的事情就是一坨屎。
什么是架构？
架构=组成+决策
组成=模块结果+模块关系
决策=约束+设计原则+演化方向
架构的目的
- 确定系统便捷，在技术层面上做与不做
- 确定系统里各个模块之间的依赖关系与模块的宏观输入与输出
- 使后续的子系统或模块设计在一个既定的框架内和技术方向上继续演化
- 明确非功能性需求，非功能性需求是指安全性、可用性、可扩展性等
时序图
随着时间关系对象之间的协作调用深度以及消息之间的返回。
关注正常流程
不关注逆流程、异常流程、分支判断
\
