软件工程——基于云端协作的实践（英文版）
定价：￥49.80
作者： 蓝珲
出版时间：2025-06
出版社：电子工业出版社
- 电子工业出版社
- 9787121506345
- 1-1
- 568552
- 平塑
- 16开
- 2025-06
- 302
- 168
- 工学
- 计算机类
- 计算机科学与技术
- 本科 高职 研究生及以上
内容简介
本书详细阐述了如何在云计算时代利用高质量、轻量的开源软件Bugzilla，Kanboard，以及Git/Gitea进行软件的多人多地异步协同开发与维护。本书总结了以Pull Request为中心的多分支软件协作开发模型，并提出了与该模型配套的BKG工作流（Bugzilla-Kanboard-Git/Gitea Workflow）。本书立足实战，将软件工程的实践搬到云上，使得项目更新与知识共享触手可及，使云软件工程的概念得以落地。本书强调了搭建云基础设施以保障软件的持续改进。为了帮助读者更好地掌握我们的开发模型与工作流，本书配套了3个自己开发的完整网页应用程序。读者可以克隆所有程序的代码仓库。我们鼓励读者在自己的电脑上运行这些程序，发现缺陷，修复缺陷，提出改进意见，并提交补丁。
目录
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 decisio
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 decisio
