简介
最开始，只是一个简单的需求，然后基于简单的需求实现了一个系统。然后不停的开始加小功能，尤其是需求方来自不同的人员的时候，无目的的扩充，会让系统逐步变得很臃肿、零散，中间还往往伴随着 项目负责人的变动，代码风格的不一致等。
项目的演化有两个方向
- 广度，觉得系统不错，让它承担更大的职责边界。 尤其要警惕跟系统功能很类似，但本质不是一个东西的需求
-
深度
- 更高性能，数据更全，界面更友好等
- 项目的各个要素 从特定 变成灵活配置。不仅 项目的职责边界 会变化，某个要素的意涵 与项目设计之初也可能会有所不同。
- 在设计一个系统时，必须描述清楚项目的边界和假设。一旦新功能跨了边界，最好是重新设计，而不是很丑陋的兼容实现。 另一个方面，加功能的时候通常只是立足于功能本身，而没有从全局视角来调配问题。辽沈战役中，有一个阻击阵地失守了，连长想夺回阵地再汇报。最后，所属团长撤职，连长枪毙。
- 项目必须周期性的调整，基于变化，调整项目的边界。评价项目是否应该重构（以及重构方案的好坏）的重要标准是：项目当前状态与理想状态的差距。
项目本身会腐化、臃肿，越来越多的老代码、历史遗留，最后应对问题的时候越来越力不从心，就好像一个王朝的末期，军事失败只是表象，组织、经济能力失灵才是本质。
一个项目问题的解决是分层次的，比如分布式事务问题：
- 可以业务需求、架构层干脆避免分布式事务
- 也可以应用层使用相关框架 + 设计解决
- 也可以干脆使用大容量或分布式数据库，即在数据库层面上解决。
解决问题时，通常并不是单纯解决问题本身就够了，还要符合整个系统一贯的思路。
一个项目 ，若是长时间不管，不精心培育，关键时刻是顶不住的
项目的发展离不开需求的完备性，但需求是一波波的，不是一个线性的过程。
项目需求变化 ==> 实现方式变化 ==> 使用方式变化 对项目的挑战很大，比如k8s为什么会赢？后Kubernetes时代，2019的容器技术生态会发生些什么？不同于一个只能生产资源的集群管理工具，Kubernetes 项目最大的价值，乃在于它从一开始就提倡的声明式 API 和以此为基础“控制器”模式。Kubernetes 项目为使用者提供了宝贵的 API 可扩展能力和良好的 API 编程范式，催生出了一个完全基于 Kubernetes API 构建出来的上层应用服务生态。可以说，正是这个生态的逐步完善与日趋成熟，才确立了 Kubernetes 项目如今在云平台领域牢不可破的领导地位，也间接宣告了竞品方案的边缘化。
无论如何演化，每个项目都有一个内核
笔者曾经负责过两个项目：配置中心和api管理
- 配置中心，一个配置管理系统，app 启动时访问该系统，拉取适配app的所有配置。进而支持运营通过更改配置 来操控 app的行为
- api管理，类似swagger，服务端项目开发完毕后，录入接口，供前端/客户端使用，进而支持apimock等功能，支持前后端并行化开发
两种思维方式
- ”归纳整理法“。常规的设计系统的流程：研究业界已有系统，提炼抽象，该系统有几个基本概念，每个概念有几种实现方式，然后整理归纳，判断取舍，制定详细设计方案。从这个视角来看，配置中心 和 api管理 是两个完全不一样的系统。”归纳整理法“ 说白了是从众心理，体现在生活上就是这事儿别人做了，所以我也要做。
- “核心扩展法”，说白了是第一性原理在系统设计的体现。配置中心有项目、分组、配置、发布等概念，api 管理有项目、模块、api、mock 等概念。换个表达方式：api管理首先是做接口管理的，然后因为接口不能平铺在那里，所以从组织方式上有模块管理和项目管理。接口是人操作的，所以有权限管理，然后围绕接口有api mock 等。 从这个角度看，api 和 配置中心是一样一样的，url 类似配置中心的一个个配置。
我们为什么要争辩两个思维方式的差异，就是因为常规的”整理归纳“的思维方式，无法帮助你在一些具体的问题上做决策，你最多知道一个具体的特性在你调研的案例里有几个实现了，有几个没实现，这个问题在”核心扩展法“思维下就很好决策，既然项目都有一个内核， 那么项目迭代的过程中，一定要关注对内核的影响。比如当你去看业界主流的api 管理系统实现时，不能被外在的项目公有/私有，是否支持模块 等这些细节所迷惑，它的核心是做api 管理，其它一切都是围绕接口管理进行的。你向别人介绍自己的项目时，也应该先从接口管理入手，这是要点，然后才是其它”支持“功能。
时刻保持优雅，而不是修修补补成大泥球
业绩增长常会稀释人才密度，当业务复杂度往上快速增长时，公司高绩效人才的占比是下降的，两者会出现一个交叉点。当交叉点出现时，你会发现以前的那套流程已经不适用了，混乱和错误开始出现，产品迭代速度会受到严重制约。在这个人才密度上，业务已经变得太过复杂，而系统不可能再以往常的形态运行。
需要完善团队人才梯队，使人才密度的提升超过业务复杂度增长。
项目管理
做产品想“多快好省”都占着，是不可能的，最多只能选两样。因为软件工程的目标就是要构建和维护高质量的软件，“质量”这个因素一般不会妥协。PS：与分布式CAP异曲同工之妙
固定一条边很重要：从时间、成本和范围这三条边中找出来固定的一条或者两条边，再去调整另一条边。
“不可能三角”是道的层面，应用在“术”的层面：
- 老板要压缩工期，则应减少产品范围和加大成本（投入更多人力）。
- 产品经理要临时加需求，则要么延期要么加人。
- 这些年流行的 MVP（（minimum viable product，最小化的可行性产品）模式，是一种快速推出产品的模式：一开始只推出最核心的功能，满足用户最核心的需求，然后在用户的使用过程中收集反馈，进一步升级迭代，快速试错。
这个世界上有好多事情，看着像可以任意发挥， 但又不能任意发挥， 那么这个边界在哪里？就到你要摸索每个问题域的本质。
《软件架构设计》：对于项目管理，有一个关键问题要面对：“不确定性”问题。从人的认知来讲，做任何事情，思路都是从一个“朦胧”到逐步“清晰”的过程，项目的进展也是一个从思路、到方案、到落地的细化过程。在这个过程中， 不可避免存在“不确定”，比如需求变化、新技术生疏、核心人员离职、与其它部门协调、历史遗留等，项目管理就是要提前防范各种不确定性。