[2017BUAA软工]第一次博客做业

1、一些疑问

　　看书看得比较慢，暂时只思考了如下几个问题，有些自问自答，不知道符合不符合要求……

 

【1】

　　第一章中书上提到了这样一个例子：

　　“若是一架民用飞机上有需求，用户使用它的几率是百万分之一，你还要作这个功能么？”

　　对此我有个问题：若是这个功能和飞机的安全性能无关，那么还须要实现这个功能吗？

　　我一开始的想法是，是否实现这个功能是要根据价值指望（被使用的几率*它的重要性）来决定，对于安全功能，即使它被使用的几率很小，可是它的重要性很高，所以价值指望也就很高。可是后来我考虑到，实现一个功能须要一系列代价，包括开发精力、对运行速度的影响、对稳定性的影响等等……若是飞机的安全保障须要花费庞大的人力和财力（比目前的还要再高很多），这个功能真的还会被应用吗？

　　我大概想了一下，若是被应用了，多是如下这个路线：

　　机票价格上升→大众负担不起→客户减小→公司破产……

　　这可能有点夸张，可是我正想用此表达个人疑问：开发成本和产品安全性之间应该如何抉择？我认为在这种状况下，产品安全性的地位不是绝对的，只要不虚假宣传，买不买机票是乘客说得算的。若是乘客认为不值得花费更高的金额去换取百万分之一的安全，他有权利选择价格更低的机票。因此最好的办法或许是造出两种飞机（就好像经济舱和商务舱），让乘客决定哪种更适合本身。实际上如今不少软件也分为“社区版”和“专业版”，后者比前者功能更强大也更稳定，可是要贵得多，不知道这和上面的例子有没有关系呢……？

 

【2】

　　第二章中提到了用“单元测试”去检测代码的正确性，对此我有个疑问：单元测试的正确性应该如何保证？是否还须要写一个单元测试去检测单元测试呢？

　　我查了资料[1]，博文做者提到了“TEST FIRST”的观点，这一点在《构建之法》中也有说起。在开发以前先设计测试代码的的好处是，测试代码能够更加灵活、清晰，在不受到开发代码制约的同时，也为后面的开发明确了思路。与此同时，做者还强调测试应该针对需求进行，不该该涉及别的类，这却是省了些工夫，但我我的感触不是很深，以前总感受测试代码越详细越保险，不知道做者的想法是否有可取之处。总的来讲，做者的观点是对于开发人员，测试要针对需求，更加细致的测试是测试人员干的事情。那么也就是说OO还有此次软工我的做业的测试是为未来从事测试方面的工做打下基础？仍是说这也是开发人员应该掌握的技能呢？

 

【3】

　　程序的可扩展性与运行速度应当如何取舍？就拿这一次做业来讲，我是采用了在模板上变换的作法来生成数独，这样的优势是很快，可是缺点是生成的数独具备很大的共通性，算不上实用。若是后期老师又要求生成一亿个数独甚至更多，这种套路恐怕难以适用。

 

【4】

　　第四章书上特地提到了“只要有助于程序逻辑的清晰体现，什么方法均可以使用，包括goto”。可是已经有人证实过goto语句的没必要要性，并且自从大一开始学习c语言以来，老师、学长一再强调不要使用goto，会形成代码可读性降低，这一点和书上所写的不是矛盾的吗？

　　后来去了一些论坛看了看，发现使用goto的人好像也很多，毕竟存在即合理，可是使用goto的人都遵循着一个原则——不影响程序的顺序性，也就是说goto只能用于向下跳转，不能向上跳转。通常状况下，goto语句多被用于跳出多层循环，这一点我也在此次数独做业中进行了尝试，感受仍是很方便的。

　　可是让我不太明白的是，goto这种不被推荐的用法，有时候也能找到它的“用武之地”，那么若是团队明确规定“不容许使用goto语句”，这是否是一个合理的作法呢？这让我想到了不少团队都对一些代码规范进行严格的规定，好比大括号必定要换行，必定要用四个Space代替Tab等等……这些代码风格常常能成为论坛中的“引战帖”，能够看出各有优劣，那么强硬地要求使用某一种代码风格有没有必要呢？

 

