talk of software engineer

1. 现代软件工程杂谈
Larry Cai

2.  工作：探索软件开发的最好最适合的方法和
工具。
 一个开源，协作和敏捷的布道者。
› 微博：@larrycaiyu
› 博客：http://larrycaiyu.com
› Email：larry.caiyu(at)gmail.com
› Github: http://github.com/larrycai

3. 提纲
 软件工程的现状要点
 公司实施现状和特点（过去和现在
）
 流程：敏捷/精益、Scrum
 持续集成: Jenkins
 版本控制： git， artifactory
 代码质量：代码审阅、Gerrit
 基础设施：云openstack、docker
 需求： ATDD
 总结

4. 探讨的问题
 敏捷已死，现在不讲敏捷了？
 代码审查是为了保证质量，再多时间也是
应该的？
 需求都是产品经理的事，程序员都是螺丝
钉？
 只有源代码才需要版本控制？
 持续集成是啥？
 Docker看起来不错，和软件工程有关系吗
？
软件工程非常不枯燥，越来越有味道

5. 软件工程现状要点
 敏捷是软件工程的支撑，保证软件开发的改进的方向
和重点
 持续集成和持续交付是整个端到端的开发潮流，它不
断提供各级反馈来提高开发质量和效率，它涵盖了软
件工程的大部分领域
 完备的基础设施支撑自动化和管理
 技术不断的进步会不断的推动各级的进步
技术的发展使得各项软件实践加速发展，使得软件工
程所需要的交付质量可控，自动化。

6. 流程：敏捷、精益
 ISO、CMM
 2001 ： XP、轻量级
 敏捷：团队、组织到整个公司
 精益：浪费，端到端
 Scrum：框架，快速
 帮助组织有秩序有纪律前进
 理解和贯彻：难
Image Source:
http://www.123greetings.com/events/doctors_day/surgery_for_dummies.html

7. 企业中的敏捷框架
Source：http://ScaledAgileFramework.com

8. “How long would it take your organization to deploy
a change [to the production] that involved just one
single line of code?
Do you do this on a repeatable, reliable basis? ”
Mary and Tom Poppendieck,
Implementing Lean Software Development
精益

9. Scrum
Image source: www.mountaingoatsoftware.com/scrum

10. 误区
 站立会议（daily standup meeting ）
 白板（电子白板）
 自组织（任务，估时间）
 文档要不要
 Scrum就是敏捷吗
 CSM （ScrumMaster认证）
 团队敏捷到组织敏捷
 现状：敏捷暴露问题，没有很懂的人，实施是不断沟
通和循序渐进的过程，难。

11. 持续集成、持续交互
 持续集成和持续交付是整个端到端的开发潮流，它不
断提供各级反馈来提高开发质量和效率，它涵盖了软
件工程的大部分领域
 企业软件开发的核心
 使用Jenkins

12. 持续集成
代码审阅
code push
FFaasstt BBuuiilldd
• Compile
• Unit test
Git/Gerrit
notification
Compile/Build
• Compile
• Unit test
•Quality check
~ 10 min
Packaging
•jar
• rpm
•iso
~ 20 min
Function Test
Function Test
•Smoke test
•Fast test
•Complete test
•Smoke test
•Fast test
•Complete test
~ 4 hours
~ 4 hours
System Testing
System Testing
- weekend
• characters
• stability
~ 1-2 days
- weekend
• characters
• stability
~ 1-2 days
Installation
• iso
•Upgrade
•Uninstall first
~ 30 min
Production
•DemoLab
•Design Env
Production
•DemoLab
•Design Env
•Cloud
•Cloud
持续集成
源代码
Git/Gerrit
测试源代码
二进制构件
3pp
Repository
Package
Repository
Tool
Repository
发布
SSoonnaarr
TTeestsitningg r ereppoortrt
BBuuilidldiningg r ereppoortrt
DDaashshbbooaardrd
反馈系统

13. 及时的反馈系统
 为什么这么多古怪的界面？
Source:
https://github.com/edgeware/dashboard

14. 互联网云中的持续集成
 Travis-CI: 基于Virtualbox
 启动虚拟机
 下载代码库
 执行配置，运行构建
 销毁虚拟机
 Drone.io: 基于docker
简单的配置文件 .travis.yml

15. 版本控制
 企业有审计和安全的需要
 CM：配置管理工程师
 早期：
RCS，CVS、Subversion （SVN）、ClearCase
 现在：分布式 Git （Mercurial很少）
 源代码和二进制构件（artifacts）版本控制
