未来值得关注的方向
Serverless
无服务器架构是基于互联网的系统，它的应用开发不使用常规的服务进程。相反，它仅依赖于第三方服务（例如 AWS Lambda 服务），是客户端逻辑和服务托管远程过程调用的组合
什么是Serverless
Service Mesh
Service Mesh是用于处理服务到服务通信的专用基础架构层。Cloud Native有着复杂的服务拓扑，它负责可靠地传递请求。实际上，Service Mesh 通常作为一组轻量级网络代理实现，这些代理与应用程序代码部署在一起，应用程序无感知。随着Cloud Native的崛起，Service Mesh逐步发展为一个独立的基础设施层。在Cloud Native架构下，单个应用程序可能由数百个服务组成；每个服务可能有数千个实例；并且这些实例中的每一个实例都可能处于不断变化的状态，因为它们是由诸如Kubernetes之类的资源调度系统动态调度的。这个世界中的服务通信不仅非常复杂，而且是运行时行为的普遍和基本部分，管理它对于确保端到端的性能和可靠性至关重要。
什么是Service Mesh
研发流程
十二因子
基准代码
一份基准代码，多份部署
使用 GIT 或者 SVN 管理代码，并且有明确的版本信息
依赖
显式声明依赖关系。
如Java中我们可以使用Maven或者Gradle管理依赖包
配置
在环境中存储配置
第一，可以将应用的配置存储于环境变量中；第二，可以将应用的配置存储于分布式配置中心。
后端服务
把后端服务当作附加资源
构建、发布、运行
严格分离构建和运行
十二因子强调通过CI/CD（持续集成/持续布置）工具实现整个过程，例如使用Jenkins。
进程
以一个或多个无状态进程运行应用
端口绑定
通过端口绑定提供服务
并发
通过进程模型进行扩展
易处理
快速启动和优雅终止可最大化健壮性
开发环境与线上环境等价
尽可能保持开发、预发布、线上环境相同
日志
把日志当作事件流
管理进程
把后台管理任务当作一次性进程运行
Code Review的意义
Code Review，顾名思义，就是针对一名开发人员完成的代码，让团队其他开发人员检查的过程。很多公司都在开展 Code Review，但是绝大多数公司只是流于形式，并没有形成一种文化。Code Review更多依靠的是小团队的工匠精神和程序员个人的主观能动性
Code Review的原则
以发现问题为目标
不设置惩罚 而应该采用正向激励的做法
不论资历
Code Review的过程
利用工具 线上+线下结合
代码即设计
架构设计包含两方面，一是架构，二是设计。在敏捷开发中，架构并没有被抛弃，架构的思考可能发生在你理解需求的过程中，也可能来自你的经验；架构的结果可能是一个白板上简单的图，也可能需要详细调研，这与架构师的能力有关。设计需要耗费大量的时间和精力去做，设计会转移、分配到整个研发流程。
整个进化设计需要简单的架构+持续集成+重构+整个研发流程的设计来保证。
敏捷研发流程模糊阶段性的理由是：业务需求太多和技术变化速度太快。
这种设计上的转变实际上非常适合小规模、有强大战斗力的团队
团队文化
高效的会议
缩小会议范围
常规会议不应该超过45分钟
限制“意见领袖”的发言时长
提供平等的会议氛围
会议中的分歧不应该延伸到会议之外
如何留下你想要的人
充分沟通
给予尊重
肯定工作成绩
设定合适的岗位
设定更大的挑战
关注公众号 获取更多精彩内容