本书详细阐述了如何在云计算时代利用高质量、轻量的开源软件Bugzilla，Kanboard，以及Git/Gitea进行软件的多人多地异步协同开发与维护。本书总结了以Pull Request为中心的多分支软件协作开发模型，并提出了与该模型配套的BKG工作流（Bugzilla-Kanboard-Git/Gitea Workflow）。本书立足实战，将软件工程的实践搬到云上，使得项目更新与知识共享触手可及，使云软件工程的概念得以落地。本书强调了搭建云基础设施以保障软件的持续改进。为了帮助读者更好地掌握我们的开发模型与工作流，本书配套了3个自己开发的完整网页应用程序。读者可以克隆所有程序的代码仓库。我们鼓励读者在自己的电脑上运行这些程序，发现缺陷，修复缺陷，提出改进意见，并提交补丁。

蓝珲，博士，2016 年 06 月- 2017 年 07 月英国剑桥大学塞恩斯伯里实验室（SLCU）博士后 （Research Associate）；2017 年 08 月-至今浙江师范大学教师。著作方向：软件工程、软件项目管理。所承担过的重点科研或教研项目：NSERC 项目《Combining classifiers to predict gene function in Arabidopsis thaliana using large-scale gene expression measurements》项目主要参与人，负责编写程序。NSERC Discovery项目《Genome-wide network model capturing seed germination reveals coordinated regulation of plant cellular phase transitions》项目主要参与人，负责编写程序。Gatsby Foundation项目《The evening complex coordinates environmental and endogenous signals in Arabidopsis》重要参与人，负责编写程序。浙江师范大学2020年校级重点建设教材项目《云软件工程Cloud Software Engineering》负责人。浙江师范大学数学与计算机科学学院2020年研究生课程、教材、教学改革案例建设项目《Lab Report Repository的开发、维护、Bug报告修复与持续改进》负责人。浙江师范大学数学与计算机科学学院2020年本科课程、教材、教学改革案例建设项目《云软件工程 Cloud Software Engineering》第一负责人。浙江师范大学数学与计算机科学学院2020年本科课程、教材、教学改革案例建设项目《软件工程基础》第二负责人。所从事的主要科研与教学工作及获奖情况：所发表论文总引用数超过300次（Web of Science数据）。Cambridge Network Day （2017年） Poster 一等奖。浙江师范大学第一届教师教学创新大赛（2021年）三等奖。

