初窥构建之法——记2020BUAA软工我的博客做业

时间 2020-03-09

标签构建 2020buaa buaa 我的博客繁體版

原文原文链接

项目	内容
这个做业属于哪一个课程	2020春季计算机学院软件工程(罗杰任建)
这个做业的要求在哪里	我的博客做业
我在这个课程的目标是	完成一次完整的软件开发经历并以博客的方式记录开发过程的心得掌握团队协做的技巧作出一个优秀的、持久的、具备实际意义的产品
这个做业在哪一个具体方面帮助我实现目标	经过邹欣老师的《构建之法》在开始团队项目前先了解清楚“团队”和“项目”

学会提出问题

第一次真正意义上的软件工程我的博客做业，要求是速读邹欣老师编著的《构建之法》，并提出5-10个问题。这个任务很是有趣，他不是传统的读书做业似的让同窗们写读后感，我想多是读后感这种东西比较偏向我的，并且大多的读后感实际上是对文章目录的总结，并无深度到某一个文字段落中去。可是，提出问题，一是同窗必需要真正深度到段落文字，二是强迫你在阅读的时候思考，没有思考就不会提出问题。在周舜钦：学习金字塔的误解中，做者为阅读这一学习行为进行了辩护，认为不少人经过读完以后能记忆多少来考察阅读的效果是不正确的，应该夹以考虑阅读的深度和广度，是否有在阅读的过程当中积极思考，参与讨论。对书本中不理解的地方提出问题，便是一种思考的方式。html

问题零：课程的打分是否合理？

参见《构建之法》—— 给任课老师和助教的建议linux

这堂课如何打分？很简单：把每次做业的表现分为N档，最优秀的几个同窗得满分，第2档的同窗得1/2的分数，第3档的同窗得1/3的分数，依次类推下去，这就是1/N的打分体系。迟交做业0分，不交做业倒扣分。就像下图实线显示的那样。虚线是传统的“你们都能及格”的分数分布，如此分布看似皆大欢喜，实际上是对优秀学生的极大不公。
git

为何是问题零呢？你们已经看出来，这个问题是在书中的正式内容开始以前的部分，甚至是 “给任课老师和助教的建议部分”，而不是关于软件工程的部分。可是我仍是想斗胆提出本身的质疑，这样的 1/N打分体系 是否合理？是否有走极端的嫌疑？程序员

首先，分档给分是有依据的，这里我也在arxiv上找到了一篇Grading by Category(GBC)关于讨论如何可以更好的给同窗不只仅是分数，而带有反馈。文中提到了三个关键点：github

分类标准是由学生的整体水平决定的，而不是事前给出的分数。如：应该是占当年学生的百分之多少，而不是达到了多少分。
先分类再给定分数，这也透露出分档不是最后的得分。
分类的标准是学生没作什么或者作错了什么，而不是作对了什么。
这里的分档给分，论文中也给出了例子，对于一道物理题，分了多达8个等级：

等级	缘由	占比
Q(4.0)	完整的回答，有清晰的步骤和整洁的做图	27%
M(3.5)	也是完整的回答，但可能在步骤或做图上出现一些瑕疵	6%
L(3.2)	大体完整的回答，但做图错误或表述不清	10%
C(2.5)	回答中对图片没有完整的定义，做图也出现错误或表述不清	6%
P(2.0)	知道回答须要的方程，并能知道方程的定义	14%
S(1.0)	知道回答须要的方程，可是并不能正确理解方程的含义	22%
N(0.5)	可以写出一些有意义的回答，可是没有完成题目	10%
Z(0.0)	物理意义和实际意义上的白卷	4%

论文的做者表示，经过给出细分的等级，有如下几点好处：编程

学生能够根据获得的等级快速定位到本身的问题，以致学生可以在将来的测试中根据本身等级对应的不足本身有目标努力。
学生更加关注的是本身没有作到什么，而不是本身作到什么，从而暴露出本身的不足和缺陷，去重视本身的缺陷。
老师在给分时能够三思，由于GBC评分方式是等到全部学生的回答都给定等级以后再进行细致的数值上的分数。这可让老师在给定具体数值分数的时候能够不须要从新审阅全部同窗的回答，而是在大致的等级区域内给出细致的分数，也不会让同窗获得比应得更低的分数。
GBC评分制度提供给了老师一个量化分析的手段，由于在给定等级的过程当中就已经对同窗们所犯的错误或者不足进行的分类，因此出现同一问题的同窗的比例就能够直接由该等级获得，从而进一步调整教学方式和教学重点。
GBC评分制度提供了一个更简便的 re-grade 方式。也就是说若是学生对于本身的成绩有异议，能够告诉老师本身的预期等级是多少，但学生在提出异议以前会先对本身进行一个等级上的评价，也就是将成绩的合理性的证实从老师的身上转移到了学生的身上，给对评分不满的学生提出了“自证”的要求。

