2021-05-09发表2022-10-18更新3 小时读完 (大约28185个字)

软件项目管理

Reading

Reading 1

Things You Should Never Do, Part I – Joel on Software

这是国外的老程序员 Joel Spolsky 在2000年写的文章。

更详尽的带图表的分析:

Why You Should (Almost) Never Rewrite Code – A Graphical Guide

Avram Joel Spolsky 生于1965年，他是一位软件工程师和作家。他是“Joel on Software”博客的作者。他从1991年到1994年间担任 Microsoft Excel 团队的项目经理。在2000年，他创立了 Fog Creek 软件并开启了“Joel on Software”博客。2008年，他和Jeff Atwood一起启动了如今极为成功的 Stack Overflow 程序员问答网站。他们用Stack Exchange软件产品作为Stack Overflow的引擎。现如今Stack Exchange网络已经包含了91个站点。

他在这篇文章的论点来源于一个简单的事实：
It’s harder to read code than to write it.
写代码容易，读代码难。

在开头，他批评网景公司犯了的最严重的战略错误——他们决定从头开始重写代码

由于网景当时的极度成功，公司规模扩展很快，为了应对开发的需求而收购了一家大型软件开发公司。但这家被收购公司的高层以及开发人员做了一系列愚蠢决定，包括使用当时如麻花一般的 C++ 代替 C，削减支持平台，优先发布 Windows 版本浏览器等，最后造成了新版本发布遥遥无期，程序质量不高等一系列问题，失去了对其他浏览器（包括IE）功能上和性能上的绝对优势，而结果就是被用户抛弃。

作者的观点主要有：

重写的代码即便能完全达到旧代码的所有功能、性能需求，为产品带来的竞争力也只有边际提升。（这个很好理解，因为代码的规范性和清晰度对产品的功能性没有直接帮助，只能降低远期的维护成本）
由于重写代码过程中需要花费额外的钱和时间，可能会出现一些意外状况，比如预算不够了，核心程序员离职了，或是重写的产品没有达到原有产品的所有功能和性能需求，那么这个结果可能是灾难性的，重写的产品要么胎死腹中，要么市场竞争力反而更低了。
在重写期间，由于竞争对手不会停滞不前并且您无法开发新功能，因此产品的竞争力通常会下降。而且重写花费的时间比预期的要长得多，连锁效应使产品竞争力下降的时间更长。对于小公司来说，这可能是致命的。

上面三个中的任何一个都可能致命，但是所有三个问题肯定都是致命的，产品的竞争力可能永远不会恢复。

如果公司的项目或产品代码混乱到无法再加入新功能或提升性能，跟时代严重脱节怎么办，那么应用以上原则，这时候既然这个项目已经快死了，那么放到新项目里重写显然是最合理的选择。

Reading 2

同样是 Joel Spolsky 在2000年写的文章。

The Joel Test: 12 Steps to Better Code

他用这十二条来评估软件团队的质量，大多数软件组织的运行得分为2或3，像 Microsoft 这样的公司的得分为12。

Do you use source control?
Can you make a build in one step?
Do you make daily builds?
Do you have a bug database?
Do you fix bugs before writing new code?
Do you have an up-to-date schedule?
Do you have a spec?
Do programmers have quiet working conditions?
Do you use the best tools money can buy?
Do you have testers?
Do new candidates write code during their interview?
Do you do hallway usability testing?

1.您是否使用源代码管理？

如果您没有源代码控制，那么您将不得不尝试使程序员们一起工作。程序员无法知道其他人做了什么。错误不能轻易回滚。

在源代码层面使其易于管理、维护，同时降低核心技术泄密风险。

2.你们可以把整个系统从源码到CD映像文件一步建成吗？

这句话问的问题是：从你们最新的源码开始到建立起能够交出去的最后文件，你们有多少步骤要做？一个好的团队应该有一个批处理程序一步便可将所有的工作做完，像把源文件提取出来，跟据不同的语言版本要求（英文版，中文版），和各种编译开关（#ifdef）进行编译，联接成可执行文件，标上版本号，打包成CD映像文件或直接送到网站上去，等等等等。

3.您是否进行日常构建？

在微软软件开发中，每日构建是最重要的过程之一，被称为微软产品开发的“心跳”。简单来看，每天构建系统将整个产品解决方案完整构建一遍，生成的目标文件和安装文件被放置在一个共享位置。接着，安装文件被自动部署到release server上，随后可以自动运行BVT（build verification test），并将所有结果寄送每个team member的信箱。

4.您是否有 bug 数据库？

如果您正在开发代码，即使是一个团队，也没有列出代码中所有已知错误的有组织的数据库，那么您将交付低质量的代码。

5.在编写新代码之前，您是否修复了 bug？

要立即修复 bug 的原因之一：因为它花费的时间更少。还有另一个原因，这与以下事实有关：预测编写新代码要比修复现有 bug 要花多长时间。例如，如果我要求您预测编写代码以对列表进行排序所需的时间，那么您可以给我一个很好的估计。但是，如果我问你如何预测这将需要多长时间来修复 bug：如果安装Internet Explorer 5.5您的代码不工作，你甚至无法猜测的，因为你不知道（定义）是什么导致 bug。跟踪可能需要3天，或者可能需要2分钟。

这意味着如果您的日程安排中有许多尚待修复的 bug，则该日程安排是不可靠的。但是，如果您已经解决了所有已知的 bug，而剩下的只是新代码，那么您的日程安排将更加准确。

将 bug 计数保持为零的另一个很棒的事情是，您可以更快地响应竞争。一些程序员认为这是使产品随时准备就的准备*。然后，如果您的竞争对手推出了一种吸引用户的杀手级新功能，则您可以实施该功能并当场发货，而无需修复大量累积的 bug。

6.您有最新的时间表吗？

这使我们按计划进行。如果您的代码对企业至关重要，则有很多原因说明知道何时完成代码对企业很重要。

制定时间表的另一个关键之处在于，它迫使您决定要执行的功能，然后迫使您选择最不重要的功能并将其剪切掉，而不是陷入特征成熟度（又称范围蠕动）。

7.您有写软件规格说明书（SPEC）吗？

在产品的前期设计过程中，如果你发现了一些问题，你可以轻易地在说明书里该几行字就行了。一旦进入了写程序的阶段，解决问题的代价就要高得多了。

没有产品开发详细说明书就开始写程序，往往会导致程序写的乱七八糟，而且左拖右拖不能交付使用。

不论采用以上哪种方法，道理只有一个：在没有产品开发详细说明书之前，决不可写程序。

8.程序员有安静的工作条件吗？

通过为知识工作者提供空间，安静和私密性，可以广泛地记录生产率的提高。

9.您是否使用金钱可以买到的最好的工具？

要给予程序员尽可能好的条件

10.您有测试员吗？

需要有测试员来检测产品的漏洞

11.新候选人在面试中是否写代码？

通过写代码了解程序员的能力，而不是看似漂亮的简历和问几个简单的问题（如CreateDialog()和DialogBox()有什么区别？这种问题，查一下帮助文件就知道了）

12.您是否进行走廊可用性测试(hallway usability testing)？

也就是随便抓一个人来，进行测试。

走廊实用性测试对于企业产品测试来讲提供的反馈比招募来做测试得出的结论要好很多，而且很多时候是完全相反的结论。

但现在很多企业都不做走廊测试了，而改用poll这种电子方式在Social Media发布，让用户选择。原因是走廊测试这种方法的效率不高。

Reading 3

The Development Abstraction Layer – Joel on Software

对于软件公司来说，管理的第一要务需要为程序员创造抽象。

我认为Joel的看法是尽量不能让程序员分心，让大家能够各司其职，每个人都能拥有良好的工作环境。

创造抽象的目的就是让程序员专心于开发，发挥其长处，最终创造更好的软件，使用户受益。

Reading 4

Good Software Takes Ten Years. Get Used To it. – Joel on Software

Joel 认为推出一个好的软件需要很长时间，也就是十年规则。

不理解十年规则会导致关键的业务错误

Get Big Fast 综合征（前期啥也别想，把用户量干上去就行了，不要在乎利润这种东西）

这种”从构建到翻转”的心态、公司庞大的超员和超支，以及每十分钟提高一次风投的需要，使得软件在10年内无法开发。
炒作综合征(the Overhype syndrome)

当你发布软件1.0版本时，需要保持冷静，而不是大肆炒作
相信互联网时间（Internet Time)

加快了版本升级速度，减少升级周期。

但是软件的创建速度没有加快，只是发布频率更高。
完成软件后，将不会再有收入
“准备好了我们就发货” 综合症

软件需要10年才能编写，但如果你10年不发布，企业就不可能生存下去

你必须提前发布不完整的版本，使他们相信你的版本1.0是有希望的——但不要夸大其言，因为它们不是那么好，不管你有多聪明。
过于频繁的升级(Too-frequent upgrades)

用户并不总是需要最新和最好的软件版本

良好的软件必须使用真实世界的数据来处理它在现实世界中可能遇到的例外。乔尔对”好软件”的定义是已经学会处理的软件。因此，可以在广大的情况下，为广大人民群众使用。

（说实话，拿 Lotus Notes当正面教材，在现在看来，有点好笑。高昂的价格，落后封闭的技术，维护和升级困难，反人类的交互设计使得其不断衰落）

该文章写于2001年，作者写这篇文章也是对2000年的互联网泡沫的思考。

互联网泡沫开始应该是从1999年开始的，那时候美国处于一个相对低息的周期，只有4%左右的利率。流动性开始涌入以互联网企业为代表的，新兴经济体，特别是在GDP增长，以及股市攀升带来的纸上富贵错觉影响下，拉动的消费增长，极大的增加的企业营收，越来越多的企业愿意在这些互联网公司身上投放网络广告。网络广告，也就是横幅banner，是当时互联网企业唯一的能够盈利的商业模式。新经济概念＋营收增长＋新商业模式故事带来的预期增长（其实就是网络销售 B2C B2B),形成戴维斯双击错觉＋正循环效应。让所有的人都心潮澎湃，nasdq指数的斜率陡然攀升，互联网大泡沫开始形成。很多企业在 ipo 的时候，就享受2-5倍的股价攀升，分析师、投资者、企业家、风投、银行全部都陷入狂热的情绪当中，everybody is winner,no loser.

那时候格林斯潘，还是美联储主席，预感到经济过热，和足够低的失业率空间，给了鹰派足够的多的话语权，美国开始进入一个加息周期，利率4%逐渐攀升到6%。

流动性的减少，带来了企业净利润的削弱，广告投放的减少，外加那些不挣钱的 B2B B2C业务，还有并购业务的繁荣，疯狂蚕食互联网企业的现金流，聪明的投资者开始意识到，这是一场不可持续的繁荣，已经有人在开始撤离，纳斯达克从最高点的5048.62开始逐渐回落，但是市场总体的情绪，并没有意识到这大周期的逆转点，抄底才是主旋律。

当然，那时候市场还有些别的新闻，为股市的下跌做出合理化的解释，最著名的莫过于微软公司在反垄断诉讼中的失败，被贴上的垄断的标签，差点面临被拆分的命运。

《巴伦周刊》上的一篇报道基于207家互联网公司的研究报告指出，将会有51家网络公司，现金流面临枯竭，而且股价下行＋高管套现＋投资风险厌恶上升＋市场资金缩减＋再融资市场的冷却，多重效应叠加下，这些公司的再融资问题无法得到解决，最终将会面临行业的大洗牌，破产加重组。

这篇报道引发了市场了恐慌，所有人才从如梦如幻的错觉中清醒过来，疯狂抛售自己手中的网络股票，市场在挤兑的浪潮下，纳斯达克指数在一年多的时间，跌到了最低点1114.11。