=》Infrastructure as Code
 不是限制，是帮助。

16. Git workflow
 更多的协作方式（分布式）
 更加友好（本地历史）

17. 二进制构件版本控制
 Jenkins服务器
 文件服务器、WEB界面
 专用的二进制构件（ Artifactory、Nexus）
（ npm/pypi/jar…)

18. 二进制构件的提升
 二进制构件的提升（ Promotion）：可以在不同的仓
库中被挪动、拷贝而保留原始信息
 重要的生命周期的管理

19. 代码质量控制
 单元测试：xUnit/TDD
 静态代码检测：lint、Klockwork 、Clover
 代码审阅：Gerrit/Github
 质量反馈：Sonar
 功能测试：ATDD、Selenium、Sikuli
 是帮助，不是目标、KPI
Image Source http://www.sikuli.org/

20. 代码质量

21. 代码审阅的策略
代码变化
自动化测试审阅
减少浪费，只做有意义的事

22. Gerrit基本流程
commit
Local
Repository
Local working space
Working
Directory
Gerrit
Code review
system
Remote
repository
gitgit
Gerrit 服务器
提交代码
2
Review Team
3
1
pull
Sync
5
Merge to master
4
Code Review: +2
CI System
3
Verify: +1
4

23. Github pull request
 开源软件在Github怎么工作
 提交Issues
 fork代码库
 修改测试通过
 Pull request
 合并（作者）

24. 基础设施Infrastructure
 完备的基础设施支撑自动化和管理
 变化：物理机->虚拟机->云服务->Docker容器
 更快更灵活带来更多的策略
Image source ： http://www.itrus.com/infrastructure_design.html

25. Node List (A,B,C)
IaaS
Node VM conf
(OpenStack)
(image name, flavor)
Cloud Conf (API) 1. 启动VMs
OOppeennSStatacckk
Package repo
Installation tools
repo
Test Case
repo
二进制构件库
Git
Git
Source code
Git
Installation code
Git
Test case code
源代码库
vm
A
IaaS
(OpenStack)
VM Images
(OS/Base 3pp)
VM information
VM A: 192.0.1.1
VM B: 192.0.1.2
VM C: 192.0.1.3
….
2. 安装最新APP
(DB, Apache/Tomcat)
vm
B
..
vm
A
vm
B
OOppeennSStatacckk
..
vm
A
vm
B
OOppeennSStatacckk
..
3. 功能测试
OOppeennSStatacckk
4. 产生报告
删除VM
云O
penstack
不同产品特性不同用法

26. Docker介绍
 Docker是一种Linux容器工具集，它是为“构建
（build）、交付（ship）和运行（run）”分布式应
用而设计的。
http://www.slideshare.net/dotCloud/solomon-hykes-dockercon-keynote

27. Docker带来的变化
› 持续集成自动产生docker镜像
› 开发团队Pull安装好的docker镜像，直接验证和测试
› 将来：docker镜像直接交付给客户
Docker
Registry
Server
Docker
Registry
Server
Source Code
(Gerrit)
Source Code
(Gerrit)
compile/verify
install/build
push
AAPPP:P1:51a5a
AAPPP:P2:021041049029828
AAPPP:Pte:tlesltsrtar1a010
pull
关注 http://www.infoq.com/cn/dockers

28. 需求
需求是软件开发中最重要的事，但总是做错

29. 验收驱动测试（ATDD）
 需求是最容易瀑
布式的！！
 验收驱动测试环
路
Image source
http://www.slideshare.net/hujak/javacro14-test-automation-using-robotframework-
libraries-stojan-peshov 第8页

30. 实例化需求
 实例化需求（specification by example ）是验收驱动测
试的一种
 还有业务驱动开发、可执行的需求
 特点：
 用例子（自然语言）来描述需求，在归纳成特性
 需求是用来沟通的
 可以用Cucumber语言来实现

31. Cucumber工具实现

32. 总结
 云使得资源利用更有效，测试更充分，持续集成效率更高
 Docker容器化技术使得测试更易本地化，应用交付更方便
 分布式版本控制使得协作更简便，代码审阅简单化
 实例化需求使得测试更加贴近业务，使得交流更通畅，质量更好
技术的发展使得各项软件实践加速发展，使得软件工
程所需要的交付质量可控，自动化。

33. 推荐书目

34. 建议 & 问题
多写代码，参加开源软件的开发！
 微博：@larrycaiyu
 博客：http://larrycaiyu.com
 Email：larry.caiyu(at)gmail.com
 Github: http://github.com/larrycai