论文做者经过实际践行这一方法获得了积极的反馈，学生们从各个角度都认同了这种等级制评分方式。bash

因此在这里，我想提出的问题就是，邹老师在《构建之法》中提到的 1/N 体系是否太过于仓促果断了，咱们能够按照分档给分的方式去衡量每一个人的做业，可是在衡量具体的做业以前就将对应的等级的分数给出，如1/2，1/3等等，是否有点对学生的工做不负责任？在这里我想表达的是，我相信每一个学生都是认真完成做业并在做业的过程当中带有本身的思考的，可能有些地方作的确实不是很完美，可是是否应该按照同窗在哪里作的不够好或者不足去具体的细分等级，而不是只要犯错就马上少了一半的分数，我相信这样一种“狼性文化”，会在同窗们刚开始的时候起到很好的竞争的效果，可是与此同时对于学生的打击也是巨大的。网络

也算是斗胆对课程组提出本身小小的建议，不妨尝试一下这种 Grade by Category的评分方式，能够给同窗们的做业按照不足进行分档，在等级内再进行细致的给分，我相信这会是一个不错的尝试。ssh

问题一：是否真的没有银弹

参见《构建之法》—— 第一章第2节分布式

CD/DVD上可是这些非本质、临时的特性并不能决定软件工程的本质问题。例如，有人发明了一种新的程序设计语言，或者又出现了一个新的软件开发流程，或者网上出现了又一个程序员技术社区……这些事并不能改变软件工程的根本难度，这也是著名的“没有银弹（No Silver Bullet）”论断所阐述的道理。软件的这些本质特性让“作一个好软件”变得很难，同时也让软件工程有它独特的挑战和魅力。

首先咱们看银弹是什么，根据维基百科上没有银弹的词条：
《没有银弹：软件工程的本质性与附属性工做》是IBM大型机之父佛瑞德·布鲁克斯所发表一篇关于软件工程的经典论文，该论述中强调因为软件的复杂性本质，而使真正的银弹并不存在；所谓的没有银弹是指没有任何一项技术或方法可以使软件工程的生产力在十年内提升十倍。
布鲁克斯在他的论述中将软件开发的困难分为两类，一是本质性的困难，是软件自己在概念（conceptual）建构上存先天的困难；二是附属性的困难，在于将概念上的构思施行于电脑上，所遭遇到的困难。并提出了四点形成本质性困难的缘由：

复杂性（complexity）：软件要解决的问题，一般牵扯到计算步骤，这是一种人为、抽象化的智能活动，多半是复杂的。
隐匿性（invisibility）：还没有完成的软件是看不见的，即便利用图标说明，也常没法充分呈现其结构，使得人们在沟通上面临极大的困难。
配合性（conformity）：在大型软件环境中，各子系统的接口必须协同一致。因为时间和环境的演变，要维持这样的一致性一般十分困难。
易变性（changeability）：软件所应用的环境常是由人群、法规、硬件设备、应用领域等，各因素所聚集而成，而这些因素皆会快速变化。

虽然布鲁克斯提出了四点困难的缘由，可是为了提高软件工程的生产力，也有许多人在奋力搜寻“银弹”的存在，如从汇编语言到高级语言，大幅提高了生产力，下降了程序员的编程门槛；分是技术的出现提高了人们工做的效率，经过时间片轮转等技术实现了程序的并行，同时不下降使用体验等等。

除了没有银弹的声音外，还有一些存在银弹的反响，其中以 Brad Cox 的《There is a Silver Bullet》和 Divid Harel 的《Biting the Silver Bullet》为主要论点。