Contents
Chapter 1 People’s Accountability 1
1.1 Responsibility card 2
1.2 Code ownership 4
1.3 The produce-review cycle 4
1.4 The indifferent customer 5
Chapter 2 Building Teams 6
2.1 Stating vision 6
2.2 Starting small 6
2.3 Characteristics of a quality software engineer 7
2.4 Software health 7
2.5 Being honest about development status 8
2.6 Treasuring old code 8
2.7 Meeting 8
2.8 Who makes the final decision? 9
2.9 Bus factor 9
2.10 Joel test 10
2.11 Evaluating team quality from four aspects 11
2.12 Measuring productivity 12
2.13 Training and employee retention rate 12
2.14 Improving software process 13
2.15 Data and statistics 13
2.16 Territory 13
2.17 Code review 13
2.17.1 Pull request 14
2.17.2 Code review plus edit 16
2.17.3 Code review psychology 18
2.18 Treating criticism as praise 19
2.19 Automation ratio 19
2.20 Code of conduct 20
2.21 Software principles 20
2.22 Roles 22
2.23 Development time distribution 23
2.24 Comment to code ratio 24
2.25 The Apache Way 24
2.26 Intellectual property and licenses 25
2.27 Documentation 25
2.27.1 Being easy to find, easy to search, and easy to update 26
2.27.2 Being specific 26
2.27.3 Providing links wherever available 27
2.27.4 Documenting everything 27
2.27.5 Learning from good examples 27
2.27.6 Inspecting documentation 28
Chapter 3 Reducing Complexity, Increasing Quality 29
3.1 Source lines of code 29
3.2 Say no to bloatware 30
3.3 Software quality 32
3.4 High quality is cheap 32
3.5 Refactoring code 33
Chapter 4 Cloud Infrastructure 35
4.1 The pull request-centered collaboration model 36
4.2 Remote working 37
4.3 Email 39
4.4 Mailing lists 40
4.5 Git and GitHub 41
4.5.1 The feature-branching workflow 42
4.5.2 The fork-then-feature-branching workflow 47
4.5.3 Gitea 48
4.6 Kanboard 49
4.7 Bugzilla 51
4.7.1 Tracked bugs are good bugs 52
4.7.2 The more bug reports, the better 52
4.7.3 Do not accept duplicate bugs 53
4.8 The Bugzilla-Kanboard-Gitea workflow 53
4.9 Jenkins 55
Chapter 5 Selected Topics in The Software’s Life Cycle 56
5.1 Silver bullets 56
5.2 Project checklist 57
5.3 Fork 59
5.4 Technical debt 59
5.5 Timeboxing 60
5.6 Reusing 60
5.7 Tracking bugs 60
5.8 Bug repairs 61
5.9 Maintenance 61
5.10 Being simple and quite 63
5.11 Validation ＆ verification 63
Chapter 6 Requirements Risks 64
6.1 Important questions to ask before development starts 64
6.2 Risk analysis 67
6.2.1 The danger of not having a software requirements specification 67
6.2.2 The danger of having too many requirements 68
6.2.3 The danger of not talking to customers 69
6.2.4 The danger of preconceived ideas 69
6.2.5 The danger of ambiguity 71
6.3 Gathering requirements 71
6.3.1 Use cases 72
6.3.2 Requirements workshops 73
6.3.3 Prototyping 73
6.3.4 Brainstorming 73
6.4 Prioritizing requirements 75
6.5 Inspecting requirements 76
6.6 Structure of SRS 76
6.7 Common problems in SRS 77
6.8 Change of requirements 78
Chapter 7 Development 82
7.1 Schedule and budget 82
7.2 Processes 83
7.2.1 Waterfall 84
7.2.2 Extreme programming 84
7.2.3 Adopting a balanced approach 85
7.2.4 Iterative and evolutionary development 85
7.2.5 DevOps: combining development and operations together 85
7.2.6 Adhering to a process 86
7.3 Project efforts 87
7.4 Cost 87
7.5 Design 88
7.5.1 Design decisions 89
7.5.2 Why is design difficult? 89
7.5.3 Abstraction 90
7.5.4 Simplicity 91
7.5.5 Modularity 91
7.5.6 Handling undesired events 91
7.5.7 Formal inspections 92
7.6 Naming variables 92
7.7 Coding style 94
7.8 Comments and code 94
7.9 Programming languages 94
7.10 Pace 95
7.11 Versions 96
7.11.1 Concise and informative commit messages 96
7.11.2 Atomic commits and small pull requests 97
7.12 Test-first, test-early and test-last 97
7.13 Testing 99
7.13.1 Spell and grammar checking 101
7.13.2 Static code analysis 101
7.13.3 Unit testing 101
7.13.4 Usability testing 102
7.13.5 Regression testing 102
7.13.6 Code inspection and walkthrough 105
7.13.7 Test coverage 105
7.13.8 Test case density 106
7.13.9 Test case quality 106
7.13.10 Enough testing? 107
7.13.11 The trade-off between automated testing and manual testing 107
7.13.12 Test data generators 107
7.13.13 Testing in a small software company 108
7.14 Releasing 108
7.15 Continuous improvement 109
7.15.1 Continuous integration/continuous delivery 109
7.15.2 Continuous deployment with Docker 110
Chapter 8 Rules, Laws, and Plots 114
8.1 10 Years Rule 114
8.2 Eyeballs and bugs 115
8.3 Fish in the pond 115
8.4 Brooks’ Law 115
8.5 Goodhart’s Law 116
8.6 Cost to fix an error in different phases 116
8.7 Development cost versus maintenance cost 116
8.8 External quality versus internal quality 117
Chapter 9 Maintenance Stories 118
9.1 English Pal 118
9.2 Child Physical Examination Booking Application 119
9.3 The GNU Nano Editor 120
9.4 Lab Report Repository 124
9.4.1 Logging in with student number 125
9.4.2 Regression 126
9.4.3 Batch entering student numbers 132
9.4.4 Showing assignments that missed the deadline 135
9.4.5 A group member’s name appears more than once in group information 136
9.4.6 Definition of done 137
9.4.7. Other improvement areas for the Lab Report Repository web application 138
Chapter 10 References 140
Chapter 11 Appendices 143
11.1 Original requirements for Lab Report Repository 143
11.2 Correspondence between Ashly and the author on maintaining LRR 145
11.3 Software engineers, software writers, and entrepreneurs 148
11.4 End-to-end testing 148
11.5 Kanboard installation guide 151
11.6 Research questions 152