股指的下跌持续了2年，中途加上9·11事件带来影响，整个纳斯达克市值跌掉了5万亿美元，指数只有巅峰时期的四分之一不到，是美国历史上最大的金融泡沫之一，纳斯达克花了15年才恢复到2000年之前的水平。

2000年互联网泡沫始末 - 知乎 (zhihu.com)

再看2000年：泡沫破灭时的公司存亡 - 知乎 (zhihu.com)

Dot-com bubble - Wikipedia

大多数的公司并没有像当时的亚马逊、Ebay或者谷歌一样把金钱投入到技术和产品本身的建设，而仅仅停留在打广告拉新推广这种烧钱的模式中，占领市场全靠昂贵的广告和并购。

决定一家公司未来发展最重要的因素是公司优质可持续的发展模式，这也是其抵御危机的绝对筹码。只有一个好的创意确实有可能拿到大笔融资，但是如果没有持续的盈利能力，公司做大也只是一场泡沫，危机来临之时也会迅速坍塌

Reading 5

Meet Minimum Requirements: Anything More is Too Much - The Neal Whitten Group

作者 Neal Whitten 认为对于一个项目，首要的是满足最低要求，提交仅包含基本功能的项目计划，并针对非必要功能制定”壁橱计划”。

项目最常见的问题之一是承担了太多的工作——试图超越要求而不是满足最低要求。这造成了过多的不良影响，包括延迟交货、预算超支、士气低落和质量差。试图把俗话说的10磅塞进一个5磅重的袋子里是司空见惯的事。

“满足最低要求”意味着给客户成功所需的条件：但不提供必要的功能。其他功能是未来的发布和未来的商业机会。重要的是要赢得可靠履行客户承诺的声誉，然后被信任在常规的、可预测的基础上继续升级。这是一个很好的业务。

大多数人习惯于认为”满足最低要求”是没有刺激性和非竞争性的。作者认为情况正好相反。刻意实践符合最低要求，有助于组织或公司率先进入市场，从客户那里赢得越来越多的信誉，并有力地为企业创造新的商业机会摆出姿态。采用满足最低要求的概念可以为组织设置卓越的绩效。

Watching

Watching 1

纪录片《Code Rush》

节选一些读后感

看到CSDN上有不少人推荐，就看了这部纪录片。
与开始想象的不一样，这部纪录片的重点不是放在微软和网景的历史纠葛上，不是像很多描写硅谷商战的电影那样为故事添油加醋，非要展现出一个个令人血脉贲张、扣人心弦的情节不可，而是把重点放在描述那个历史背景下网景程序员的日常生活。
我也是程序员，在一个普通的IT公司上班，薪水待遇还算OK，但是工作压力比较大，项目紧的时候加班也是家常便饭。相信大部分程序员兄弟也是这种生活状态。我有时会在心里自嘲，天下有千万种职业，怎么我就选择做了苦逼的程序员呢？好像当初大学选了个计算系专业，这样稀里糊涂地就过来了。再看看人家美国小孩，从小就喜欢坐在电脑前写程序，16岁的时候已经为Mozilla的开源项目工作多年了，高中毕业之后顺理成章地来到硅谷工作。人家才是选择自己最喜欢和最擅长的事情作为职业，这是一件多么幸福的事。可惜成长在中国应试教育下面的大部分年轻人就没有这么好的运气了。
面对工作的重重压力，公司业绩的下滑，网景的程序员们又是怎么看待程序员生活的呢？有的人为自己订下约定，35岁之后就结束苦逼的程序员生涯，转行做别的；有的人在公司卖给AOL之后，趁着股价坚挺，赚了一笔，套现走人；有的人（公司领导）选择继续留在公司；还有的人选择去新的公司，继续追求自己的开源和技术理想。不管选择的道路怎样，正如片中所说，程序员们都要付出比很多行业更多的工作时间，把青春中最美好的时光花在了电脑前面，而不是与亲人朋友相处上。即使是创业成功而一夜暴富的人，他付出的代价也是常人难以想见的，而不了解的人往往只看到了表面的光鲜。
人们喜欢津津乐道乔布斯、盖茨们的成功，却忽视了在这些IT巨头背后，一些挣扎着与他们抗争的小公司。即使技术强如网景，也需要为商业上的失败买单。程序员们常常会有一种分裂的感觉：在计算机的世界里，他们是无所不能的上帝；而在其他方面，例如商业策略，他们又根本无能为力；于是会有瞬间从天堂跌落谷底的感觉，因为最出色的技术也并不能保证商业上的成功。即使好不容易杀出一条血路，也可能马上就被微软腾讯这样的巨头像捏死一只蚂蚁一样捏死。
谈了这么多程序员生活的艰辛，其实做一个程序员也有好的地方：有机会改变世界，生活中充满有趣的刺激和挑战，还有机会一夜暴富。很多程序员都是一个梦想家，是梦想给予他们力量度过苦与乐并存的生活。

一部关于Netscape公司的纪录片

作者：阮一峰

这是一部关于Netscape公司的纪录片。
如果你不知道这家伟大的公司，那么我告诉你，它是浏览器和其他许许多多东西的发明者，比如显示图片的img标签、http协议中的cookie、互联网加密协议SSL、以及javascript语言。上个世纪90年代中期，它的Netscape Communicator浏览器，曾经占据了90%的市场份额。
但是很不幸，它的对手是Microsoft。微软投入超过1亿美元，雇佣1000多个程序员，开发出了IE浏览器。更致命的是，微软将IE免费发行，并且捆绑在操作系统中。
所以，到了1998年的年初，所有人都看出来了，Netscape遇到大麻烦了。

《Code Rush》（奔腾的代码）这部纪录片，就是讲述Netscape公司在1998年的故事，摄制组整整跟拍了一年。

在其中，你可以看到两件历史性大事的第一手画面。
1998年3月31日，Netscape宣布将Netscape Communicator浏览器开源，这个新项目就叫做Mozilla。
1998年11月24日，由于股价不断创出新低，Netscape公司在绝望之中把自己以42亿美元的价格卖给了AOL。一家曾经如此辉煌的公司，就这样死了。后来的历史证明，AOL以42亿美元买来的只是一具无用的尸体。我不知道，历史上有没有比这更不合算的交易了。但是，这笔交易的好处是，AOL因此成为Mozilla项目的最大赞助者，Netscape已死，Mozilla活了下来。
Amazon上一位观众的留言标题就是”一家伟大公司之死”。

如果你对软件业感兴趣，希望了解程序员的生活，以及Mozilla项目的起源和创造它的人们，那么千万不要错过这部纪录片。
我保证这是一部过目难忘的作品。

自己学的就是计算机自己将要从事的就是写代码自己将要适应的就是纪录片里geek们的生活

在一个没有事情做的暑假午后看完这部10年前的纪录片它的时代感却还是鲜活地要跳出屏幕大起大落的网景独断的微软巨人呼声越来越响亮的代码开源或许计算机硬件软件都随着摩尔定律一路向前rush着但是计算机诞生60年来有一些精神在代码员心里不会改变

第一是创造不管是网景员工或是在乡村独自为mozilla贡献代码的高中生还是影片里在介绍美国街头变化时所透露出来的画外音都引导人们走入程序员所构筑的平行于现实世界的虚拟空间银行??我们有网上银行百货大厦??我们有网购寄达信件??用email吧怎样将网络构筑地比拟现实甚至超越现实一切的源头是程序员的创新和创造世界的渴望

第二是自由有很多侧面都可以体现出程序员应该有的自由奇怪的发型桌上叠成金字塔的空可乐罐混乱的工作时间办公室里夸张的躺椅和电玩设备… 这些反映于代码就是社区与开源程序员所创造的一切会有同行的审评改进并最终作为全人类的财富被共享没有太多的束缚一切服从于本心的渴望赚上十个亿不是程序员最大的渴望自己写的代码运行于十亿人的电脑才是真正值得兴奋的事情——当然能赚钱还是会很开心的>.<

第三是团队为了在有限生命里追寻创造世界的极致为了拥有心灵的慰藉为了对抗巨人…我们都需要团队每一个bug都尽力去调每一个部分都认真写好 netscape拥有看着或许业余但是战斗力强大的团队有术业专攻的程序员与负责的项目经理他们有机会成功只是现实世界变化地有些超出程序员的想象罢了…

第四是deadline 自己曾经说过追逐deadline是程序员的宿命有了deadline 疏懒的我们才不至于躺在椅子上盯着屏幕睡成一具尸体

Watching 2

google谈话Eric Brechner: “AgileProject Management with Kanban” | Talksat Google_哔哩哔哩_bilibili

使用看板以最大限度地提高效率、可预测性、质量和价值
使用看板，您花在软件项目上的每一分钟都能为客户增加价值。一本书可以帮助你实现这个目标：敏捷项目管理与看板。
作者埃里克·布雷奇纳在微软的Xbox工程团队中开创了看板。现在，他告诉你如何让它为你的球队工作。
把这本书想象成”盒子里的看门人”：打开它，阅读快速启动指南，你启动和运行得很快。随着您获得经验，Brechner 揭示了正确的团队规模、估计、满足最后期限、部署组件和服务、适应或从 Scrum 或传统瀑布演变等强大技术。
在旅程的每一步，您都会找到实用的建议、有用的清单和可操作的课程。这确实是”盒子里的看板”：所有你需要提供突破的价值和质量。

看板技术：

开始与当前团队和项目一起提供持续的价值
掌握完成工作积压的五个快速步骤
更有效地规划和人员编制新项目
最大限度地减少正在进行的工作，并快速调整以适应变化
消除人为会议和长期稳定
改善和增强客户参与度
可视化工作流程并修复暴露的瓶颈
驱动器质量上游
将看板整合到大型项目中
优化持续工程（由詹姆斯·瓦莱茨基贡献）
将看板扩展到软件开发之外

Watching 3

Feature-branching workflow using Git and GitHub

参考

Git 功能分支工作流|阿特拉斯吉特教程 (atlassian.com)

Watching 4

使用Jenkins自动部署Springboot应用程序_哔哩哔哩_bilibili

book

Producing Open Source Software How to Run a Successful Free Software Project

制造开源软件文档中心 - 文江博客 (wenjiangs.com)

Chapter 1. 介绍

作者认为大部分自由软件是失败的

开源软件开发过程中的独特问题：

一个最常见的错误就是急于从开源的形式本身获得好处
一个相关的错误是对展示和打包的轻视，特别是当一个项目顺利运转时总认为这些以后再做不迟。展示和打包有很多的目的，所有的一切都是为了减低进入的门槛。
一个谬误是认为开源几乎或完全不需要项目管理，或者照搬商业开发的那一套管理模式也能在开源中做得很好。
还有一种类型的问题也许我们可以称之为“文化引导失败”。

Chapter 2. 起步

当程序员对解决某个问题产生了个人兴趣之后，才能产生优秀的软件；这一点同自由软件的联系在于，大部分自由软件项目的最初动机都是始于一个人的痒痒处。

本章是关于如何将一个自由软件项目介绍给全世界

首先是寻找是否有一个现存的项目已经做了你想做的，如果有并且其已经解决了问题，那就不必重新发明轮子了。或者你脑中的计划非常特别，你肯定不会有其他人有同样的想法，那你也不妨试试看。如果没找到真正适合你的软件，可以决定开始一个新的项目。
选择一个好名字（告诉人们有关项目性质、便于记忆、不与另一个项目重名）
有一份清楚的使命陈述
声明项目是自由软件
特性和需求列表，列出一个简短的清单，说明软件支持的各种特性（如果某些特性还未完成，也可以列出，但是在旁边注明“计划中”或“建设中”），以及运行该软件所要求的系统环境。
开发状态，人们总是希望了解一个项目的状况。对新的项目，他们想知道项目的承诺和现实之间存在着多大的距离。对成熟的项目，他们想知道维护得如何，新发布的频率怎样，以及对Bug报告反应的及时性等等。