我本身的观点是辩证地讨论这个问题，这个问题须要结合实际的现实而不是在任什么时候候均可以扬言——“没有银弹”。咱们知道软件开发的生产力不只被本质困难所影响，还被附属困难所左右。今天咱们之因此可以站在这里万众开发，就是由于先人们已经帮助咱们必定程度上解决了附属性困难。好比集成开发环境的产生使得全部人都能轻松运行和开发程序，好比面对对象编程的出现，使得全部人都可以在构建和开发时编写出更加理解易懂好维护的代码。因此说，Harel还提出的一项假象实验，将没有银弹的说法发表在再向前三十年的1952年而不是1986年，在当时的外部附属难度颇高的环境下，没有人会预料到后续的三十年内人们将附属困难逐一攻破，十年内软件工程的生产力提升十倍极可能成为现实。
其次，我也很是赞成Jones的观点——“把重点放在质量上，生产力将随之而来”。对于生产力的衡量不只仅是量还有质。Jones提出，缺少有系统的质量控制与发生时程落后的灾难，这二者之间有强烈的相关性。这就引出了咱们所须要学习和思考的如何对团队进行系统且有效的进度控制和质量控制。
我之因此对银弹是否存在持有怀疑态度是由于在大环境下，有一些本能够提升的生产力没有提升，还有不少团队会出现文档与实现分离的状况，出现进度卡在某一我的负责的环节的状况，这些状况都是咱们会在后续的团队编程中可能会遇到的，因此我以为如今就应该思考，如何在团队中破除没有银弹的诅咒，提高团队的总体水平和能力。

问题二：如何选择合适的团队模式

参见《构建之法》第五章第2节

体育团队从一窝蜂抢球演变到有明确的分工、阵型、战术的团队，须要时间。相似地，软件团队的模式，最初是混沌的一窝蜂形式：一群人开始写代码，但愿能写出好软件。随着团队的成熟和环境的变化，团队模式会演变成下面几种模式之一。

对于本学期的重头戏：Alpha 和 Beta 阶段的团队编程，心中既激动好奇又惴惴不安，之前历来没有进行过任何大项目开发的咱们，该如何打好第一次战役？
在团队的选择中，咱们首先是舍友三人组成了一个小的团体，一是对于你们的能力和责任心都比较放心，二是团队中大部分人相熟能够迅速在团队中破冰。后来加入了一位女生和两位男生，组成了6人的团队。可是问题是你们都没有从事过软件开发，这就给咱们的团队模式的选择带来了困扰。
结合咱们目前的状况来看，因为没有一个技术高手进行统领，比较实际的是在社区模式和业余剧团模式中进行选择，然而社区模式在个人理解下，是像Linux社区那样的，须要原先就具备必定的基础，结合一个成熟的审核团队进行质量控制，因此剩下的只有业余剧团模式，文中对于业余剧团模式的描述确实比较业余，在网络上也没有找到相关的描述，想请教老师和助教，业余剧团模式的具体形式可以结合助教的经历或是老师的观察给一个更加清晰的讲述吗？

问题三：每日例会的效果如何？

参见《构建之法》第六章第2节

天天这样写代码，咱们离冲刺的终点线究竟是更近了，仍是更远了？若是流于形式，不管多么敏捷的每日立会也会被忽悠[注释5]。一个改进是，定义好任务到底是什么？任务的完成（Done）到底意味着什么？每一个人的任务必须是明肯定义的，狗熊们不能笼统地说“我在掰棒子”，而是要说明标号为123的棒子如今是什么状态，你作好以后交给谁了。

在个人实习生活中，只遇到过周会，还没经历过紧张刺激的日会，天天完成的任务量有时候小到难以和前一天区分开的时候，咱们真正能从日会中得到什么吗？好比如今咱们除了软件工程以外，还有计算机网络、计算机网络实验，几乎每位同窗还有额外的两三门通常专业课，当时间真的一天18个小时不够用的时候，咱们的例会可能发言就变成了“我和昨天同样在掰棒子”甚至是“今天没有动代码”。我很是担忧咱们团队到了后期也会出现这种问题，我相信咱们的团队每个人都不是浑水摸鱼的类型，可是时间管理方面出现严重的缺陷时，咱们该如何应对？
这是我特别想向老师和助教请教的一个问题

