軟件工程-基於雲端協作的實踐 (英文版) 藍琿 葉榮華 9787121506345 【台灣高等教育出版社】

*書籍均為代購，我們向大陸付款發訂後即無法取消，為避免造成不必要的損失，
下訂前請慎重考慮！下訂前請慎重考慮！謝謝。
*完成訂單後正常情形下約兩周可抵台。
*本賣場提供之資訊僅供參考，以到貨標的為正確資訊。
印行年月：202506*若逾兩年請先於客服中心或Line洽詢存貨情況，謝謝。
台灣(台北市)在地出版社，每筆交易均開具統一發票，祝您中獎最高1000萬元。
書名：軟件工程-基於雲端協作的實踐 (英文版)
ISBN：9787121506345
出版社：電子工業
著編譯者：藍琿 葉榮華
頁數：168
所在地：中國大陸 *此為代購商品
書號：1745140
可大量預訂，請先連絡。

內容簡介
本書詳細闡述了如何在雲計算時代利用高質量、輕量的開源軟件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

大陸簡體正版圖書，訂購後正常情形下約兩周可抵台。