要回答这些问题，你应该建立开发状态页，列出项目的近期目标和需求（例如，需要具备某方面专长的开发人员）。开发状态页也可以列出过去发布的记录，其中包含特性清单，以便访问者了解项目是如何定义“进展”的，并根据这一定义了解项目进展的速度。
下载。应该可以以标准格式下载软件的源代码。
版本控制和Bug跟踪访问
沟通渠道
开发者指南。如果有人考虑参与项目，她会寻找开发者指南。与社会性文档相比，开发者指南通常没有很多的技巧：只需要解释开发者之间，以及与用户之间如何交互，以及如何最终完成任务。
文档（告诉读者他们所需的技术技能。清楚和完整的描述如何配置软件，并在文档的开头部分告诉用户如何运行确认安装成功的诊断测试或简单命令。提供一个普通任务的教程式的实例。标示文档中未完成的部分。）
- 维护FAQ
- 文档的可用性
- 开发者文档
输出和屏幕截图实例
包装主机

Chapter 3. 技术基础设施

自由软件项目依赖于选择性捕获和信息集成的技术。对这些技术的使用越是熟练，并说服别人去使用这些技术，你的项目就越成功。

大部分开源项目至少提供了最低限度的标准工具用于管理信息：

网站

主要是一个集中将项目信息发布给公共的单向渠道。网站也可以作为其他项目工具的管理界面使用。
邮件列表

通常会是项目中最活跃的通讯手段，是“可记录的媒介”。
版本控制

让开发者可以方便地管理代码的变更，包括回复和“变更转运”。让每一个人能看到代码的变化。
Bug跟踪

使开发者可以追踪他们正在工作的内容，互相协调，以及计划发布。让每个人都能查询Bug的状况并且记录特定Bug的信息（例如重现方法）。不仅能用于对bug的追踪，而且能用于任务、发布和新特性等等。
即时聊天

一个可以快速和方便的进行讨论和问答的地方，缺点是并不总是能完整地归档。

Chapter 4. 社会和政治的基础架构

本章尝试展示支持成功项目的共同结构。 “成功”不仅仅指的技术质量方面，而且也包含了运行健康状况和生存性。运行健康状况是指项目将新代码和新开发者吸收进来，并对到来的bug负责的持续能力。生存性是项目独立于任何单独参与者或赞助商而存在的能力—考虑一下如果项目所有的创始成员离开后项目继续运作的可能性。技术成功不难实现，但是如果没有健壮的开发者基础和社会基础，一个项目就不能处理由初始的成功带来的成长，或者有魅力个体的离开。

分叉能力

能将开发者绑定在一个自由软件项目中的必需组成部分，能让他们在必要时愿意作出妥协，是代码的分叉能力：也就是任何人可以使用一个拷贝并使之成为一个竞争项目的能力，被称为分叉。

慈善独裁者

慈善独裁者模型这一称号确实名副其实：最终的决定权完全取决于一个人，因为其人格和经验的力量，他被认为可以明智的运用这个权力。

Bugzilla

Bugzilla 是一个开源的缺陷跟踪系统（Bug-Tracking System），它可以管理软件开发中缺陷的提交（new），修复（resolve），关闭（close）等整个生命周期。

Bugzilla Bug报告分类

（1）待确认的（Unconfirmed）

（2）新提交的（New）

（3）已分配的（Assigned）

（4）问题未解决的（Reopened）

（5）待返测的（Resolved）

（6）待归档的（Verified）

（7）已归档的（Closed）

（8）Bug处理意见

（9）已修改的（Fixed）

（10）不是问题（Invalid）

（11）无法修改（Wontfix）

（12）以后版本解决（Later）

（13）保留（Remind）

（14）重复（Duplicate）

（15）无法重现（Worksforme）

Bugzilla指定处理人：

（1）可以指定一个处理人

（2）如不指定处理人，则系统指定管理员为默认处理人

Bugzilla链接:

输入超链接地址，引导处理人找到与报告相关联的信息

Bugzilla概述：

（1）概述部分“Summary”的描述，应保证处理人在阅读时能够清楚提交者在进行什么操作的时候发现了什么问题。

（2）如果是通用组件部分的测试，则必须将这一通用组件对应的功能名称写入概述中，以便今后查询。

Bugzilla平台操作系统：

（1）测试应用的硬件平台（Platform），通常选择“PC”

（2）测试应用的操作系统平台（OS）

Git

Git 教程 | 菜鸟教程 (runoob.com)

git init newrepo #初始化仓库
git clone <repo> #拷贝一份远程仓库，也就是下载一个项目
git clone <repo> <directory>

git add .   #添加文件到暂存区
git commit  #将暂存区内容添加到仓库中

git branch (branchname) #创建分支命令
git checkout (branchname)  #切换分支命令
git checkout -b X  #切换分支X

git pull origin master #从远程获取代码并合并本地的版本，远程分支与当前分支合并
git pull origin master:brantest #将远程主机 origin 的 master 分支拉取过来，与本地的 brantest 分支合并

git push origin master #将本地的 master 分支推送到 origin 主机的 master 分支

Kanboard

每个任务由一张卡片表示。

每张可移动卡可以处于以下阶段之一：

积压、进行中的工作 (WIP) 和完成。

通常，随着工作的进行，您会转移卡片向右。

对于软件开发，我们可以有 Backlog（要求）、开发、测试、文档、完成。

优先事项。按每个阶段的卡片按重要性排序。

从你现在正在做的事情开始。

WIP limit。不要过于压倒开发人员许多任务（多任务处理）。

完成或完成规则的定义。

提前期 Lead time：任务创建和任务之间的时间完成。对客户可见。

周期时间 Cycle time：任务开始到完成。对员工可见。

燃尽图（Cumulative Flow Diagram）。是以图表展示随着时间的减少工作量的剩余情况。工作量一般以竖轴展示，时间一般以横轴展示。燃尽图对于预测何时完成工作很有用，经常被用于敏捷软件开发中，如Scrum。燃尽图也可以用于任何可测量的进度随着时间变化的项目

拉工作而不是推工作 Pull work instead of Push work

每个团队成员一种颜色

Jenkins

Jenkins高级用法 - Jenkinsfile 介绍及实战经验 - 晓晨Master - 博客园 (cnblogs.com)

(8条消息) 玩转Jenkins Pipeline_大宝鱼的博客-CSDN博客_jenkins pipeline

CI/CD 方法

CI/CD是实现敏捷和Devops理念的一种方法。
具体而言，CI/CD 可让持续自动化和持续监控贯穿于应用的整个生命周期（从集成和测试阶段，到交付和部署）。这些关联的事务通常被统称为“CI/CD 管道”，由开发和运维团队以敏捷方式协同支持。

CI - 持续集成

持续集成（CI）是在源代码变更后自动检测、拉取、构建和（在大多数情况下）进行单元测试的过程。持续集成是启动管道的环节（尽管某些预验证 —— 通常称为 上线前检查(pre-flight checks) —— 有时会被归在持续集成之前）。

持续集成的目标是快速确保开发人员新提交的变更是好的，并且适合在代码库中进一步使用。

CD - 持续交付

持续交付（CD）通常是指整个流程链（管道），它自动监测源代码变更并通过构建、测试、打包和相关操作运行它们以生成可部署的版本，基本上没有任何人为干预。

持续交付在软件开发过程中的目标是自动化、效率、可靠性、可重复性和质量保障（通过持续测试）。

持续交付包含持续集成（自动检测源代码变更、执行构建过程、运行单元测试以验证变更），持续测试（对代码运行各种测试以保障代码质量），和（可选）持续部署（通过管道发布版本自动提供给用户）。

Pipeline

Pipeline，简而言之，就是一套运行于Jenkins上的工作流框架，将原本独立运行于单个或者多个节点的任务连接起来，实现单个任务难以完成的复杂流程编排与可视化。

Pipeline是Jenkins2.X的最核心的特性，帮助Jenkins实现从CI到CD与DevOps的转变

Pipeline是一组插件，让Jenkins可以实现持续交付管道的落地和实施。

持续交付管道（CD Pipeline）是将软件从版本控制阶段到交付给用户或客户的完整过程的自动化表现。软件的每一次更改（提交到源代码管理系统）都要经过一个复杂的过程才能被发布。

Pipeline提供了一组可扩展的工具，通过Pipeline Domain Specific Language（DSL）syntax可以达到Pipeline as Code（Jenkinsfile存储在项目的源代码库）的目的。

Stage：阶段，一个Pipeline可以划分成若干个Stage，每个Stage代表一组操作，例如：“Build”，“Test”，“Deploy”。

注意，Stage是一个逻辑分组的概念，可以跨多个Node

Node：节点，一个Node就是一个Jenkins节点，或者是Master，或者是Agent，是执行Step的具体运行环境。

Step：步骤，Step是最基本的操作单元，小到创建一个目录，大到构建一个Docker镜像，由各类Jenklins Plugin提供，例如：sh ‘make’

Pipeline五大特性

代码: Pipeline 以代码的形式实现，通常被检入源代码控制，使团队能够编辑、审查和迭代其 CD 流程。
可持续性：Jenklins 重启或者中断后都不会影响 Pipeline Job。
停顿：Pipeline 可以选择停止并等待任工输入或批准，然后再继续 Pipeline 运行。
多功能：Pipeline 支持现实世界的复杂 CD 要求，包括 fork/join 子进程，循环和并行执行工作的能力
可扩展：Pipeline 插件支持其 DSL 的自定义扩展以及与其他插件集成的多个选项。

Jenkinsfile

Jenkinsfile 是 Jenkins 2.x 核心特性 Pipeline 的脚本，由Groovy语言实现。Jenkinsfile一般是放在项目根目录，随项目一起受源代码管理软件控制，无需像创建“自由风格”（Jenkins FreeStyle）项目一样，每次可能需要拷贝很多设置到新项目，提供了一些直接的好处：

Pipeline上的代码审查/迭代
Pipeline的审计跟踪
Pipeline的唯一真实来源，可以由项目的多个成员查看和编辑。

Pipeline支持：Declarative（在Pipeline 2.5中引入）和Scripted Pipeline两种格式。两者都支持建立Pipeline，两者都可以用于在Web UI中定义一个流水线Jenkinsfile，将Jenkinsfile文件创建并检查到源代码控制库中通常被认为是最佳做法。

spm-slides

(蓝珲的PDF讲稿，选择一些比较重要的内容，可能与其他笔记内容重复；内容是机翻的，理解可能不太通顺)

旧计划很快就会过时。

你有一个计划，但你总是被额外的“请求”而分心。其称为请求蠕变（request creep）的现象。

• 请求将“一些小功能”添加到产品而无需更改预算或时间表。

• 要求接纳一些在职人员在项目之间找到对他们有用的东西去做。

• 减少设计审查范围的请求（在为了弥补一些时间表）。

你应该仔细考虑请求的影响。你应该能够协商计划、时间表的相应变更和预算。

我建议你遵循的步骤。

礼貌地说“不”。
告诉我，如果我不那么忙，我愿意提供帮助。
分析额外请求对我目前的时间表的影响。
要求更多的钱或时间，或两者兼而有之。（这管理委员会通常会同意，因为他们已经投入了很多，只要你的要求是合理的。）

专有软件（Proprietary Software）

proprietary ：与所有者或所有权有关。

该软件归一家公司所有，该公司规定对使用、修改和分发的许多限制。我们需要先付款（显式或隐式）用它。

网景的错误

糟糕的产品，糟糕的产品决策，产品方向。

变得太大了。

停止创新。

功能蠕变。不

断添加“不”的功能休息一下，没有时间重新构建”。

反微软。

粗糙、复杂的代码。

IE 占了上风。

频繁发布

编程基本定律（Joel Spolsky）：阅读代码比编写代码更难。