由这个问题引伸出的一个问题：敏捷开始是不是一个伪命题？
在我阅读第六章的内容前，这个疑问一直在个人脑海，我观念里面的敏捷开发，就是三点：一是快；二是快；三仍是快。这种快速可能会带来质量上的损失，好比《构建之法》的图6-5，大量微博用户反映本身的微博丢失的状况。可是当我看到第六章最后的“酒后问答”，不少个人疑问都被老师一一解答了。
敏捷开发确实是快，可是并非只要参与了敏捷开发，本来工期长的项目就能够马上获得缩短，最后提早完成。用老师的回答来讲——“敏捷的方法能帮助你更早地知道你是否能如期完成任务，仅此而已。敏捷的方法（迭代的方式）能帮你尽快让用户看到项目的部分价值。当你尽早交付部分价值时，也许用户对你目前交付的东西已经很满意了，这样你就不用再花时间来实现其余需求。另外一种多是，用户看到了部分系统，他们有新的需求，这样你就能够实现新的需求，而不用再浪费时间实现过期的需求了。”
老师的回答和轮子哥在知乎上的回答有着殊途同归之妙。敏捷不是一群开发者对着甲方的初版需求猛作几天，而是在作的过程当中始终和甲方进行有效的、不间断的沟通，来帮助甲方更加清晰地认清本身的需求，也帮助整个团队肯定一个当前的完成进度，也就是一个迭代中的需求分析和验收。

问题四：为何除了微软不多见到Program Manager

参见《构建之法》第九章第1节

Program Manager：微软的职位名称。微软产品团队三足鼎立的角色分配就是PM、开发、测试。PM负责除产品开发和测试以外的全部事情。从某种意义上说，是前面两种角色的综合。微软一般有专门的产品策划（Product Planner），他们和市场部门的专职人员一块儿，负责产品的长期发展和市场推广。

在第九章中提到了PM，有三种含义，分别是 Product, Project和 Program Manager。做者也在书中提到，其中的Program Manager 是微软的三驾马车之一，另外两个分别是测试和开发。我又在网络上搜寻了有关Program Manager的资料，发现这个程序经理依然是微软的特点之一，不由思考，为何其余的公司不效仿微软，将Product Manager 升级为 Program Manager呢？

对此，我首先看了一下微软的员工眼里二者的区别，其中，做者说道：“最基本的一条是程序经理不承担人员和资源的管理任务。微软一般把技术路线称为Individual Contributor，而把管理路线称为Management。而程序经理在职业规划上属于前者。” 此外，该做者还总结了程序经理的任务：

负责和提出需求的客户打交道，而且负责撰写功能规范，也就是Product Feature Spec。
协调部门间的合做关系。

可是在看了这些资料以后，我还不是特别可以区分开二者的区别，但愿老师和助教可以给我提供一个具体的样例，即程序经理有什么是产品经理作不了的，有什么是产品经理能作而程序经理作不了的，有没有除了微软的其余公司也设立了 Program Manager 这一个职位，这家公司和微软有什么类似的地方？

问题五：对于小团队而言小强地狱是否可行？

参见《构建之法》第十一章第5节

随着项目的深刻，每一个人同时既要开发新的功能，也要修复之前的缺陷。因为没有明确的优先次序，通常人都愿意把时间花在开发新功能上。可是咱们的确须要平衡进度和质量。有这样的一种方法：小强地狱（Bug Hell）。若是开发人员的小强（Bug）数量超过一规定值，则此君被送入“小强地狱”，在地狱中，他惟一能作的就是修复小强，直到小强数量低于此阈值。这一阈值由团队根据实际状况来肯定，要注意：开发人员同时“入狱”的人数应在全体成员的5%——30%之间，若比例过高，则要考虑阈值或小强数量的计算方式是否合理（是否只包括某一严重程度以上的Bug）。在项目过程当中，阈值不宜频繁调整，最好事先宣布阈值。

从这个团队的例子中咱们能够看到不少人身上的影子——如何处理待开发的新功能和已存在的Bug？相信不少人在编写C/Cpp程序的时候，都会先写完全部功能，而后再进行覆盖性的测试，去找出全部的bug。可是当咱们是以一个团队的身份开发一个项目的时候，不一样点在于咱们再也不是单打独斗，咱们有专门的一部分人负责测试工做，若是像书中的例子同样开发人员也是一味追求新功能而将本身的bug都藏着掖着，就会致使测试人员进度了等待的状态。
这里提到的小强地狱确实很美好，他将每一个人产生的小强的个数限定在一个提早设定好的阈值以内，每一个人的bug数目只要达到阈值就要开始专门的修复bug阶段。这种方案对于大型团队而言不容置疑是高效的，可是对于一个小型团队而言，这种小强地狱的方案是否会对整个项目的进度带来严重的影响？或者咱们是否能够让测试也承担起一部分修缮bug的责任？

