启——软工第一次个人博客作业
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2020春季计算机学院软件工程(罗杰 任健) |
| 这个作业的要求在哪里 | 个人博客作业 |
| 我在这个课程的目标是 | 系统学习软件工程，在实践中获得个人提升 |
| 这个作业在哪个具体方面帮助我实现目标 | 通过阅读书籍学习新的知识，同时提出问题，进行反思 |
快速看完整部教材，列出你仍然不懂的5到10个问题，发布在你的个人博客上。
问题1
如何能让自己负责的模块功能定义尽量明确，模块内部的改变不会影响其他模块，而且模块的质量能得到稳定的、量化的保证？单元测试就是一个很有效的解决方案。
——2.1 单元测试
说到单元测试，就不得不让我想到课程组所使用的自动评测机。说到自动评测机，就不得不让我想到大二下学期学习OO时候的惨烈。可以说，会写自动评测机的人约等于能够获得九十以上的分数。写自动评测机的人那么多，写单元测试的又有几个呢？
于我来说，单元测试需要通过自己构造数据来覆盖各种语句的分支，费时费力，而自动评测机只需要用简单的shell语句就可以实现，并且可以长时间大批量进行bug测试覆盖，不局限于各种条件分支问题。那么是否说明单元测试其实并无必要，而应该转而使用自动评测机暴力测评呢？或者说用单元测试为辅，暴力测评大面积覆盖为主？
问题2
在结对编程模式下，一对程序员肩并肩、平等地、互补地进行开发工作。他们并排坐在一台电脑前，面对同一个显示器，使用同一个键盘、同一个鼠标一起工作。
在结对编程中，因为有随时的复审和交流，程序各方面的质量取决于一对程序员中各方面水平较高的那一位。
——4.5.2 为什么要结对编程
结对编程，在课堂上或多或少有过这样的机会，而不得不说，对于我来说，几乎每次的体验都比较差。
在现实编写代码的过程中，我们或许会觉得，如果身边有个人能和我一起共同写、共同发现bug，那样我的代码就一定写的很优秀了。这也是第一段话中所提到的观点。
但是事实上是，常常因为两个人思路不合而无法继续进行下去，或者是因为某个人过于大佬，另外一个只能打call，又或者两个人都很菜，最后双双挂科。而这也印证了第二段话中的观点。
所以，既然我们有了“小黄鸭debug”法，为什么还需要同伴去指出我们代码的问题？这样说或许有点太刚愎自用，但是结对编程真的有必要吗？大的工程需要团队去执行，小的程序自己一个人就可以完成，似乎结对编程有些多余了。更何况按照第二段话所说，程序的的优劣取决于程序员中各方面水平较高的那一位。那么按照组合来说，会有以下几种情况：
大佬配大佬、大佬配菜鸡、菜鸡配菜鸡。
第一种组合或许比较适合结对编程，但是是否因为两个人都是大佬而意见常常不合，或者最后交出了两份功能相同，风格完全不同的代码，那岂不是“我结对我自己”了？
第二种组合，大佬往往因为自身能力太强，在不经意间就导致了菜鸡划水，又变成了“我结对我自己”了？
第三种组合，两人可能因为某些方面都有缺陷而成为了菜鸡，那么两个菜鸡放在一起，如果是很有责任心的话还可以很好的完成结对任务，但是若是两个人都比较想混，岂不是从"ddl战士"变成了“ddl战士团”？
所以在我看来，结对编程似乎并无必要？
问题3
很多时候用户并不知道自己确切的需求，或者不愿意表达完整的需求，软件团队需要设身处地，替用户着想，引导出需求。
——8.1 软件需求
最近我确实遇到了这个问题。
在帮助别人写代码的过程中，对方无法表述清楚自己的需求，或者甚至直接让我去提出一些可能的需求，而在我完成了初始代码的书写之后，又数次提出新的需求，在我按照要求更改之后又反复回退到前一个甚至前几个版本的需求。
在真实的市场上，甲方是否会同样反复无常，甚至直接让程序员自己去想呢？那么对于这种类型的用户，我们到底应该如何应对呢？而对于代码来说，我在书中看到，不要过早的注重通用的问题，那么在这样经常变换需求下，我们作为代码编写者和维护者，应该怎样组织自己的代码呢？
问题4
我们要让团队中做事不仔细的人慢下来，这样能减少他们的危害。
——11.5.2 每日构建
这让我想起了大二时冯如杯的感受。
或者说我比较排斥组队的原因就在于这里，似乎每次组队的后果都是自己一个人完成所有需求，冯如杯也是，数学建模也是。我有时候在反思自己，为什么“团队任务”最后都变成了我的“个人任务”了呢？是因为我能力很强吗？我想不是的。
是因为"在乎"。
在线上交流的时候，我们永远也不知道自己的队友到底是看了不回还是不看不回，这也许就是”薛定谔的队友“吧。
所以我想问，假如已经组到了不作为的，或者更贬损一点的说，猪队友，而临时更改又没有办法的情况下，应当如何减少其对团队造成的损失呢？又当如何减少”一人带飞全队“的情况呢？
问题5
如果我简单地合并版本，并且签入，很有可能会导致TFS上编译失败。但是如果我为了保证质量，在合并后，本地编译并运行各种测试，这相当于重复了第2、3步。当我再次提交签入（重复第4步）时，有可能碰到新的版本冲突。这样循环往复，以致无穷……
——11.5.4 宽严皆误
不光是在毕业后，我们需要面临团队共同维护代码的问题，而且在本次软件工程课上，我们同样需要面对共同维护代码的问题。
还记得之前和同学共同维护一个规模较大的代码，git的使用令人目不忍视。
而且也常常听说，在工作中的程序员维护代码时，需要抢时间，如果你先改完了，提交到仓库，那么其他人就得重新修改再提交，以保证版本对应，反复数次总有修改速度比较慢的人得等全部同事都改完了之后再进行修改。我自己在不同服务器上的代码也经常会因为不同的用处修改，最后到合并的时候出现无法兼容的问题，想要修改就必须重构，这样过于麻烦。那么对于这样的版本不一致问题，是否有较好的解决办法呢？
问题6
软件学院的学生果冻在移山公司实习，他问阿超：为啥需要源代码管理？我自己写代码多爽，别人要，就用QQ传过去好了。为啥要看老的代码？我的最新代码是质量最高的，有质量最高的代码还不够么？
——11.6 实战中的源代码管理
我们或多或少都会遇到这样的问题。
在完成代码初期，我们思考的框架很好，将各种功能的封装也尽量做到了低耦合。但在长时间的新需求冲击下，我们难免将代码改写的越来越臃肿，以至于到了某个临界点之后，原本漂亮的代码已经面目全非。对于比较简单的，几千行的代码或许可以通过重构来解决，但是到了工程项目上，动辄几万，几十万的代码量，显然重构是不现实的。
但是根据书中前半部分所说，我们不应该过多考虑问题而导致过度分析，但是如果没有将需求全面分析，那么是否会导致更严重的问题？而对于增量式任务中，维护代码注意的要点又在哪里呢？是否到了某个阈值之后就将代码重构以保证其美观性？
而这又让我想到了，如果我们放弃对于代码的美观性，仅仅是增量再增量（我也相信很多公司处理这样任务的方式就是这样，代码简直像一个弗兰肯斯坦），对于新入职的员工，代码可读性很差，这是否是不利于吸收新鲜血液？而且在书中也提到过一个故事，就是新来的员工觉得公司的代码过于丑陋，便打算重构，他的同事却说，这份代码就是上一个新来员工重构过的版本了。对于这样代码臃肿，可读性差的问题，我们是否除了重构别无他法？是否能够以更优雅的方式维护其功能性与可读性呢？
问题7
最近几年，我们整个社会似乎对创新都很感兴趣，媒体上充斥着创新型的人才、创新型的学校、创新型的公司、创新型的城市、创新型的社会等名词。
——16.1 创新的迷思
对于普通人来说，接受了比较僵化的书本教育之后，似乎已经丧失了创新力。
创新一词，是否只是天之骄子的独有之物？
对于我自己来说，和同学合作的过程当中，我也偶尔会提出自己的看法，都是灵光乍现的产物，但无一不被否决。那么如此说来，是否代表着我缺乏创新力呢？或许是我思考问题的方式有了偏差，导致我思考出来的角度都不可行，那么想要拥有有效的创新力，应该如何去培养呢？应该从何等方面去思考？
请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 何时、何地、何人？
软件
1953年8月，Richard R.Carhart在兰德公司的研究备忘录中首次写道软件这个词汇
1958年，John Wilder Tukey发表了名为"The Teaching of Concrete Mathematics"的论文，这是软件一词最早发表在论文上的记录
软件工程
在50年代，Douglas T. Ross在MIT的讲座中便已经提到了这个术语，之后由Margaret Hamilton，正式命名了这个术语。
在60年代，由于人类面临”软件危机“，1968-1969与NATO组织的会议上提出软件工程这个术语。
【附加题】：大家知道了软件和软件工程的起源，请问软件工程发展的过程中有什么你觉得有趣的冷知识和故事？
Lenna图
Lenna图是数字图像处理领域大名鼎鼎的例图，常常被用作实验，因为其包含以下特点：
-
该图适度的混合了细节、平滑区域、阴影和纹理，从而能很好的测试各种图像处理算法。
-
Lenna是个美女，对于图象处理界的研究者（大部分都是男性）来说，美女图可以有效的吸引他们来做研究。
但其实，它被采用为测试图片的真实故事是：
1973年6月，美国南加州大学的信号图像处理研究所的一个助理教授和他的一个研究生打算为了一个学术会议找一张数字照片，而他们对于手头现有成堆“无聊”照片感到厌烦。事实上他们需要的是一个人脸照片，同时又能让人眼前一亮。这时正好有人走进实验室，手上带着一本当时的《花花公子》杂志，结果故事发生了……而限于当时实验室设备和测试图片的需要，lenna的图片只抠到了原图的肩膀部分。
上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？
| 名称 | 使用人数 |
|---|---|
| Assembla | Unknown |
| Buddy | Unknown |
| CloudForge | Unknown |
| Gitea | Unknown |
| OW2 Consortium | Unknown |
| Rosetta code | Unknown |
| SEUL | Unknown |
| GitHub | 31,000,000 |
| Bitbucket | 5,000,000 |
| Launchpad | 3,965,288 |
| SourceForge | 3,700,000 |
| GitLab | 100,000 |
| GNU Savannah | 93,346 |
| OSDN | 54,826 |
| Ourproject.org | 6,353 |
优缺点
| 名称 | 优点 | 缺点 |
|---|---|---|
| Microsoft TFS | 是对敏捷，msf，cmmi等项目、过程管理、过程改善的支持。任务版上能将需求、项目进度一览无余，对于小团队而言，比甘特图更有用。 | 能应用起来的团队、公司的数量极少，多数真正用起来，也就是源代码管理这部分，这也仅仅是占TFS极小部分功能。 |
| GIT | 适合分布式开发，强调个体；公共服务器压力和数据量都不会太大；速度快、灵活；任意两个开发者之间可以很容易的解决冲突；离线工作。 | 学习周期相对而言比较长；不符合常规思维；代码保密性差，一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。 |
| Mercurial | 易于学习，上手很简单；封装好 | 跨平台性能较差；分支管理不灵活；支持社区略差 |
| GitHub | GitHub提供Git存储库服务，基于web，允许你使用Git的源代码管理功能，或者其特性。GitHub提供Git存储库服务，基于web，允许你使用Git的源代码管理功能，或者其特性。 | 可能不是捕捉创意过程和记录创意点子的最佳工具。对于这种特殊功能模拟可以选择LayerVault 或其他相似工具。之前，我们已经强调过Github非常适用代码跟踪，但是却不是最好的设计跟踪工具。将图片内容转化为代码，或者将设计用于产品设置，看起来依旧不是那样顺利。 |
| Bitbucket | 易学易用；完全免费；支持中文 | 速度慢；代码闭源 |
| Trac | 非常灵活，可以随心所欲控制可以和SVN集成 | 功能不是很强大。 |
| Bugzilla | 免费；支持中文版本 | 快速搜索结果不准确。只能管理缺陷。 |
| Apple XCode | 编译速度极快，每次操作都很快速和轻松。自动提供撤消、重做和保存功能，无需编写任何编码。 | 更新版本后，某个插件可能会失效。 |
调查完目前流行的源程序版本管理软件和项目管理软件后，请你选择其中至少2个软件来进行动手实践
Bitbucket
如图所示，我通过使用Bitbucket来实现了创建仓库的功能，并且尝试上传了名为test的文件。总的来说这个软件的用途和github区别不大，不过也可能是目前使用方式太过单调，还需要继续调研。
Git
如图所示，我使用了Git的GUI界面创建仓库，它可以直接使用github来进行代码管理，所以其实在我看来git和github两者之间有区别但又有很大联系。