从头开始可能是一种荒谬的策略或行为。

创业公司杀手：建立一个扔掉。

大误解：新代码比旧代码好。

原因：

• 你不能保证新代码比旧代码好。

• 当我们添加代码时，我们添加了功能，也可能带来新的Bug。

• 虽然旧代码看起来很丑，但新代码甚至可以更差。

• 你可能会再次犯旧错误，并犯下新错误错误。

• 旧代码已被使用、测试和修复。新的代码没有。这意味着巨大的努力和时间（通常对您来说是不可见的）已投入旧代码。那就是钱。

• 旧代码：也许修复只是一行代码，或者只是几个字符。但这需要巨大的努力。扔掉代码就是扔掉努力，有时是多年的编程工作。

•（旧代码）不会因为坐下而获得错误在你的硬盘上。- 乔尔·斯波尔斯基。

Software years：即使您的新代码更好，您可能会落后几年，并且因此失去市场。

使用分支避免瓶颈

有利于协同开发。

发布分支，错误修复分支，实验分行等

分支之所以有价值，是因为它们变得稀缺资源——项目代码中的工作室——进入丰富的。

分支做起来成本低。

提出拉取请求、请求审查和合并（当所有审稿人都满意时）。

隔离和稳定释放线到发展线。

自由使用分支。

大多数分支应该合并他们的更改尽快进入主线并消失。

当我们进行合并时，表明这是一个合并到日志消息中

拉取请求（Pull Requests）

拉取请求是来自贡献者的请求，某个变更被“拉”（合并）的项目进入项目。

一旦贡献到达，它通常会消失通过审查和修订过程，包括贡献者与各方面的沟通项目的成员。

代码更改合并到项目的主分支是什么时候正式成为项目的一部分。

对项目的99.9%的贡献应该通过拉取请求 - 审查 - 修订 - 合并的过程。

拉取请求应该有一个目的。如果你有很多目的，那就创造很多分支并发出许多拉取请求。

为什么？

更容易参考一个小项目，更容易审查一个小项目。

基本 Git 命令

git branch

git checkout -b FIX-README

git add .

git commit -m ”README.md: Why, What, How?”

git pull origin master

git push origin FIX-README

git checkout FIX-README

你在项目开源后宣布。

你应该期待什么：

- 影响不大。保持 1.0 安静。

- 一些随意的询问。

- 您的邮件列表中还有几个人。

发布即播种。

形成指数通信网络。

项目→社区

版本（修订）控制系统

Version (revision) Control System

版本控制的核心是变更管理：

谁在哪个日期进行了哪些更改。

两种方式：

锁定-修改-解锁
复制-修改-合并

commit - 对项目进行更改。

push - 发布对公开在线的提交存储库。

pull (or update) - 拉其他人的更改（提交）您的项目副本中。

commit message - 评论附加到每个提交，描述性质和提交的目的。

repository - 存储更改的数据库并从中发布它们。

clone - 获得自己的开发库通过制作项目中央存储库的副本。

checkout - 切换到分支

revision or commit - 修订或提交

diff - 更改的文本表示。

tag or snapshot - 标签或快照

branch - 项目的副本，受版本控制但被隔离，以便对分支所做的更改不会

影响项目的其他分支。一个好方法拥有多条独立的发展路线。“主线”、“主干”、“主线”、“发布分支”

merge - 将更改从一个分支移动到其他分支。

conflict - - 当两个人试图做出不同的更改到代码中的相同位置。“解决”问题冲突。

revert - 撤消已提交的软件更改。

失去焦点（Losing Focus）

甚至不要考虑创建膨胀软件，或者群件。

继续您的产品愿景。

许多干扰，一路向北

发布节奏（Rhythm of Releases）

过于频繁的发布被认为不是成熟产品所必需的

梅特卡夫定律（Metcalfe’s Law）

网络的价值随着网络规模的平方而增长。

The value of a network grows by the square of the size of the network

德尔福效应（Delphi Effect）

集成方法

一大批同样专业的观察家的平均意见比一个随机选择的观察家的意见更可靠

专家的差异很重要

首先寻找现有的解决方案

Looking for Existing Solutions First

也许不值得重新发明轮子。相反，向现有功能添加一些功能。

例外：出于教育目的，非常专门的应用程序，用于国家安全

不要让任务压倒你。

No Need to Provide Everything At Once

这样做会非常耗时：

• 详尽的设计文档

• 完整的用户手册

• 精美且可移植的打包代码

• 平台独立

Hacktivationenergy

一个新人必须投入的精力，在他开始找回一些灵感（手感）之前

摩擦（Friction）

潜在贡献者成为真正贡献者所需的能量

Alpha - 第一个版本，有已知错误。

Beta - 修复了严重的已知错误，请用户提供详细的反馈

10-year Rule. Good Software Takes Ten Years. Get Used To it. Sustained effort is needed.

避免私下讨论（Avoid Private Discussions）

与公开讨论一样缓慢和繁琐是的，从长远来看，它几乎总是可取的。如果没有理由将其设为私有，则应该公开。

为什么？

讨论将有助于培训和教育新的开发人员。
讨论将培训您如何向不像您那样熟悉软件的人解释技术问题。
讨论将形成档案以备将来使用参考。

对粗鲁行为的零容忍政策

在分布式工作环境中，写下所有内容对于有效沟通至关重要

代码审查（Code review）

提交审查。

开源世界中的同行评审。

好处：

培养富有成效的发展社区。
提高软件质量。在它们之前捕获错误溜进。

为什么我们专注于审查最近的变化？

• 它在社交方面效果更好。及时反馈新鲜变化。与人互动的好方法。确认他们所做的事情很重要（被看到并明白了）。人们在做他们最好的工作时知道其他人会花时间对其进行评估

• 最近的变化是获得熟悉代码库。也看看受影响的呼叫者和被呼叫者。

审查应该是公开的，以便其他人可以看到它并知道发生了审查，并且是期待。

提交通知很有用

技术债（Technical debt）

“当走捷径并交付不适合当前编程任务的代码时，开发团队会招致技术债务。这种债务降低了生产力。生产力的损失是技术债务的利益。”

高技术债务会使软件不可维护

自述文件（README）

使用此文件来传达原因、内容和方式。
将此文件视为项目的构成。
使用此文件可避免特征蔓延（feature creep）

“In the open”意味着以下事情是公开访问：

- 代码库

- 错误跟踪器

- 设计文件

- 用户文档

- 维基

- 开发者论坛

您的日常工作对公众可见。兼容的开源

“In the open”不一定意味着以下内容

- 允许陌生人将代码检查到您的存储库

- 允许任何人在您的跟踪器中提交错误报告

- 阅读并响应提交的每个错误报告，即使您确实允许陌生人提交

- 回答人们在论坛中提出的每个问题

- 审查发布的每个补丁或建议，何时这样做可能会花费宝贵的开发时间

你的源代码是开放的，但你的时间没有开放

项目需要什么

网站：更好地将面向用户的与面向开发者。
邮件列表/消息论坛
版本控制
错误跟踪
实时聊天

罐头托管（Canned Hosting）

提供在线协作的在线服务运行自由软件项目所需的工具

Github (Ben Balter)
Bitbucket
Launchpad
Savannah

优点：

（1）服务器容量和带宽

（2）简单。

缺点：定制有限，无精打细算粒度控制

匿名和参与（Anonymity and involvement）

您不希望陌生人将更改推入您的回购，即使他们被审查。

你不想要一个不方便的参与吧防止快速评论和简单的错误报告。

确保只读操作、错误归档（使用适当的允许使用反垃圾邮件技术，例如验证码）对于匿名、未登录的访问者有用

可浏览性（Browsability）

项目的存储库应该可以在Web上浏览

可浏览性很重要，因为它是一个轻量级的项目数据的门户。

可浏览性还意味着用于查看的规范 URL一个特殊的变化——在讨论过程中没有歧义

票证生命周期（Ticket life cycle）

存储库树中引入的每行代码都必须经过严格的审查过程。这保证了代码基础的整体质量

其他人阅读票证，添加评论，然后也许要求原始申报人澄清一些点

该错误被重现。

该错误得到诊断。分配所有权。放优先事项。

票被安排解决。

该错误得到修复。票已关闭。

需要注意的事情：是不是真正的错误；是否有重复的漏洞。

分叉和可分叉性（Fork and Forkability）

复制一份源代码并用它开始一个竞争项目，称为分叉。

结果：自由软件中没有真正的独裁者项目。

错误的决定最终会引发反抗和分叉。

硬分叉：不向前兼容的分叉

分叉的可能性。

实际分叉

仁慈的独裁者（Benevolent Dictators）

做出最终决定的人。

个性和经验。

不愿做出决定：在大多数情况下，推迟给领域专家或区域维护者。让其他人讨论。

BD - 社区认可的仲裁员。例如，一个项目的创始人。

需要注意的两点：

BD通常没有在所有领域都有足够的专业知识。
优质开发商如果他们不能影响项目的，就不会留下来方向。在没有达成共识并且大多数开发人员想要的情况下继续前进，BD 会说“事情就是这样。”

好BD的特征。

自我约束。没有BD早期讨论中的个人意见或结论以便每个人都可以发言。
承认自己错误的决定。
不需要有最好的技术能力。

如果项目有一个明显的、好的候选BD，那就是要走的路。否则，请使用民主

懒惰的共识

隐含的共识。

沉默意味着同意。

沉默意味着没有异议

Lazy Consensus

Implicit consensus.

Silence means consent.

Silence means no objection.

版本控制意味着您可以放松

Version control means you can relax

更改可以恢复。

所以我们可以消除坏的或仓促的影响判断。

但这并不意味着我们可以滥用回归

阿帕奇方式（The Apache Way）

基于共识、社区驱动的治理。

项目管理委员会具有较高的自由度。

使用邮件列表进行通信（异步）。语音交流非常稀有的。为什么？

做决定：“meritocracy”, “do-ocracy”