网络上对于小强地狱这种工做方式寥寥无几，因此但愿有丰富的经验的老师和助教们能以自身的经历或者见闻解答一下个人这个疑惑——“小强地狱对于小型开发团队团队而言适合吗？若是不适合，有什么其余的适合方案呢？若是适合，如何解决开发至多三人带来的团队进度被影响的问题呢？”

问题六：迷思之六：技术的创新是关键？

参见《构建之法》第十六章第1节

铱星有用户么？固然有，那些爬山运动员，在南极科学考察的人士，想只身驾船周游世界的孤胆英雄们，他们但愿有一部这样的电话。可是这样的用户在全世界有多少呢？铱星电话如今变成了一项租赁业务，为这些几千、几万的用户提供短时间服务。与此同时，全世界的手机用户早已突破了10亿。

做者在这里举出的例子是铱星计划(Iridium)的手机，论述的是铱星计划虽然有技术的创新可是没能成功，在这里我有一点小小的疑惑。由于对铱星计划不是很是了解因此就查了一下。

对于摩托罗拉的工程师巴里·伯蒂格来讲，它来自于妻子在加勒比海度假时的抱怨，说她没法用手机联系到她的客户。回到家之后，巴里和摩托罗拉在亚利桑那州工做的卫星通讯小组的另外两名工程师想到了一种铱星解决方案——由77颗近地卫星组成的星群，让用户从世界上任何地方均可以打电话。因为金属元素铱有 77 个电子，这项计划就被称为了铱星计划，虽而后来卫星的总数降到了 66 个。
——来自百度百科对铱星计划的介绍。

我分享一下个人感觉：技术的创新我依然认为是关键，铱星计划的失败只不过是没有把握住最好的时机。若是铱星计划可以早那么10年，我相信又是另外一幅格局。用户基数一旦造成就难以撼动，不是技术不够创新，而是很大程度上因为人的惰性形成的，人们不肯意踏出温馨区去为了一点点微小的利益而改变，假若摩托罗拉的铱星计划可以比基站通讯更早地俘获大量的用户而且稳定用户，我相信铱星计划仍是可以成功的。并且铱星计划也没有彻底失败，说不定在将来又有他的出彩之处，若是可以基站和铱星结合起来，相互补充，我相信这将是通讯历史上浓墨重彩的一步。

问题七：最难的问题——排座次

参见《构建之法》第十七章第3节

一群人在一块儿作事，事成以后，就有排座次、论功劳的问题——在有些团队里，事成以前就为功劳的事吵翻了。软件团队如何作人员的绩效管理？这个问题较难回答，由于全部人的工做被集成在一个软件产品中，互相依赖，产品功能受到用户赞赏或批评，都不能简单地彻底对应于某一我的的工做。

在《构建之法》的最后一章的内容中，仍是提到了没法回避的问题，如何给团队里面的人排座次。做者经过多个角度论证了座次的排列不能但从一个角度，而是多个角度一块儿考虑的结果。最后给的二维评价考核表特别有趣，我以为是一种很是新颖并且值得尝试的方式。可是这些方式都是一些比较偏理论的，那若是在好比咱们这种软件工程的课程里面，和同年级的同窗组成的小组里面进行贡献度分配的时候，有什么具体的实用的方式吗？我也参考了知乎上的回答，可是上面所罗列的 KPI （Key Performance Indicator）关键业绩指标法、BSC（Balanced Score Card）平衡记分卡、OKR （Objectives and Key Results）目标与关键成果法和 360度考核法虽然特别完善和强大，可是对于小型团队而言彷佛又太过于专业化了，并且会带来额外的巨大的工做量，因此想请教一下助教们，当初大家在完成软件工程这门课的最后是如何进行小组内的考核评比的呢？

“软件” 和 “软件工程” 这些词汇是如何出现的 - 什么时候、何地、何人？

软件：从维基百科中能够看到“软件”一词最先在 Turkey 于 1958 年所发表的 "The Teaching of Concrete Mathematics" 一文中被使用。

软件工程：在对Margaret Hamilton的专访中，咱们得知，是她在编写阿波罗登月计划的项目期间创造的软件工程一词。Margaret Hamilton 致力于为软件以及那些发明者争取应有的正统性与尊重，因此开始使用“软件工程”这样的字眼来将之与硬件还有其余工程学类作出区别。