【5】

　　第五章开头，做者强调了“团队”与“非团队”的区别——“团队目标一致，互相依赖合做，共同完成任务；而非团队成员则彼此独立，甚至能够随时脱离队伍”。非团队给个人感受就是聘用者和受聘者的关系，leader给受聘者发放薪水，受聘者给leader打工，一分钱一分货。我因而在想，若是按照这种定义来看，岂不是企业中就不存在团队了？

　　可是仔细想了想，我以为也不必定。衡量一伙人是否是一个团队不能只看薪水，而是他们在关心什么。团队的成员关心团队是否可以取得成功，而非团队的成员只关心还有没有工资能够拿。也就是说，即使拿了工资，偶尔也能关心一下项目进展，那么这也能够做为一个团队。

　　那么个人问题是，做为一个由“雇员”组成的团队，成员为何会愿意关心团队的情况呢？在软工课上，之因此每一名成员都努力为团队作贡献，是由于团队的期末答辩拿到了高分，每名成员均可以收获不错的成绩。在创业初期的团队中，可能每名成员不只可能吃不上饭，还须要付出至关大的努力。那么是什么维系着这个团队呢？大概是若是创业成功了，每名成员都将获得巨大的利益，这份利益彻底对得起他们的付出。

　　个人理解是，团队之因此是团队，是由于团队的成功能够为每个成员带来好处，若是一个吝啬的leader不肯意将队伍的成果分享给每一名成员，而仅仅用工资打发他们，那么我想成员也不必再关心这个队伍的进展了。实际上，不少企业都会根据当年的业绩发放“年终奖”，这就是将团队利益共享的一个很好的方式。

　　因此我在想，是否是一个非团队，若是可以实现利益的共同化，它就能够变成一个团队呢？

 

 

---

 

2、“软件”和“软件工程”这些词汇是如何出现的？

　　1958年，Tukey发表了一篇题为“The Teaching of Concrete Mathematics”的论文，这是所知的“software”一词最先的用法。[2]

　　“software engineering”是Apollo计划中，Hamilton在MIT提出的，她想要给予软件“合法性”，就像其它工程学科同样。[3]

 

 

---

 

3、软件工程发展的趣事和冷知识

　　“I'm an egotistical bastard, and I name all my projects after myself. First Linux, now git.”

　　Git这个名字是Linus Torvalds在编写第一个版本的时候起的，他将这个工具自夸为“the stupid content tracker”（傻瓜内容跟踪器）。我从Git的官方wiki找到了关于这个名字的多种解释，用本身的渣英语翻译一下：

1. 三个随机的、可发音的字母，而且它没有被做为任何UNIX的指令，它是被误读的“get”这件事变得可有可无；
2. 辣鸡、卑鄙、简陋，字典里的粗话随你挑；（该词在英国俚语貌似是脏话OTZ）
3. 是“global information tracker”（全局信息跟踪器）的简写：若是你心情不错，而且它正常地运行着，天使们在歌唱，一缕阳光洒进房间；
4. 是“g*dd*mn idiotic truckload of sh*t”的简写：若是它崩了……

 

 

---

 

4、上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？

　　其它的不太了解，Github在2013年用户数量突破了300万[4]，并且根据2016年GitHub的Octoverse报告显示，在过去一年中，来自中国的新用户注册增加最快，同比增加了97%，其次是印尼（90%）、印度（76%）、俄罗斯、巴西和日本。[5]

 

[GIT]

优势：

　　1.分支能力特别强大，体验特别好。加上支持离线提交，分布式推送拉取，使得代码层面的协做至关流畅；[6]

　　2.GIT的分支模型很全面很好用，能够自由地修改历史，方便多个版本库的交流。

缺点：

　　1.概念过于复杂；

　　2.命令行语法设计得比较随意且不一致；

　　3.命令行帮助提示晦涩难懂；

　　4.缺少良好的封装；

　　5.对代码的维护者友好，但却牺牲了共享者的使用体验；

　　6.版本管理未必安全；

　　7.一些简单的操做须要用到过多的命令。[7]

 