做事者的力量：做的越多，允许做的越多。使用惰性共识（沉默意味着没有异议）。+1, 0 (没有意见), -1 (需要提供另一种建议）。

ASF Incubator

成为 ASF 项目的切入点。

它根据成功可能性过滤项目。

要求：工作代码库，意图转让足够的知识产权，以及赞助 ASF 成员或官员

邮件列表（Mailing lists）

使用邮件列表而不是私人邮件列表的好处通信是一种共享资源，其中其他人也可以从常见的错误中学习社区，我们共同成长。

审查然后提交或提交然后审查（Review-Then-Commit or Commit-Then-Review）

RTC：改变首先需要共识批准。

CTR：随意更改，有可能被追溯否决

未能提供高质量的批评可能是一种侮辱

你必须对一切做出回应。

沉默也是交流。如果你不知道如何回答，用沉默回答

显着使用档案（Conspicuous use of archives）

开源项目中的所有通信都是存档。

为什么档案很重要？

他们提供了一个基础供讨论。

在提问之前先搜索存档。

为了避免重复，如果一个问题已经在档案中回答，参考它（例如，包括一个链接到存档页面）

选择合适的论坛

IRC 或开发邮件列表？

IRC：适合快速响应，不适合制作由于样本量很小，因此做出了重大决定。

邮件列表：更正式。每一个感兴趣的人将有机会看到并回应相关帖子，不分时区，时间表。

发布分支（Release branch）

发布分支只是版本中的一个分支控制系统（见分支），其上的代码用于此版本的可以与主线隔离发展。

混沌之力（Forces of Chaos）

一位重要的开发人员突然失去了兴趣

长期雇用一个真正有经验的程序员

在项目中至少呆了几年。
拥有良好的声誉。
有影响。
非常了解代码。
了解有关设计决策的旧讨论。
具有提交访问权限。

如何培养新人？

从错误修正和清理任务开始，这样他就可以学习代码库并让自己了解社区。

有经验的程序员应该阅读所有内容新人发布（例如，错误修复补丁）并成为可以回答他的问题。

评估开源项目（Evaluating Open Source Projects）

社会健康和项目成熟度。Social health and project maturity.

他们的开发者有多庞大和多样化社区？

他们是否定期获得新的贡献者？

他们是否处理传入的错误报告合理的方式？

他们是否足够频繁地发布稳定版本您的需求？

tips：

首先查看错误跟踪器活动。

衡量提交多样性，而不是提交率。

评估组织多样性。

讨论论坛。

新闻、公告和发布

测试金字塔

（1） 尽可能地多做单元测试和集成测试，因为他们的执行速度相较于上层的几个测试类型来说快很多且相对稳定，可以一天多次执行。一般来说，我们都会将单元测试和集成测试做到持续集成构建任务中去，比如放到Jenkins中每天定时执行1~2次，或者每次push代码到git仓库后执行，总之，就是要确保可以频繁执行以确保代码质量。

（2） 尽可能地少做组件测试、端到端测试和探索性测试，因为他们的执行速度相较单元测试和集成测试会慢很多，且不够稳定，无法做到一天多次执行，每次执行都要等很久才能获得反馈结果。但是，他们的覆盖面比下层的单元测试和集成测试要广一些。总之，就是要确保一定周期内或者关键节点时间执行以下这几个测试以确保软件质量。

古德哈特定律（Goodhart’s law），是以 Charles Goodhart 的名字命名的，这是一个非常有名的定理：当一个政策变成目标，它将不再是一个好的政策。

当衡量标准成为目标时，它就不再是一个好的衡量标准

Goodhart软件开发定律的一个例子是代码行数。代码行数提供了一种衡量软件产品大小的方法。但是，当用作目标时，代码的质量会下降。

应该根据软件本身的结构进行精炼或分离，而不是一个混乱的意大利面条式代码。

Other

书面文化 written-culture

Chapter 6. Communications (producingoss.com)

清晰写作的能力也许是在开源环境中最重要的技能。从长远来看，它比编程人才更重要。

人如其文 you-are-what-you-write

You Are What You Write (producingoss.com)

结构和格式

不要像编写手机短信那样编写所有的东西。要使用完整的句子，每个句子首字母要大写，也要根据需要分段。在编写电子邮件和其他内容时这一点最重要。邮件、文档、bug报告和其他会永久保存的东西，必须使用标准语法和拼写，并有一致的叙事结构。

对于个别的电子邮件，有经验的开源开发者会使用特定的约定：

只发送文本邮件，而不应该是HTML、富文本或其他格式
使用真正的换行
包含屏幕输出，代码片段或其他格式化文本时，需要清晰的处理缩进，这样可以轻易的区分你的叙述和引用的内容
当引用其他人的邮件时，可以直接在合适的位置插入你的回应
小心构建新邮件的主题行

内容

让读者轻松
不要使用夸张法
编辑两次

基调（语气，风格）

通过仔细注意人们行为的长期模式，即使你从未面对面地遇到他们，你也会开始意识到他们是个体。通过对自己写作的语气敏感，你可以对别人的感受产生惊人的影响，从而最终受益。

识别无礼

技术批评，即使很直接且没有铺垫，也不是无礼的
迟钝、朴实的问题，也不是无礼
按照同样的原则，详细的技术批评是一种奉承，不提供高质量的批评可能是一种侮辱

面容

避免常见的陷阱 testing-and-releasing

Avoiding Common Pitfalls (producingoss.com)

不要发表无目的的文章

三类信息占据：

提出重要事物的信息
提出对他人曾经说过的话表示支持或反对的信息
总结信息

生产性与非生产性线程

非生产性线程的一些特征：

已经提出的论点已经开始在同一条线程中重复，好像海报认为没有人第一次听到它们。
随着赌注越来越小，夸张和参与程度越来越高。
大多数评论来自很少或什么都不做的人，而那些倾向于把事情做完的人是沉默的。
许多想法讨论后从未提出过明确的建议。（当然，任何有趣的想法一开始都是一个不精确的愿景;重要的问题是它从何而来。这个线索似乎是在把视觉变成更具体的东西，还是把它旋转成子视、侧视和本体论争议？

主题越小，辩论时间越长

对于长期的主题，讨论的数量与主题的复杂度成反比的原理，被非正式的称为Bikeshed效应（BSD）

避免圣战

圣战的一个共同特点是，在继续讨论能否解决争端这一问题上存在分歧。

处理圣战：

第一个答案是，做好准备避免其发生

当圣战不可避免时，尽早决定你要关注多少，并乐意公开放弃。当你这样做，你可以说你正在退出，这场圣战毫无价值，而不要展示出挖苦，并且不要利用这个机会对对方的辩论做最后一次攻击。只有优雅的去做才能有效的放弃。

“嘈杂的少数派”效应 noisy-minority

在任何邮件列表讨论中，少数人很容易给人留下非常不同的印象，因为列表中充斥着大量冗长的电子邮件。

对付这种影响的最佳方法是非常清楚地指出这一影响，并提供佐证，表明与同意者相比，实际持不同政见者人数是多么少。

不要抨击竞争的开源产品

避免对竞争的开源软件发表负面意见。给出负面事实是完全可以的——即很容易在良好的比较图表中看到的那种可以证实的断言。但是，出于两个原因，最好避免对性质不那么严格的负面描述。首先，他们容易发动有损于富有成效的讨论的火焰战。其次，更重要的是，您项目中的一些开发人员也可能参与竞争项目，或者来自其他项目的开发人员可能正在考虑为您的项目做出贡献。

测试和发布 testing-and-releasing

Testing and Releasing (producingoss.com)

软件公开之前，它应该经过一些最低数量的开发人员（通常是三个或更多）的测试和批准。然后，必须使用数字签名和识别哈希向全世界发出批准信号。

签名和哈希的目的是给用户一种方法来验证他们收到的副本没有被恶意篡改。

获得开发人员批准不仅仅是他们检查发布是否存在明显缺陷的问题。

候选版本

对于包含许多变更的发布版本，许多项目会首先推出发布候选版本

在大多数其他方面，候选发布一定要与正式发布保持相同的待遇。alpha、beta或rc修饰足以警告保守的用户等待真正的发布，而候选发布的声明邮件也必须指出他们的目的是征求反馈。除此以外，应该对候选发布提供与正式发布相同的关注。毕竟，你希望人们使用候选版本，因为暴露是发现bug的最佳方法，而且也因为你永远无法获知哪个候选会最终成为正式版本。

宣布发布

每当你提供下载发布tarball的URL时，一定要确保给出MD5/SHA校验和数字签名文件的链接。

在宣告邮件和新闻页中，不应该仅仅报告关于发布的宣传信息，而应该包含CHANGES文件中相关的部分，这样人们就能够看到自己是否有兴趣去升级。

最后，不要忘记感谢项目团队、测试人员以及所有花时间发起bug报告的人。

团队协作教程

TeamCollaborationTutorial/team.rst at master · spm2020spring/TeamCollaborationTutorial (github.com)

集中式工作流 (Centralized Workflow)

集中式工作流保留了在 SVN 下的工作风格，对于每一个 Repo，集中式工作流只使用 master 分支进行开发。

从 master 克隆分支到本地

git clone https://github.com/spm2020spring/TeamCollaborationTutorial.git

（只能克隆一次）
去工作目录

cd TeamCollaborationTutorial
获取当前分支

git branch
创建并切换分支（Copy the whole castle to make castle2）

git checkout -b castle2

（现在 castle2 包含了主分支的所有内容。此命令只能执行一次。当您希望切换到 castle2 时，使用上面的命令而不使用 -b）

现在在 castle2 分支
编辑文件、暂存和提交

git add .

git commit -m “file changed: specific messages (what & why)”

（一切发生在 castle2 ，原来的不受影响）
切换回主分支 master

git branch master
现在在castle2中所做的更改合并到master中

git merge castle2

中央仓库（central repo）发生了什么？

当我在 castle2 内部努力工作时，我团队中的其他人可能已经更新了中央仓库
与更新同步

git pull origin master
将 master 分支推送到 origin 服务器

git push origin master

功能分支工作流（feature-branching workflow）

功能分支工作流背后的核心思路是所有的功能开发应该在一个专门的分支，而不是在master分支上。

这个隔离可以方便多个开发者在各自的功能上开发而不会弄乱主干代码。另外，也保证了master分支的代码一定不会是有问题的，极大有利于集成环境。

从 master 克隆分支到本地

git clone https://github.com/spm2020spring/TeamCollaborationTutorial.git

（只能克隆一次）
去工作目录

cd TeamCollaborationTutorial
获取当前分支

git branch
创建并切换分支（Copy the whole castle to make castle2）

git checkout -b chinese-castle

（现在 chinese-castle 包含了主分支的所有内容。此命令只能执行一次。当您希望切换到 chinese-castle 时，使用上面的命令而不使用 -b）

现在在 chinese-castle 分支

所有与此功能相关的更改（或错误修复）都必须发生在 chinese castle 中。
编辑文件、暂存和提交；

git add .

git commit -m “file changed: specific messages (what & why)”
更新分支 chinese-castle

git pull origin master
将 chinese-castle 推送到中央仓库

git push origin chinese-castle

2020年春季期末考试

判断题

Detailed, dispassionate technical criticism can be regarded as a kind of praise.

详细、公正的技术批评可以视为赞美

应该是对的
At the Apache Software Foundation (ASF), Project Management Committees (PMCs)
can manage their projects independently and set per-project policies, as long as they follow the
Apache corporate policies in terms of licensing, branding, infrastructure and so on.

在 Apache 软件基金会 (ASF)，项目管理委员会 (PMC) 可以独立管理他们的项目并设置每个项目的政策，只要他们遵循 Apache 公司在许可、品牌、基础设施等方面的政策。

应该是对的
Let code to comment ratio, φ, be the amount of code divided by the amount of comments.

A reasonable value of φ ranges from 3 to 10, according to the top 10 software listed at OpenHub.

让代码与评论的比率 φ 是代码量除以评论量。根据 OpenHub 列出的前 10 名软件，φ 的合理值范围为 3 到 10。

对

When preparing a release, it is a good practice to create a release branch, isolated from
the mainline development.

在准备发布时，最好创建一个发布分支，与主分支隔离。

应该是对的
Reviewing changes before merging them to the master branch is a waste of time

在将更改合并到 master 分支之前审查更改是浪费时间

应该是错的
Open source software can be used for commercial purposes

开源软件可用于商业用途

应该是对的
Your priority as the manager of a software team is building the development abstraction
layer on which programmers can produce.

作为软件团队经理，您的首要任务是构建程序员可以在其上进行生产的抽象层。

应该是对的（见 Reading 3）
You developed a Web application and want to open source it. Affero GPL is a better choice of license than GPL because it has an extra clause designed specifically for online applications.

您开发了一个 Web 应用程序并希望将其开源。 Affero GPL 比 GPL 更好许可，因为它有一个专门为在线应用程序设计的额外条款。

应该是对的（其主要针对的是基于web的应用程序,要求网络程序开发者必须让源代码能通过网络分发）
Having many bug reports in your bug tracking system indicates that your software project is unlikely to be successful. Therefore, a good project manager does not use a bug tracker.

在您的错误跟踪系统中有许多错误报告表明您的软件项目不太可能成功。因此，优秀的项目经理不会使用错误跟踪器。

显然是错的
Don’t hire a tester. Ask the programmer to do testing, because you can save money spent on salary and the programmer knows the program better.

不要聘请测试人员。请程序员做测试，因为可以省钱花在薪水上，程序员更了解程序。

错（开发和测试是软件生命周期的不同组成部分，专门的测试人员更能保证软件的高质量。）

简答题

Describe fork. Describe feature creep.

描述 fork（分支）.描述 feature creep（功能蔓延）.

答案：
fork: a copy of the original source code.

feature creep: the amount of additional feature requests exceeds a team's capacity.

分支：从一个软件包拷贝了一份源代码然后在其上进行独立的开发，创建不同的软件。这个术语不只意味着版本控制上的分支，同时也意味着开发者社区的分割，是一种形式的分裂。

功能蔓延（feature creep），有时也被称为需求蔓延（requirements creep）或范围蔓延（scope creep），它是指在发展过程中产品或设计的需求增加大大超过他们原来预期的趋势，导致其功能不是原本计划的并且要承担产品质量或生产进度的风险。

In terms of treating old code, Joel Spolsky suggested “ ___ old code”.Please fill in the line. What are the good things about old code

在处理旧代码方面，Joel Spolsky 提出了“___旧代码”。请填写行。旧代码有什么好处

答案：
Do not throw awy / Keep / Reuse / New code may be worse than / It is harder to read

Used, tested, and fixed.

What does do-ocracy mean in The Apache Way?

Apache Way 中的 do-ocracy 是什么意思？

1 2	答案： The more you do, the more you are allowed to do.

抛开纯粹的被动反应，事情的实际发展方向通常是由开发者的工作来决定，而不是由任何宏伟的计划决定。如果你干了具体的活，那么实际上是你控制事情的发展方向。如果您需要某些东西，那就去实现它。这种方式偶尔用笨拙的英语-希腊语混合词 “ do-ocracy ” （“干活者掌权”——译者注）来描述。我将其称为 “ Pratocracy ”，即“创客法则”。它既适用于 Apache 核心团队，也适用于更广泛的社区。

(应该不考)

What does WIP mean in Kanban? Why is it important to have a WIP limit?

WIP 在看板中是什么意思？为什么设置 WIP 限制很重要？

答案：
WIP: Work In Progress.

Keep the team focused on accomplishing small tasks (goals) within their capacity.  Avoid work overload.  Avoid bottleneck.

在敏捷开发中，WIP限制决定了每种情况下的工作流中可以存续的最大工作量。限制进行中的工作数量可以更容易辨识团队工作流中的无效工作。在情况变得更糟前，一个团队的持续交付通道中的瓶颈是非常容易辨别的。

WIP限制通过强制让团队聚焦在更小的一套任务中来改善吞吐量和减少“将要完成”的工作量。从根本上来讲，WIP限制鼓励的是“完成”的文化。更重要的是，WIP限制让阻碍和瓶颈显而易见。当有明确指示现有工作遇到瓶颈时，团队可以聚焦在阻塞问题上尽快的理解、实施和解决。一旦消除阻塞，团队中的工作将再次开始流动。这些优势可以确保在最短的时间内向用户交付有价值的增量，从而使得WIP限制成为敏捷开发中一个非常有价值的工具。

Given the following releases of software, LRR 1.0, LRR 0.9, LRR 0.9 Alpha, LRR 0.9 Beta. Order them by time (oldest first).

鉴于以下软件版本，LRR 1.0、LRR 0.9、LRR 0.9 Alpha、LRR 0.9 测试版。按时间排序（最老的在前）。

答案：
LRR 0.9 Alpha
LRR 0.9 Beta
LRR 0.9
LRR 1.0

LRR 0.9 Alpha -> LRR 0.9 Beta -> LRR 0.9 -> LRR 1.0

Alpha：预览版，或者叫内部测试版；一般不向外部发布，会有很多 Bug；一般只有测试人员使用。

Beta：测试版，或者叫公开测试版；这个阶段的版本会一直加入新的功能；在 Alpha 版之后推出。

RC(Release Candidate)：最终测试版本；可能成为最终产品的候选版本，如果未出现问题则可发布成为正式版本

多数开源软件会推出两个RC版本，最后的 RC2 则成为正式版本。

应用题

Feature-branching workflow and Pull Request. You are going to manage the online web application, Lab Report Repository (LRR). The central, remote project repo of LRR is hosted at https://github.com/lanlab-org/LRR.git.

功能分支工作流和拉取请求。您将管理在线 Web 应用程序——实验室报告存储库 (LRR)。 LRR 的中央远程项目存储库托管在 https://github.com/lanlab-org/LRR.git。

You are asked to add a new feature X to LRR and use the feature-branching workflow, please describe each step. Make sure that you also include git commands.

您被要求向 LRR 添加新功能 X 并使用功能分支工作流程，请描述每个步骤。确保您还包含 git 命令。

答案：
[1] Clone LRR: git clone https://github.com/lanlab-org/LRR.git
Change directory to LRR: cd LRR
[1] Make a new branch:  git checkout -b X
[0.5] Edit files, stage and commit:  git add. &&  git commit -m "file changed: specific messages (what & why)"
[0.5] Sync with the master branch: git pull origin master
[1] Push the new, local branch X to the remote, central repo: git push origin X

Refer to the following link for more detail: https://github.com/spm2020spring/TeamCollaborationTutorial/blob/master/team.rst

[1] 克隆 LRR:git Clone https://github.com/lanlab-org/LRR.git
将目录更改为 LRR:cd LRR
[1] 创建一个新分支：git checkout -b x
[0.5]编辑文件、暂存和提交：git add. && git commit-m "file changed: specific messages (what & why)"
[0.5]与主分支同步：git pull origin master
[1] 将新的本地分支X推送到远程中心repo:git Push origin X
有关详细信息，请参阅以下链接：https://github.com/spm2020spring/TeamCollaborationTutorial/blob/master/team.rst

What is the main purpose of Pull Request?

拉取请求的主要目的是什么？

1 2	答案： Ask people to review changes and merge them to the project (if OK).

“拉取请求”是一种机制，用于表示一个分支的更改已准备好合并到另一个分支中。它们为利益干系人提供了审查和讨论提议的更改的机会，以确保基础分支中的代码质量尽可能地保持最高。

What should you do if you see a comment from other people in your Pull Request?

如果您在 Pull Request 中看到其他人的评论，您应该怎么做？

1 2	答案： Respond to it and address it as soon as possible.

尽快回复并解决。

What is the most important message the following figure conveys? How could reviews in Pull Request help improve software’s internal quality?

下图传达的最重要的信息是什么？ Pull Request 中的评论如何帮助提高软件的内部质量？

答案：
Software of high internal quality is less costly to build, in the long
run.  Producing software of high internal quality is more productive,
in the long run.

Pull Request is where our changes to software will be reviewed by
other people before they become a part of the software, and addressing
the constructive comments (e.g., pointing out a potential bug) raised
by the reviewers could improve software's internal quality.

从长远来看，内部质量高的软件的构建成本较低。长期来说生产内部质量高的软件效率更高。

拉取请求是我们对软件的更改将被审查的地方其他人在他们成为软件的一部分之前，并解决提出的建设性意见（例如，指出潜在的错误）由审阅者可以提高软件的内部质量。

Automated regression testing. As a software project manager, you want to ensure that your team’s new changes to software do not break existing functionalities, so you ask your team to run regression testing for every non-trivial change they made. If breakage occurs, you get a regression. Here is an example of regression: adding a new, working feature makes several old features stop working.

自动化回归测试。作为软件项目经理，您希望确保您的团队对软件的新更改不会破坏现有功能，因此您要求您的团队运行对他们所做的每个重要更改进行回归测试。如果发生破损，您将得到回归。这里是回归的一个例子：添加一个新的、有效的功能会使几个旧的功能停止工作。

Why is automated regression testing important? Answer this question in terms of the consequences of not having automated regression testing.

为什么自动化回归测试很重要？回答没有自动回归测试的后果。

1
2
3

答案：
Without automation, testing capacity could be quickly overwhelemed.
如果没有自动化，测试能力可能会很快被夸大。

自动回归测试将大幅降低系统测试、维护升级等阶段的成本。

In which scenarios do you expect to get most from automated regression testing? Give one scenario.

您希望在哪些场景中从自动化回归测试中获得最大收益？给出一个场景。

答案：
- Code change is frequent and we need to check that each change does not break old functionalities.
- Refactoring.
- The web application has lots of functionalities.
- The web application has lots of forms to fill in.
- Manual testing is boring.
- Testing takes long time to execute. - Quick feedback about the testing results.
 
 - 代码更改很频繁，我们需要检查每个更改是否不会破坏旧功能。
 - 重构。
 - Web 应用程序具有许多功能。
 - Web 应用程序有很多表格需要填写。
 - 手动测试很无聊。
 - 测试需要很长时间才能执行。
 - 关于测试结果的快速反馈。

The following table compares the time required to run manual testing and the time required to run automated testing. After how many repeated testing on the Post new assignment functionality will you see overall time saving by using automated testing instead of manual testing? Please give a number. Briefly describe how you derived this number. Note: you can assume that manual testing needs zero extra preparation time, while automated testing requires us to prepare a testing script first. Overall time saving is achieved when the accumulative time spent by using the automated solution is less than the accumulative time spent by using the manual solution.

下表比较了手动测试所需的时间和自动化测试所需的时间。在对 Post new assignment 功能进行多少次重复测试后，您会看到使用自动化测试而不是手动测试节省了总体时间吗？请给出一个数字。简要描述你是如何得出这个数字的。注意：您可以假设手动测试需要零额外的准备时间，而自动化测试需要我们先准备一个测试脚本。当使用自动化解决方案花费的累计时间小于使用手动解决方案花费的累计时间时，可以实现总体时间节省。

LRR functionality	Manual	Automated	Time spent on writing the automated testing script
Sign in	37 secs	13 secs	26 mins
Post new assignment	59 secs	24 secs	14 mins

答案：
Let number of repeated testing be N.
     Overall time spent on automated testing - Overall time spent on manual testing  = (14 * 60 + 24 * N) - 59 * N = 840 - 35*N < 0.
     When N > 24, overall time spent on automated testing will be less than overall time spent on manual testing.
     Therefore, it will be worthwhile to use automated testing if the number of repeated testing is much greater than 24.
     
设重复测试次数为 N。
自动化测试总时间 - 手动测试总时间 = (14 * 60 + 24 * N) - 59 * N = 840 - 35*N < 0。
当 N > 24 时，花费在自动化测试上的总时间将少于花费在手动测试上的总时间。
因此，如果重复测试的次数远大于 24，则使用自动化测试是值得的。

2019年春季期末考试

判断题

A license provides protection to software. A software license is usually issued by the government.

许可证为软件提供保护。软件许可证通常由政府提供。

错（软件许可是软件发布者和最终用户之间的协议合同）
The Project Management Committees (PMCs) at the Apache Software Foundation (ASF) have great autonomy when setting per-project policy.

Apache 软件基金会 (ASF) 的项目管理委员会 (PMC) 在设置每个项目的政策时有很大的自主权。

对
A bug tracker tracks bugs only. Don’t add feature requests to a bug tracker. They will pollute it.

错误跟踪器仅跟踪错误。不要向错误跟踪器添加功能请求。他们会污染它。

错
A project manager needs the sharpest programming skills.

项目经理需要最敏锐的编程技能。

错
Praise and criticism can be diluted by inflation. Detailed, dispassionate criticism is often taken as a kind of praise. Most people respond pretty well to technical criticism that is specific, detailed, and contains a clear (even if unspoken) expectation of improvement.

赞美和批评可以被通货膨胀冲淡。详细的、冷静的批评往往是作为一种赞美。大多数人对具体的技术批评反应很好，详细，并包含明确的（即使是不言而喻的）改进期望。

对
Benevolent Dictatorship (BD) won’t work well as a means of governance in open source projects. Consensus-based democracy is preferred.

慈善独裁者（BD）在开源中不能很好地作为一种治理手段项目。以共识为基础的民主是首选。

错
Meritocracy is a key part of The Apache Way. One has to contribute substantially to the project in order to become a committer (who has write access to the master copy of the source code).

Meritocracy 是 The Apache Way 的关键部分。一个人为了成为提交者（谁对源的主副本有写访问权限代码），必须要做出重大贡献项目

对（在Apache社区中谁有能力做这个事情，谁就去这个事情）

Opening a formerly closed project is an easy task.

打开以前关闭的项目是一项简单的任务。

错
Having many bug reports in your bug tracking system indicates that your software project is unlikely going to be successful.

在您的错误跟踪系统中有许多错误报告表明您的软件项目不太可能成功。

错
Bug tracking enables developers to plan releases.

错误跟踪使开发人员能够计划发布。

对

简答题

Technical debt. What is a technical debt? What is consequence of accumulating too many such debts?

**技术负债。什么是技术负债？积累太多这样的债务会有什么后果？ **

答案：
Technical debt is the debt incurred by taking shortcuts instead of using a proper approach.
Maintenance would become costly, or even impossible, if we don't payoff the debt in time.
技术负债是因走捷径而不是使用正确方法而产生的债务。
如果我们不及时还清债务，维护将变得昂贵，甚至不可能。

技术负债指开发人员为了加速软件开发，在应该采用最佳方案时进行了妥协，改用了短期内能加速软件开发的方案，从而在未来给自己带来的额外开发负担。这种技术上的选择，就像一笔债务一样，虽然眼前看起来可以得到好处，但必须在未来偿还。软件工程师必须付出额外的时间和精力持续修复之前的妥协所造成的问题及副作用，或是进行重构，把架构改善为最佳实现方式。

Project parasites. What are the main characteristics of project parasites?

**项目寄生虫。项目寄生虫的主要特征是什么？ **

1
2
3

答案：
Contributing little to the project but taking a big amount of credits.
对项目贡献很小，但获得了大量学分。

Code review. Code review enables us to improve software quality and enhance interaction with other developers. When we review code, why should we focus on reviewing recent changes?

代码审查。代码审查使我们能够提高软件质量并增强与其他开发人员的互动。当我们审查代码时，为什么要专注于审查最近的更改？

答案：
It works better socially.Timely feedback for fresh changes is a great way to interact with people through confirming that what they do is seen and understood.People do their best work when they know that others will take the time to evaluate it.The recent change is also a good starter for familiarizing yourself with the code base.
There could be "new changes on older changes". (by Antonio Wilinata)
Recent changes are the most likely part to be unstable. (by Jamal Ait Boui)
它在社交方面效果更好。对新变化的及时反馈是通过确认人们看到和理解他们所做的事情来与人们互动的好方法。当人们知道其他人会花时间对其进行评估时，他们会做得最好。最近的变化也是熟悉代码库的良好开端。 
可能有“旧变化上的新变化”。 （安东尼奥·威利纳塔）
最近的变化是最有可能不稳定的部分。 （贾马尔·艾特·布伊）

Voting to move on. The ASF has a bit weired voting and veto process. When one votes -1, what does he want to express, and what other information must he provide?

投票继续前进。 ASX 的投票和否决程序有点奇怪。当投票-1，他想表达什么，他还必须提供什么信息？
1
2
3
答案：
Against the proposal.Provide a detailed explanation or better alternatives.
反对该提案。提供详细的解释或更好的替代方案。

Community-driven project management. “We worry about any community which centers around a few individuals who are working virtually uncontested.” Why does the ASF worry about the formation of uncontested individuals

社区驱动的项目管理。 “我们担心任何以几个几乎毫无争议地工作的人为中心的社区。” 为什么ASF担心无争议个体的形成

1
2
3

答案：
The "uncontested individuals" would form a territory in software project management, hampering open, collaborative software development.People will leave if they cannot influence the project.
“无争议的个人”会在软件项目管理中形成一个领域，阻碍开放、协作的软件开发。如果他们不能影响项目，人们就会离开。

Version control. Describe the purpose of the push command while interacting with github

版本控制。描述当与 github交互时，推送命令的目的

1
2
3

答案：
Upload local changes to the central repository hosted remotely on github.
将本地更改上传到 github 上远程托管的中央存储库。

Hacktivation energy. What is hacktivation energy for newcomers to a project?

黑客化能量。什么是项目新人的黑客化能量？

1
2
3

答案：
The amount of energy a newcomer must put in before he starts getting something back.
新人在开始取回某些东西之前必须投入的能量。

License. How to apply a license to your software application?

许可证。如何将许可证应用于您的软件应用程序？

答案：
1. State the license clearly on the project's front page.
2. Include the license (LICENSE or COPYING) in the software distribution itself.
3.  Include a short notice at the top of each software source file.
1. 在项目首页清楚地说明许可
2. 在软件分发本身中包含许可证（许可或复制）。
3. 在每个软件源文件的顶部包含一个简短的通知。

Looking for alternatives first. Why is it important to look at alternatives before we start a project?

首先寻找替代品。为什么在我们开始一个项目之前考虑替代方案很重要？

1
2
3

答案
If there are alternatives, we don't need to re-invent the wheel.Even if we have to (e.g., for educational purposes), we could learn something from them.
如果有替代方案，我们就不需要重新发明轮子。即使我们必须这样做（例如，出于教育目的），我们也可以从他们那里学到一些东西。

Noisy minority. What is the “Noisy Minority” effect? How to handle this effect?

喧闹的少数派。什么是“嘈杂的少数派”效应？如何处理这种影响？

答案：
A few people give the impression that there is a lot of dissent,by flooding the mailing list with numerous lengthy emails.
The best way to handle this effect is to point it out and provide supporting evidence showing how small the actual number of dissenters is, compared to those in agreement.
一些人通过大量冗长的电子邮件充斥着邮件列表，给人的印象是存在大量异议。
处理这种影响的最佳方法是指出这一点并提供支持证据，表明与同意的人相比，反对者的实际数量是多么的少。

Mailing lists for public communication. Read the following notice from the Apache Hadoop Project PMC and answer the following questions. “We ask that you please do not send us emails privately asking for support. We are non-paid volunteers who help out with the project and we do not necessarily have the time or energy to help people on an individual basis. Instead, we have setup mailing lists …” What are the benefits of using mailing lists for open source projects? In particular, compare mailing lists with QQ/WeChat as a means of technical communication.

用于公共通信的邮件列表。阅读来自 Apache Hadoop 项目 PMC 的以下通知并回答以下问题。 “我们要求您不要私下向我们发送电子邮件寻求支持。我们是帮助项目的无偿志愿者，我们不一定有时间或精力单独帮助人们。相反，我们设置了邮件列表……”使用邮件列表进行开源项目有什么好处？特别是将邮件列表与QQ/微信作为技术交流的方式进行比较。

答案：
It is a shared, permanent resource that is publicly accessible andsearchable.  It encourages user involvement.  It could divide into several more specific sub-lists, e.g., user, general, announce,dev, bugs, etc.  Many other subscribers, besides developers, could help answer questions.  They could even give good advice for the
project.
QQ/WeChat, or other instant messaging systems, could interrupt people's work flow. Typos, not well thought-out or even irrelevant comments could creep in, lowering the quality of discussion.Messages in QQ/WeChat are not archived, and private by design.
它是一种共享的、永久的资源，可公开访问和搜索。 它鼓励用户参与。 它可以分为几个更具体的子列表，例如用户、一般、公告、开发、错误等。 除了开发人员之外，还有许多其他订阅者可以帮助回答问题。 他们可以为项目给出好滴建议。
QQ/微信或其他即时通讯系统可能会打断人们的工作流程。 错别字、未经深思熟虑甚至无关紧要的评论可能会出现，从而降低讨论的质量。QQ/微信中的消息未归档，并且设计为私密的。

Release criteria. Johanna Rothman proposes in his 1998 article Of Crazy Numbers and Release Criteria to use the magic number 36 as a release criterion. That is, enter all software bugs into our bug tracking system, if there are less than 36 high-priority bugs, then we could release a beta version, and if we have closed all open high-priority bugs, then we could release an official version. Why does this approach make sense? Does the number has to be 36?

发布标准。 Johanna Rothman 在他 1998 年的文章 Of Crazy Numbers and Release Criteria 中提议使用幻数 36 作为发布标准。也就是把所有的软件bug输入到我们的bug追踪系统中，如果高优先级bug少于36个，那么我们可以发布一个测试版，如果我们已经关闭了所有开放的高优先级bug，那么我们可以发布一个正式版本。为什么这种方法有意义？数字必须是36吗？

答案：
It gives a sensible, clear, and tangible target so that people could make efforts to achieve it.
No, it can be any reasonable number, depending on the problem domain.
它给出了一个合理的、清晰的、切实的目标，以便人们努力实现它。
不，它可以是任何合理的数字，具体取决于问题域。

应用题

One commit, one change. Each git commit should be small and atomic

一次提交，一次更改。每个 git commit 都应该是小而原子化的

Benno Schulenberg, the current maintainer of the GNU nano editor, seems to follow the “one commit, one change” principle. Below is one of his recent commits to the GNU nano source code repository. What change did he make in this commit, and for what purpose? Does this change satisfy the small and atomic criteria?

GNU nano 编辑器的当前维护者 Benno Schulenberg 似乎遵循“一次提交，一次更改”的原则。下面是他最近对 GNU nano 源代码库的提交之一。他在这次提交中做了什么改变，目的是什么？这种变化是否满足小和原子标准？

author Benno Schulenberg <bensberg@telfort.nl> 2019-06-12 09:46:19 +0200
committer Benno Schulenberg <bensberg@telfort.nl> 2019-06-12 09:51:14 +0200
commit 189de5ee781fd11230c0412719582aba6e207d55 (patch)
files: suppress feedback when writing a temporary file

This fixes https://savannah.gnu.org/bugs/?56474.

Bug existed since commit 47770bd3 from two weeks ago.

1 files changed, 2 insertions, 1 deletions
diff --git a/src/files.c b/src/files.c
index c55c957..12046c2 100644
--- a/src/files.c
+++ b/src/files.c
@@ -1858,9 +1858,10 @@ bool write_file(const char *name, FILE *f_open, bool tmp,
						goto cleanup_and_exit;
			}
	}