关于软件工程的小故事

世界上第一个计算机病毒

世界上第一个病毒是由巴基斯坦兄弟俩巴斯特（Basit）和阿姆捷特（Amjad）在1987年写下的，但他们写出这个病毒并非为了去损害别人的利益，偏偏相反，是为了维护本身的利益。
两兄弟开了一家电脑公司，主要经营电脑和软件业务。刚开始的时候公司经营很是好，生意兴隆，可是慢慢的，市面上浮现出了盗拷的行为，致使他们辛苦写的程序被别人普遍传播，因而兄弟两人从父亲往鱼塘里面丢树枝防止别人撒网偷鱼的作法中获得了灵感，编写了第一个病毒软件。一旦他们的发行程序被盗拷，这个病毒就会在计算机中发做，将盗拷者计算机剩余的内存空间所有占据，这使得很多盗拷的人由于计算机没法使用来向他们认错，请求他们帮助修复计算机。他们一不留神写下了世界上第一个病毒，人类与计算机病毒之间的较量由此展开。

Linus & Git

参考资料：Linus 在 2007 年 Google Talk 上介绍 Git

Linus 相信没有学习计算机专业的人不认识的，独自开发Linux系统，开发了Git源程序管理软件，性格乖戾脾气暴躁，都是他的tag。2005年的时候，Git还没诞生，Linux内核代码托管在 BitKeeper 上，Linus 本人对 CVS 十分厌恶，可是对 BitKeeper 钟爱有加。他认为 BitKeeper 的工做流和分布式等理念是值得学习和尝试的。可是因为 BitKeeper 是一款商业软件，Linux 是一款开源的工做，为了防止状况的恶化(此处也没找到具体的是什么恶化)，于2005年的时候 Linus 发布了 Linux-2.6 ，因而开始本身开发一个 BitKeeper 的替代品。也就是说，若是不是BitKeeper 和 Linux 的一些不合，可能你们就不能看到 Git 的诞生了。对于Linus 给软件的起名也特别有趣，Linux系统是Linus一开始起的名字，在发布的时候Linus曾经想过换一个名字，可是被旁人制止，以为使用本身的名字做为一款系统的名字比较有意义。而对于第二款Source Code Management 源代码管理工具——Git，则是英国俚语中“坏小子”的意思，Linus也曾经说过，本身是一个傲慢的混蛋，因此他的创做都用本身起名，Git也不例外。

源程序管理软件和项目管理软件调研

软件	使用人数	优势	缺点
Git	Unknown	1. 分布式 2. 轻量 3. 能够和其余仓库(如 GitHub GitLab Gitee)结合使用 4. 能够随时随地离线使用，联网时再update	1. 上手困难 2. 出现误差时难以纠正 3. 指令太多，部分指令的表现与理解存在误差
GitHub	31,000,000	1. 是当前最大的开源免费代码仓库，如今private仓库也无偿使用 2. 提供开发者一个交流合做的平台，经过pr和issue帮助拥有者维护开源程序 3. 还提供了发布的模块给开发者进行发布的版本管理	主要适合于代码的追踪，而不适合创意的记录
Bitbucket	5,000,000	1. 一直提供无限免费私有仓库 2. 对hg和git都支持 3. 支持中文 4. 第四方的git工具SourceTree比GitHub for Windows好用	1. 功能相比Git少不少 2. 对于开源不够完全
Mercurial (hg)	Unknown	1. 学习门槛低，比git容易上手 2. 可以实现彻底回到某个历史版本 3. 具备SVN的影子，对SVN用户友好，零学习成本	1. 分支管理不灵活，对于大一些的团队项目会形成权限混乱 2. 分支种类过多，匿名分支法、具名分支法、书签法、克隆版本库法等等，不方便使用 3. 没有命名空间，团队中谁提交的代码搞不清楚
Trac	Unknown	很是灵活，能够为所欲为控制能够和SVN集成	功能不是很强大
Bugzilla	Unknown	免费，有中文版支持	快速搜索结果不许确。只能管理缺陷。
Microsoft TFS	Unknown	1. 微软出品，和Visual Studio深度结合 2. 任务版内容详尽，有需求和任务进度等，对小团队而言更加方便有效 3. 集成了项目管理、版本控制、BUG 跟踪等特性	1. 上手困难，搭建和维护TFS复杂 2. 基于ASP实现，访问相比而言慢一些

