个人作业-Week 1
一.快速看完整部教材，列出你仍然不懂的5到10个问题，发布在你的个人博客上
1.在看到第二章中关于《个人技术和流程》中讲到了个人的开发流程：
需求分析->生成设计文档->设计复审->代码规范->具体设计->具体编码->代码复审->测试
我在实际开发第一次作业时发生了这样的问题：在我写好数独的生成算法后，就写了和它相关的主函数和辅助函数的测试单元。之后因为要提升算法的性能，所以我选择了另外一种数独的生成算法，但是这个过程中，我的主要函数和辅助函数都发生了变化，所以这时我又要重新写关于新的主要函数和辅助函数的测试单元。这样做其实浪费了不少时间。
我觉得这是因为之前的设计文档设计的不够好的缘故。如果之前在设计文档时就定好具体的算法实现，或者规定好相应的api规范，就可以避免这个问题。但是很多时候，我们计划写的api和实际中的api可能完全不一样了。比如我在数独生成算法中，一开始设计的判断是否能填入的api是通过对所在行，列，九宫格进行遍历得到的，而之后又听到别人的建议后，选择了另外一种方法即通过在数字填入时记录对应行，列，九宫格不能再填这个数字来实现是否能填入。
这只是一个小的api，可能前后修改起来还比较简单，但是假如是一些很重要的接口，很关键的设计，我觉得就需要在生成设计文档和设计复审时花很大的功夫设计到最好，我甚至觉得这个过程比具体编码还要重要，因为如果设计文档设计的好，逻辑正确，那么具体编码时只不过是把伪代码转化为真正的代码的过程。
但是文档的设计说起来容易，做起来我觉得很难，可能是我现在还比较渣，我总是觉得在具体编码时，原来的一些设计是不可取的，或者想到了更好的设计。那么除了不断的提高自己的经验以外，还有没有其他的系统的方法来提高一开始的文档的设计后的质量呢？
2.书里第一章提到了：
软件工程的一个重要任务，就是要在时间，成本等多种约束条件下决定一个软件在什么时候能够“足够好”，可以发布。
我觉得这句话很经典。这句话让我想到了数学上的优化问题。数学上一类问题就是需要解决在约束条件下的目标函数的最大值和最小值问题，这里也是一样，时间，成本等资源就是限制条件，而目标函数就是软件的“好坏程度”。我们的目标就是在这些限制条件下，让我们的目标——做出来的软件越来越好。软件工程的目的就是尽可能的高效率的系统的调度这些时间金钱人力物力成本让最后生成的软件项目达到限制条件内的最好。
所以我个人疑惑的是在评判软件的好坏时，是不是需要考虑软件背后的成本来对软件好坏进行评判呢？
3.在上个学期的面向对象编程的课上，老师提到了这么一种编程模式：一些人把api的规范和功能都以规格的形式定义好，即定义好每个api的输入，输出，要实现的功能，需要处理和返回什么结果。然后具体的编码和算法的设计由其他人来具体完成，因为之前的规格已经把功能都定义好了，所以只需要让具体编码的人遵守规格即可。我觉得这种方法其实很不错，即一人设计文档，另外一人具体编码。
而我在书上也看到了关于这种方式的一点描述：就是把开发人员分为“master”和“slater”，master负责制定伪代码，slater负责具体编码。但是我觉得两者是平等的，每个人既可以设计伪代码，也可以设计具体编码，不要分为“master”和“slater”多伤和气...如果能保证每人分别承担一定的伪码设计和实际编码，我觉得这种办法其实是很不错的：
①每个人既能锻炼设计能力，也能锻炼实际编码能力
②我觉得这就是合作的一种方式，设计和具体实现不一定非要都放在一个人身上。
所以我想问这种编程方式实际中被应用的如何？
4.很多时候很多问题我们在具体开发过程中才能遇到或者意识到，包括一开始的设计问题，架构问题，或者说人员分工问题，那么有什么普遍性原则可以帮助我们尽量的减少这些突发问题或者藏得很深的问题所带来的损失呢？
5.在团队项目中，人员的管理是一门很重要的技能。如果每个成员都可以自我管理，自我约束，并有一定的集体精神，那么管理起来就很方便，但是对于那些未能自我管理，并且经常因为自己的原因耽误了大家的整体进度的人，如果他技术能力不强，那么我们可能就直接请他退出团队就好，但是对于那些掌握技术核心，却没有集体主义精神的人该如何管理呢？
二.请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 何时、何地、何人？
1.“软件工程”概念第一次出现在1968年在德国GarmischDr.F.L.Bauer的文章《Software Engineering:Report of a conference sponsored by the NATO Science Committee》。
2.“软件”概念第一次出现在John W Turkey，在1958年1月9日发布的 "The Teaching of Concrete Mathematics," American Mathematical Monthly, 其中是这样描述的：
"Today the 'software' comprising the carefully planned interpretive routines, compilers, and other aspects of automative programming are at least as important to the modern electronic calculator as its 'hardware' of tubes, transistors, wires, tapes and the like"
[附加]请问软件工程发展的过程中有什么你觉得有趣的冷知识和故事？
应该就是书上的关于《敏捷宣言》的诞生吧。有时一些重要的东西只有在人们闲着没事做时，才有可能产生出来。
三.上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？
Microsoft TFS、Git、Mercurial、GitHub、Bitbucket、Trac、Bugzilla、Rational，Apple XCode
1.Microsoft TFS优缺点：
优点：适用于敏捷团队的工具，任务版上能将需求、项目进度一览无余，对于小团队而言，比甘特图更有用，支持对任何平台的开发，开放且可扩展，而且可供个人或小团体免费试用。
缺点：能应用起来的团队、公司的数量极少，多数真正用起来，也就是源代码管理这部分，这也仅仅是占TFS极小部分功能。
2.GitHub：
优点：分支能力特别强大，体验特别好。加上支持离线提交，分布式推送拉取，使得代码层面的协作相当流畅。重在社交。
缺点：Github非常适用代码跟踪，但是却不是最好的设计跟踪工具。
3.Mercurial：
优点：照顾命令行用户，简洁优雅，服务器部署相对容易。
缺点：分支管理不灵活，branch分出来就不能被删除了。
4.Git
优点：开源，免费，擅长的是程序代码的版本化管理，代码库占很多空间，易于代码的分支化管理
缺点：不支持中文，图形界面支持差，使用难度比较大。
5.Bitbucket
优点：提供无限免费的私人仓库，简单易学，支持中文
缺点：人气不高。
6.Trac
优点：非常灵活，可以随心所欲控制可以和SVN集成
缺点：功能不是很强大
7.Bugzilla
优点：免费，有中文版支持
缺点：快速搜索结果不准确。只能管理缺陷。
8.Apple XCode
优点：编译速度极快，每次操作都很快速和轻松。自动提供撤消、重做和保存功能，无需编写任何编码。
缺点：更新版本后，某个插件可能会失效。