- 	statusbar(_("Writing..."));
+ 	if (!tmp)
+ 			statusbar(_("Writing..."));
	while (fileptr != NULL) {
			size_t data_len = strlen(fileptr->data), size;

答案：
Change: he added an if statement, i.e., "if (!tmp)".
Purpose: suppress feedback ('Writing ...') when writing a temporary file.
Yes.
更改：他添加了一个 if 语句，即“if (!tmp)”。
目的：在写入临时文件时抑制反馈（'Writing ...'）。
是的。

In practice, though, I frequently saw big and entangled changes per comit. Below are two shortened examples from the commit history made by the students from my Software Project Management class:

然而，在实践中，我经常看到每次提交都会发生大而复杂的变化。以下是我的软件项目管理课程的学生制作的提交历史记录中的两个简短示例：

gymgym1212 committed on Apr 22
1 parent 4e7df8b commit 0cbbff55c15d563386ee06b54a67d141a26fdd30
Showing 156 changed files with 0 additions and 771 deletions.

M-michael-zhang committed on Apr 15
1 parent 6a039ec commit 5b4868ad29e6698b3992f6b10b23ba8c59ffe043
Showing 321 changed files with 101,415 additions and 55 deletions.

How many files were affected by M-michael-zhang’s commit on April 15? Why did that happen? What are the risks of having too many changes per commit?

M-michael-zhang 4 月 15 日的提交影响了多少文件？为什么会这样？每次提交有太多更改的风险是什么？

答案：
321 files were affected.
Reasons (any of the following):
      - Too many auto-generated files were included.
      - Big version change.      
      - Made many changes but did not commit regularly.
Risks (any of the following):
      - Nearly impossible for code reviewers/maintainers to understand so many changes.
      - Hard to backtrack one change.
      - Hard to write a concise commit message.
      - Could introduce new bugs.  Hard to find these bugs and their causes.
321 个文件受到影响。
原因（以下任何一项）：
       - 包含太多自动生成的文件。
       - 大版本更改。
       - 进行了许多更改，但没有定期提交。
风险（以下任何一项）：
       - 代码审查者/维护者几乎不可能理解这么多变化。
       - 很难回溯一个变化。
       - 很难写出简洁的提交信息。
       - 可能会引入新的错误。 很难找到这些错误及其原因。

Bug reports and fixes.

Developers rely on good bug tracking for their daily efforts on improving software quality. Also, project observers, who can be potential participants or supporters, would not take a project seriously if it dose not have a publicly-accessible bug database. Being able to read, analyze and respond to bug reports is crucial for a project’s success. Read the following bug report, bug discussion and bug fix. Answer the following questions. Hint: read the questions in the last page first.

错误报告和修复。

开发人员依靠良好的错误跟踪来提高软件质量。还有项目观察员，可以是潜在的参与者或支持者，如果项目没有可公开访问的错误数据库，则不会认真对待该项目。能够阅读、分析和响应错误报告对于项目的成功至关重要。阅读遵循错误报告、错误讨论和错误修复。回答以下的问题。提示：阅读首先是最后一页的问题。

bug #56023: savefile (^S) says "[Cancelled]" in nano-4.0 on an ARM
Submitted by: easyaspi314 <easyaspi314>
Submitted on: Thu 28 Mar 2019 07:47:47 PM UTC
Severity: 4 - Important Status: Fixed
Assigned to: Benno Schulenberg <bens> Open/Closed: Closed
--
Tue 16 Apr 2019 08:45:57 AM UTC, comment #14: by Benno Schulenberg <bens> Project Administrator 
In charge of this item.
The fix has been released in 4.1. Thanks for reporting.

Wed 03 Apr 2019 02:37:46 PM UTC, comment #13: by easyaspi314 <easyaspi314>
Or, maybe, you could try compiling with more compilers than just GCC...
Enabling -Wextra and doing a scan-build picks up on a bunch of potential bugs
including this one, which was picked up on without any extra flags.
Like, I admit I am biased towards Clang.
However, I’m not saying you should only compile with Clang, just try it out once in a
while because its warnings are often useful to avoid this nonsense. Clang kinda
focuses on warnings.
Plus, it comes with a decent static analyzer in scan-build.
I attached the log of ‘scan-build make CFLAGS="-Wall -Wextra -O2 -g".‘ on the
unmodified v4.0 release tag. If you run it directly it will create a HTML page you
can browse and it will show you the steps.
cppcheck and PVS Studio also picked up on the uninitialized variable usage. (PVS sees
NLS _("string wrappers") as variable format strings).
So it isn’t "oh I never would’ve picked up on it" it is "I didn’t use good enough
tools to check for bugs before I did a release."

-Wall on one compiler is not enough to pick up on even half of the bugs in your code.
(file #46710, file #46711, file #46712)

Wed 03 Apr 2019 01:03:36 PM UTC, comment #12: by Benno Schulenberg <bens> Project Administrator
In charge of this item.
(For completeness: nor with ’export MALLOC_PERTURB_=234’ nor with ’export
GLIBC_TUNABLES="glibc.malloc.perturb=234"’, nor with several other numbers, can I
make ^S fail on a nano from shortly before commit 7ad232d7. Tested on three
machines. So, even with malloc perturbation, I wouldn’t have caught my mistake.)
Sun 31 Mar 2019 10:02:21 PM UTC, comment #11: by Brand Huntsman <brand>
My x86 (32bit) Gentoo machine also has this problem.

Sun 31 Mar 2019 06:24:06 PM UTC, comment #10: by Benno Schulenberg <bens> Project Administrator
In charge of this item.
Of the machines that I tried nano on (two 64-bit, and three 32-bit), none of them
show the problem. And as far as I know none of them initialize memory to zero.
Hmm... On my previous machine, I had a setting that caused allocated memory to be
initialized to a random value. What was it called again? Googling a bit finds:
MALLOC_PERTURB_. I’ll have to start using it again; it would probably have caught
this issue.
Version 4.1 will be released in a week or two. There are a few more changes that I
want to make.
Sun 31 Mar 2019 04:43:27 PM UTC, comment #9: by easyaspi314 <easyaspi314>
I added a logger and choice is indeed garbage. It just happens to usually be positive
on my Mac.

Sun 31 Mar 2019 03:40:33 PM UTC, comment #8: by easyaspi314 <easyaspi314>
Well either way it is mucking with UB so it is incorrect.
It all depends on the compiler, compiler flags, and the system.
So yeah, we should release 4.0.1 pretty soon because it is definitely a bug.
Sun 31 Mar 2019 03:25:39 PM UTC, comment #7: by David Lawrence Ramsey <dolorous>, Project
Member
For the record, this problem was not limited to ARM chips, despite the commit message
and the recently-changed subject here. I’m running x86_64 (Slackware-current) and was
seeing this problem too. Maybe your x86_64 systems are patched to initialize things
to zero by default, but not everyone’s are.

Sun 31 Mar 2019 11:19:48 AM UTC, comment #6: by Benno Schulenberg <bens> Project Administrator
In charge of this item.
Applied and pushed to master, commit 7ad232d7.
(Although the ’choice = 0’ is not needed, I left it in for clarity.)

Sat 30 Mar 2019 10:36:46 AM UTC, comment #5: by Benno Schulenberg <bens> Project Administrator
In charge of this item.
Ow. I had seen only the original post, not all the activity afterward. Thanks for the
patch, will apply it tomorrow, first some other things to do.

Thu 28 Mar 2019 10:34:44 PM UTC, comment #4: by easyaspi314 <easyaspi314>
Here is the patch. It sets response and choice to zero.
I am just going to put it here, because it is not worth a new issue.
Somehow, GCC didn’t even pick up on this one even with -Wuninitialize, so I kind of
get why this made it into the release.
GCC’s warnings are sometimes lacking (and vice versa with Clang), so I think we
should probably do more checking across different compilers and analysis.
(file #46658)

Thu 28 Mar 2019 10:02:35 PM UTC, comment #3: by David Lawrence Ramsey <dolorous>, Project
Member
Exactly. For the record, this was broken back on Feb 20 by commit 0f9d60a. When that
commit split up one variable into two, the initialization of the original variable
was lost.

Thu 28 Mar 2019 09:21:13 PM UTC, comment #2: by easyaspi314 <easyaspi314>
Wait, Clang literally pointed out the bug for me.
files.c:2131:7: warning: variable ’response’ is used uninitialized whenever ’if’ condition is true [-Wsometimes-uninitialized]
		if ((!withprompt || (ISSET(TEMP_FILE) && exiting)) &&
			~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
files.c:2148:7: note: uninitialized use occurs here
		if (response < 0) {
			~~~~~~~
files.c:2131:3: note: remove the ’if’ if its condition is always false
		if ((!withprompt || (ISSET(TEMP_FILE) && exiting)) &&
			~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
files.c:2104:15: note: initialize the variable ’response’ to silence this warning
		int response, choice;
				  ^
				  = 0
Clang clearly doesn’t like this code.
Sure enough, initializing it to an unwanted number such as -1 results in a
"Cancelled" message.
I’ll make a patch.

Thu 28 Mar 2019 08:41:47 PM UTC, comment #1: by easyaspi314 <easyaspi314>
Update: Just updated Nano on my MacBook to 4.0 from Homebrew and it is not affected.
MacBook Pro (15-inch, Early 2011)/MacBookPro8,2
macOS Mojave 10.14
2.0GHz Intel Core i7 (I7-2635QM, Sandy Bridge)
I am going to try building from source.

Thu 28 Mar 2019 07:47:47 PM UTC, original submission: by easyaspi314 <easyaspi314>
Platform:
Android 9.0, Termux
LG G3 D851 - Qualcomm Snapdragon 801/Cortex-A15, ARMv7-A (32-bit)
Yes I am weird
I upgraded to Nano 4.0 from the apt repos, and whenever I do ^S on an existing file,
all I see is "[Cancelled]" and the file does not save. This only happens on existing
files, when saving a new file, it correctly prompts.
This isn’t an issue with the terminal capturing ^S or anything, as if I add, say,
‘bind ^W savefile all‘ to my nanorc, ^W exhibits the same behavior.
I’m going to try on a few other platforms as well as build from source later, but for
now, I just want to bring it up.

author Devin Hussey <husseydevin@gmail.com> 2019-03-28 17:28:47 -0400
committer Benno Schulenberg <bensberg@telfort.nl> 2019-03-31 12:57:27 +0200
commit 7ad232d71470cd8c4dc63aeb02f11c9e8df9ecdb (patch)
files: initialize a variable before referencing it

The lack of initialization caused a nasty bug on some targets (such as ARMv7) which
would make it so that ^S would just say "Cancelled".
While x86 (both 64 and 32 bits) seems to initialize ’response’ to zero or a positive
number, ARM does not, and there is usually a negative value in its place, which
triggers the ’if (response < 0)’ check and, as a result, the code says "Cancelled".
This fixes https://savannah.gnu.org/bugs/?56023.
Reported-by: Devin Hussey <husseydevin@gmail.com>
Bug existed since version 4.0, commit 0f9d60a3.
Signed-off-by: Devin Hussey <husseydevin@gmail.com>

Diffstat
-rw-r--r-- src/files.c 2
1 files changed, 1 insertions, 1 deletions
diff --git a/src/files.c b/src/files.c
index 84e3f68..fd54c16 100644
--- a/src/files.c
+++ b/src/files.c
@@ -2101,7 +2101,7 @@ int do_writeout(bool exiting, bool withprompt)

		while (TRUE) {
			const char *msg;
- 			int response, choice;
+ 			int response = 0, choice = 0;
			functionptrtype func;
#ifndef NANO_TINY
			const char *formatstr, *backupstr;

Who is the original bug reporter?

谁是最初的错误报告者？
What bug did he report, and for which version of nano?

他报告了什么错误，以及哪个版本的 nano？
How long did it take him to submit a patch after he reported the bug?

他在报告错误后花了多长时间提交补丁？
Who applied the patch to the nano source code repository for the next release? From the commit record, what is his role in the nano project?

谁在下一个版本的 nano 源代码库中应用了补丁？从提交记录看，他在nano项目中的作用是什么？
How many people have participated in discussing this bug?

有多少人参与了这个bug的讨论？
What are the advantages of using a bug tracker over using email for reporting and recording bugs?

与使用电子邮件报告和记录错误相比，使用错误跟踪器有哪些优势？

答案：
(1) easyapi314 or Devin Hussey
(2) The command '^S' failed to save existing files on an ARM platform. Or Bug #56023.
    Nano version 4.0.
(3) About 3 hours.
(4) Benno Schulenberg, the nano Project Administrator.
(5) 4.
(6) Any of the following:
    - All bugs are put at one publicly-accessible place.
    - Bugs are searchable as a shared record so the number of
      duplicate bug reports can be reduced.
    - The bug tracker is a good project status indicator.
    - Encourage more participation.
    - Record the bug handling process.
    - Standard and easy.
(1) easyapi314 或 Devin Hussey
(2) 命令'^S' 无法在ARM 平台上保存现有文件。 或错误 #56023。Nano 版本 4.0。
(3) 约3小时。
(4) Nano 项目管理员 Benno Schulenberg。
(5) 4.
(6) 下列任何一项：
     - 所有错误都放在一个可公开访问的地方。
     - 错误可作为共享记录进行搜索，因此错误的数量
       可以减少重复的错误报告。
     - 错误跟踪器是一个很好的项目状态指示器。
     - 鼓励更多的参与。
     - 记录错误处理过程。
     - 标准且简单。