未来值得关注的方向

• 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分钟
  
• 限制“意见领袖”的发言时长
  
• 提供平等的会议氛围
  
• 会议中的分歧不应该延伸到会议之外

• 如何留下你想要的人

• 充分沟通
  
• 给予尊重
  
• 肯定工作成绩
  
• 设定合适的岗位
  
• 设定更大的挑战