巴克云 范飞龙 软件开发中的碎片问题

CodeWarrior

2019/07/08 发布于 编程 分类

GIAC2019 

文字内容
1. 软件开发中的碎片化问题 范飞龙 巴克云 高级软件工程师
3. 范飞龙 / 幻灰龙 2003-2012,厦门大学,计算数学博士 2013-2016,迅雷网络,P2P网络协议构架师 2016,深圳巴克云网络科技有限公司,高级软件工程师 2015,参与《构建之法》与高校软件工程课程的线上线下结合的教学,担任过1年线上助教, 持续4年参与社区构建。 fanfeilong@gmail.com http://www.cnblogs.com/math
4. 问题和思路 问题:软件开发中存在各种碎片问题 分析:软件=程序+软件工程 思路:如果可以,用经过设计的程序自动化地解决 否则,再考虑软件工程中人的部分 开发 部署 测试 发布 团队
5. 内容 1. 2. 3. 4. 5. 6. 7. 8. 非IDE环境下的项目管理 项目中的脚本地狱 分布式系统的测试 开发中的文档问题 项目中的ISSUE管理 自动化构建 团队构建:能力+动机+饱和度 如何培训工程师
6. 一、 非IDE环境下的项目管理 • 非IDE环境下各种框架和脚本层出不穷 • 后端框架 • 前端框架 • 项目下充满了各种.xxxx配置
7. 痛点1:没有 解决方案->项目 的概念 • IDE中好的部分:宇宙最强IDE:Visual Studio • 解决方案 • 项目1(不同类型) • 项目2 • …
8. 分析:git 的启发 • 纯命令行操作,摆脱操作系统/语言平台依赖 • 文件系统+元数据,设计背后的数据模型 • 设计正交的原子操作,提供可组合的能力
10. 分析:基本需求/扩展需求 • 基本需求 • 命令行工具 • 内建工具账号 • 项目管理的三层数据模型: • 解决方案 • 项目(后端子项目/前端子项目) • 包 • 针对三层数据模型的原子操作 • 初始化/创建/添加/删除/配置/编译/生成测试/部署… • 扩展功能: • 对各种工具链的支持
11. 分析:以Bucky平台(后端Serverless)为例 https://www.buckycloud.com
12. Server MySQL Cache PC/Mac/CLI/TV Cloud Storage iPhone Android iWatch 冰箱
13. 首先,我们来看下后台构架的发展: RDB RDB Cache DB Proxy Cache Cache Proxy RDB Processer Server Processer ngnix Processer ngnix RRDNS Client Client 第一代:C/S Client client client 第二代:LAMP client
14. Name Service(etcd/zookeeper) Sub Service3 RDB Scheduler Cache Sub Service2 RDB Cache Biz Sub Service1 RDB Cache Message Queue(Kafka)/RPC Biz Global Log Transaction Manager …… Biz GLB client LLB(LVS) nginx Gateway client sub interface client
15. 痛点2:折腾了好久才开始写业务代码! 如何像单机程序一样开发分布式程序呢? 新建项目 程序入口 添加类库 编译运行 发布更新 Hello World !
16. 迷你聊天程序 模块1(XARPackage) 模块2(XARPackage) 模块3(XARPackage) … 模块n(XARPackage) Runtime1 Runtime2 Runtime3 … RuntimeK Private Device Runtim e RDB BUS Repository Device2 Device1 Runtim e Runtim e Runtim e Cache BUS Scheduler RDB Knowledge Gateway Bucky Cloud Client1 Client2 Client3 Client4 Bucky SDK Bucky SDK Bucky SDK Bucky SDK App1 App1 App2 App3
17. 设计:bucky项目管理命令行工具 • 原子:设计一组针对解决方案/子项目的原子操作 • `bucky action` • actions: init/add/remove/cofig/compile/gentest/pub/start/stop… • 组合:设计一组复合指令 • build –local = compile+proxy • build = compile+proxy+stop+pub+start • 碎片问题: • 命令行查看文档不方便? • 本机Web文档: `bucky doc` • 命令行参数记不住? • 提供交互式询问参数模式 `bucky xxxx -i` • 命令行创建建新项目麻烦? • 提供内置的各种模版(类似IDE)
18. 考虑碎片问题:命令行查看帮助方便吗? bucky doc
19. 结构化的元数据是自动化的基础 解决方案配置(solution.json) App全局配置管理(knwoledges.json) MySQL Redis Mongo Event/Timer 前端子项目1(Vue) 后端代理(core) 前端页面 前端子项目2(React) 后端代理(core) 前端页面 后端子项目 后端模块1 后端模块2 后端模块的测试代码 测试后端模块1 测试后端模块2
20. 二、项目中的脚本地狱 • 项目的开发周期中,存在各种高频但非“核心”的脚本代码 • 配置/编译/打包/发布… • 问题: • 全局变量满天飞 • 路径随便拼接、没有函数封装的裸奔代码 • 无任何注释和文档...
21. 痛点:破窗效应 pub.sh pubGroup1.sh pubCI.sh pub.cmd pubCI.cmd clean.sh clean.cmd pubAndClean.cmd start.sh start.cmd stop.sh stop.cmd startAll.sh startCI.sh …
22. 分析:写“程序”而不是“脚本” • • • • 有不同的集群 每个集群有不同的分组服务 每个服务有pub、start、stop、clean操作 需要在windows/mac/Linux下操作 • 发布程序需要支持 • 选择集群 • 选择分组/单一服务 • 选择操作 • 跨平台
23. 设计: • 原子: • 针对单个服务的原子指令:`dev action` • actions: pub, start, stop, clean • 组合: • 可配置集群、配置分组服务 • 可选择集群、选择分组服务 进行操作 • 碎片问题: • 参数太多记不住 • 交互式询问参数: `dev xxxx -i` • 在CI系统上集成,提供便利的菜单支持 • 命令行自动完成 • 执行的命令到底做了什么? • 默认提供命令预览,只有添加` -e` 才会真正执行 • 误操作? • 线上系统需要输入密码才能执行。
24. 交互式询问参数模式 每次交互都输出当前 完整命令
25. 默认的命令预览模式
26. 命令行自动完成
27. 集成到CI系统
28. 三、 分布式系统的测试 • BuckyCloud是一个Serverless平台 • 本身是一个分布式的调度/执行系统 • 测试 • Serverless平台本身的各种微服务的测试。 • Serverless平台所调度的用户模块的测试。
29. 痛点:任何节点都可能是故障的源头 • 平台内部微服务之间的依赖链条 • 平台调度的用户模块之间的RPC链条
30. 分析1:全覆盖的单元测试成本高
31. 解决:递进集成测试 代码仓库服务 运行时容器 运行时容器 调度服务 设备服务 运行时容器 Client 端到平台 测试代码 调度服务 设备服务 运行时容器 调度服务 测试代码 代码仓库服 务测试代码 运行时容器 测试代码 设备服务 测试代码
33. 线上冒烟测试 + 测试集群压力测试
34. 分析2: 全链路分析 难点: 1. 如何区分同一个RPC接口的并发调用 2. 如何在并发的异步调用链之间串联日志 解决: 1. 使用调用链ID区分:CallChainID 2. 异步调用链的上下文,语言支持 / 语言不支持(半自动) Client Server Rintime3 call return Server Runtime2 call return Server Runtime2
35. 全链路日志定位 选择 AppID CallChainID,把一个调用跨Runtime的 日志串出来。
36. 后端模块测试代码的 自动生成 bucky gentest
37. 全本机测试的能力
38. 四、 开发中的文档问题 • 一个合格的项目,必须要有足够的文档 • 持续地维护 • 便利地使用
39. 分析1: 项目开发中如何维护文档 • 从项目的目录结构开始就应该重视 ├── README.md ├── doc └── src • doc目录下,最简化的保持3个重要的有用目录 • 需求分析 • 原型设计 • 项目配置 • 如何配置 • 如何构建 • 如何测试 • 如何执行…
40. 设计1:使用编号 常见痛点:文档文件名随意,文档内容随意 解决痛点:文件名编号+内容分节
41. 分析2: 优秀的项目如何编写对外文档
42. 设计2: 提供模版 + 一键生成 • • • • • • 介绍(Introduction) 快速开始(QuickStart, Helloworld, Getting Started...) 整体介绍(Common/Core/Basic Concept, Architecture, Understanding...) 开发手册(References) 示例(Examples) 知识库文章(Articles) • git clone https://github.com/fanfeilong/doc.git • npm install • node doc.js docs.starlab docs.starlab.io • 考虑碎片问题:不要让写文档费劲!
43. MarkDown编写 + 命令行生成
44. 五、 项目中的ISSUE管理 • 面向死亡编程 • 目标:如何让ISSUE快速死亡
45. 考虑碎片问题:为什么要让ISSUE快速死亡 • 让一个里程碑内的ISSUE总列表有节奏地消灭 • 逐步减少不确定性, • 让项目收敛。
46. 分析原因: • 无法完成的ISSUE • 有很多子步骤的大任务 • 描述模糊的任务 • 任何时候你都在“做”它,但它又确实没有“完成”。 • 重复打开的ISSUE • 按了葫芦起了瓢:被反复的ReOpen • 痛点:不够具体,没有重现,没有分离。
47. 具体:越小越具体越能短时完成的ISSUE越好 SMART原则—见《构建之法》 • • • • • Specific: 具体的,无二义性的。 Motivating: 目标明确。 Achievable: 可操作性强。 Relevant: 和项目相关 Trackable: 能衡量进度。
48. 重现:重现之后可能就是1-2行的修改 • 重复打开BUG原因1: • 没有正确的重现BUG,工程师过于自信,宣称修正了BUG • 解决:尽可能重现
49. 分离:单一指责原则 • 重复打开BUG的原因2: • 内容相关,但实际上是另外一种BUG。 • 解决:分离具体的子BUG
50. 六、 自动化构建 • 项目发版:Alpha/Beta/… • 下面这些动作依然存在大量的手工操作的现象,费时费力: • • • • • 打包 添加版本信息 上传到服务器 更新版本信息 更新网页信息
51. 解决:如何自动化? • 设计目录结构 • 文件 • 元数据 • 操作: • 配置元数据 • 工具自动打包
52. 文件/文件夹 配置 可编程模块
53. 七、能力+动机+饱和度 • 如何真正构建一个有共同价值观,各司其职,分工协作,为共同目标努力的团 队? • 例子: • Microsoft Solution Framework( MSF ): • http://www.cnblogs.com/xinz/archive/2011/11/21/2257663.html
54. 开放问题 1. 动机强+饱和度够,但是能力不够。 => 增加能力。 能力 2. 能力强+饱和度强,但是动机不强。 3 2 => 钱没给够/角色没给对。 4 动机 3. 能力强+动机强,但是没事可做。 => 团队安排不合理。 4. 动机强,能力强,饱和度够。 => 最佳位置,持续成长。 1 饱和度
55. 什么是饱和度 • 在一个项目中的角色:猪、鸡、鹦鹉,--《构建之法》 • 重要的决定交给猪来决定,要保证在一个项目里做猪 • 但是鸡和鹦鹉的角色要有机会获得锻炼和成长 • 希望获得哪些角色上的成长? • 一个项目里做猪就饱和了 • 一个项目里做猪,一个项目里做鸡 • 一个项目里做猪,一个项目里做鸡,一个项目里做鹦鹉 • 核心痛点:成就感/动机 问题。
56. 分析PM:Programmer/Product/Project • 谁是Programmer Manager: • 拥有实战构架/开发经验最强的人,自然担任 • 谁是Product Manager: • 拥有产品分析/设计能力的人 • 谁是Project Manager: • 在一次项目中做项目开发推进,项目对接控制,里程碑推进的人
57. 一种潜在的有效模式(6-10人): • 技术能力/视野最强的,自然担任Programmer Manager。 • 擅长产品分析/设计能力,Product Manager,少数。 • ProjectManager,一个持续有凝聚力,长期合作的团队,可在不同项目中,梯次 轮换ProjectManager。
58. • 项目之间有叠合期,每个项目的密集开发期,确立一个项目经理 • 一次项目进入维护期后,下一个项目可轮换一个人来锻炼项目经理角色 • 如果团队发展,成员扩充,经过锻炼的项目经理即可带队。
59. 八、 如何培训工程师 工程师成长之后 1. 我怎样培养更多的人才 2. 培养的过程中我怎么高效的工作
60. 重视三种核心能力 1. 编程语言 2. 数据结构与算法 3. 软件工程能力
61. 设计梯次进阶路径 1. 基础: • 个人项目 • 结对编程项目 2. 进阶: • 实战项目Alpha • 事后诸葛亮小结 • 实战项目Beta • 事后诸葛亮小结 3. 反馈: • 在每个阶段给予反馈 • 在每个阶段讨论软件工程的概念,做中学 • 针对具体技术的专场内部培训讲座 4. 共同成长: • 让工程师在不同环境下不断与人交流,获得成长
62. 小结 • • • • • • 重视整个软件开发周期中,各环节的碎片化问题 设计元数据,在模块化的基础上设计自动化工具。 通过自动化,极大的减少环节的心智负担成本。 重视成员在能力/动机/饱和度 三个方面的成长, 重视工程师的核心能力和梯次进阶路径。 在不同环境下与人打交道,不断成长
63. 欢迎关注msup微信公众账号 关注大会微信公共账号,及时了解大会动态、 日程及每日更新的案例! 关注公众号获得 更多案例实践