[TFS]

优势：

　　1.任务版上能将需求、项目进度尽收眼底，对于小团队而言，比甘特图更有用；

　　2.集成了项目管理、版本控制、BUG 跟踪，能有效实现 SCRUM；

　　3.能与VS无缝接合。

缺点：

　　1.用浏览器访问至关慢；

　　2.从 IE 上访问、填写各类开发、测试记录，也是很慢，不如 mantis BT 这样基于 php 的那么方便、迅速。[8]

 

[Mercuria]

优势：

　　命令行简单、容易上手。

缺点：

　　1.Mercurial 在不一样平台上（尤为 Windows 与 Linux 之间）有档名编码的问题，若是版本库可能使用到中文档名，会形成跨平台的交流障碍；

　　2.分支方式各有缺点和不便之处；

　　3.改写历史很麻烦，操做繁琐，难以还原错误操做以前的状态，更容易致使版本库混乱，也更容易出错致使丢失历史；

　　4.Mercurial 没有命名空间，一但和不少个版本库交流，很容易致使本身与别人的代码混成一团。[9]

[github]:

优势：

　　功能设计简洁实用上手很快，可用性好，已有不少至关质量的各种项目和优秀开发者在上面。[10]

缺点：

　　1.国内访问速度太慢，常常出现connect time-out；

　　2.不能很好的解决GB2312/GBK，对中文不够友好；

　　3.wiki功能太弱，直接致使文档常常被分离到一个独立站点。[11]

[Bitbucket]

优势：

　　1.支持Hg，最易学易用的分布式版本管理工具；

　　2.彻底免费的闭源项目，还支持5人之内的合做开发；

　　3.支持中文；

　　4.官方的git工具SourceTree比GitHub for windows好用。[12]

 

[Trac]

优势：

　　Trac作一个SCM配置管理平台，意味着它有良好的扩充性。经过WebAdmin界面中的Plugin功能，能够很方便的安装下载的插件，也能够经过此功能查看已经安装的插件，并可对其中的插件进行启用或停用操做。[13]

 

[Bugzilla]

优势：

　　1.强大的检索功能，强大的后端数据库支持, 丰富多样的配置设定等；[14]

　　2.BugZilla的定制功能的确更强，能知足更多用户差别化的需求。

缺点：

　　界面比较糟糕。

 

[Rational]

优势：

　　提升了团队生产力，在迭代的开发过程、需求管理、基于组建的体系结构、可视化软件建模、验证软件质量及控制软件变动等方面、针对全部关键的开发活动为每一个开发成员提供了必要的准则、模版和工具指导，并确保全体成员共享相同的知识基础。它创建了简洁和清晰的过程结构，为开发过程提供较大的通用性。

缺点：

　　RUP只是一个开发过程，并无涵盖软件过程的所有内容，例如它缺乏关于软件运行和支持等方面的内容，此外，他没有支持多项目的开发结构，这在必定程度上下降了在开发组织内大范围实现重用的可能性。

 

 

参考资料：

[1] http://www.xuebuyuan.com/821497.html

[2] https://en.wikipedia.org/wiki/John_Tukey

[3] https://en.wikipedia.org/wiki/Margaret_Hamilton_%28scientist%29

[4] http://kuailiyu.cyzone.cn/article/1453.html

[5] http://digi.163.com/16/0919/06/C1A9M69J001680N8.html

[6] http://www.cnblogs.com/lwl123/p/5253184.html

[7] https://www.zhihu.com/question/20401926/answer/15034642

[8] https://www.zhihu.com/question/21943395

[9] https://www.zhihu.com/question/21905835/answer/94503278

[10] https://www.zhihu.com/question/19591651/answer/12314492

[11] https://www.zhihu.com/question/19591651/answer/12798445

[12] https://www.zhihu.com/question/20053312/answer/20005315

[13] https://baike.baidu.com/item/trac/7367196?fr=aladdin

[14] http://blog.csdn.net/qq_33336155/article/details/53321885

[13] http://blog.csdn.net/wayne_ran/article/details/1555686

[14] http://www.docin.com/p-1614947229.html