源程序管理软件上手实践

Git

首先确定是最经常使用的 Git：

Git 是 Linus 为了更好的控制本身的 Linux 源代码的管理而创新出来的管理工具，其核心思想是充分的分布式，特性之一是容许离线操做。Git 经过将工做区分为三棵树的方式来管理本身的代码进度。
第一棵树是本身的 工做空间，修改代码确定首先是在本身的工做空间发生变化；
第二棵树是 暂存区，是一个临时保存的区域，须要经过 git add file/dir 的命令来将本身的工做空间中的修改保存到暂存区；
第三棵树是 HEAD，始终指向最后提交的结果，运行 git commit -m "explanation words" 来说暂存区下的修改提交到 HEAD上；
三棵树保证了Git是一个能够本地离线运行的源程序管理工具，开发者能够随意回到以前的任意一个 commit 的版本中去。
最后在在线的状态下，能够经过 git push 将本地的HEAD提交到远端的仓库中，保存本地的修改。

这种思想对于初学者来讲简直就是灾难。我在一年前学习面向对象和操做系统的时候才开始接触Git，一开始上手太难理解为何要构建三棵树了，以为为何不直接本地保存而后同步到线上呢？但随着使用的时间的推移也发现了这种构建的好处，特别是能够回到任意一个commit是开发者的福音。还有 Git 的 branch 也是对于项目开发特别友好的设计，能够生成 Debug、Release、Develop 等等分支，在分支上进行为所欲为的操做，都不会对主分支形成任何的影响。
今年有幸担任了面向对象课程的助教，在第一周的上机实验中，从学弟学妹们的身上看到我本身的身影。~~没有经历过 git push 不被容许的报警是不完整的~~ 不少人一个实验两个小时也完不成基本的 Git 操做，要么在分支上出现了问题，要么在关联的远端仓库上出了问题，要么在ssh_key 上出了问题，等等等等。
若是单纯可以使用 Git 的话，学习而且使用一段时间就熟练了，但要是想完全弄懂 Git，估计须要 Linus 的智商吧。

Mercurial(hg)

既然 Git 这么劝退，咱们就尝试一下听说门槛低，较易上手的 Mercurial。
关于 Git 和 hg 的对比，为何 hg 比 Git 好上手，这个博客是我找到的最完整的介绍。

尝试了一下子 hg，注册了 BitBucket 的帐号，但发现貌似 BitBucket 如今全面支持 Git 了，半天愣是没有找到如何使用 hg 初始化仓库，因而从 hg Guide 中 clone 了一个hg说明书的仓库使用。
在已经对 Git 熟悉以后，对 hg 上手是特别快速的，要说有什么特别的地方，hg 也有本身的 hg addremove xxx 和 git add xxx 很是类似，二者的 commit 都是同样的，可是通过个人查阅以后发现，是由于我如今的仓库规模不够大因此感觉不到 hg 的方便之处。
hg 的优点通过总结有如下几点：

hg 给用户的信息较为友好、轻便。好比 hg log 查看日志的功能就特别简单清新，好比：
```
changeset:   0:2b106112869d
 user:        q2l
 date:        Sun Mar 08 01:59:07 2020 +0800
 summary:     add one add three
```
与 Git 的 SHA-1 编码制做的 commit_id 相比显示简单，但这里 Git 里面蕴含了 Linus 的我的的执念——“经过SHA编码可让你将来任什么时候候都能回到你想要的任意一个版本”。
hg 提供了不少继承的命令，好比 hg update, hg ci, hg serve 等等，能够直接使用，其中我尝试了如下 hg serve，若是仓库是网站，能够直接部署到 localhost 上，若是不是网站则能够来显示这个仓库的有关信息，好比可视化的 branch 和 commit 等等。

可能对于每一个人的习惯不同选择的工具也是不同的，在查阅hg 和 git 的对比和优缺点的时候，既有放弃hg转向git的，也有从git到hg的，但如今整体的大趋势是更多的源代码管理仓库偏向git，好比 bitbucket、github、gitlab，而hg已经被 Atlassain 收购，主要和 Atlassain下的工具进行集成。总之选择本身喜欢的就行，也不是有不少喜欢 Git 的死对头 CVS 吗？