个人博客作业Week1
个人博客作业
问题
细节问题
1.《构建之法》书上P77页讲到了两种命名方法：Pascal形式和Camel形式。
Pascal形式：所有单词的第一个字母都大写
Camel形式：第一个单词全部小写，随后单词随Pascal形式
书上说到一个通用的做法是：所有的类型/类/函数名都用Pascal形式，所有的变量都用Camel形式。但是实际上的情况是：所有的类型/类用Pascal形式，所有的变量/函数名都用Camel形式。与书上说的不完全相同。
是C/C++语言的命名规则不同，还是有其他原因？
网上有不同的规则：
http://www.linuxidc.com/Linux/2013-01/77893.htm
http://blog.csdn.net/jinzhilong580231/article/details/7717647
2.《构建之法》书上P79页讲到了goto：函数最好有单一的出口，为了达到这一目的，可以使用goto。只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括goto。
goto有什么危害？如何更加合理的运用它？
https://en.wikipedia.org/wiki/Goto
http://blog.sina.com.cn/s/blog_6908039c0101f5hx.html
http://baike.baidu.com/link?url=guvhXPkY7ZbDrxJbjcWTsBhLk3Jx2trpDT5A_YSsVke6k9JAMm_OTsi7lRQqlyGjF2cyKjBCFH_wDbR_aR9SYa
3.《构建之法》书上P79页讲到了虚函数：
1) 使用虚函数来实现多态；
2) 仅在有必要时，使用虚函数；
3) 如果一个类型要实现多态，在基类中的析构函数应该是虚函数；
虚函数是如何实现多态的？
http://blog.chinaunix.net/uid-26851094-id-3327323.html
4.3.《构建之法》书上P80页讲到了析构函数需要注意的点：
1) 把所有的清理工作都放在析构函数中。如果有些资源在析构函数之前就释放了，记住要重置这些成员为0或NULL;
2）析构函数也不应该出错。
这两个注意点我一个都不懂。所有的清理工作指什么？为什么要重置一些资源为0或NULL?析构函数出错一般会是什么情况？
概念问题
5.我们团队打算以功能团队模式来完成团队作业，那么功能团队中有一张图（P105）：Dev，QA，UX，PM，沟通&协作。这是指团队主要只需要4部分（Dev，QA，UX，PM）就可以了，还是得需要一两个人作为沟通协作其他成员的人？
6.我们在团队任务的时候是需要哪种流程方式：写了再改模式（我们一般会这么做），瀑布模型（我们应该不会这么高大上的方式），统一流程，老板驱动的流程，渐进交付的流程（MVP,MBP，我对这个比较感兴趣）。
7.我们在做敏捷开发的时候，如何正确地有效地规定近期目标？如何有效地进行沟通？
8.敏捷开发(Agile)有几种开发的方法论：特征驱动开发（FDD）、Srum、极限编程(XP)、其它。
这些方法分别适用那些项目？我们在今后的敏捷开发的过程中应该用哪种方法论？前3中方法论是否是最好的，它们有哪些验证，还有那些常用的方法论？
9.对于团队中代码检查测试，我们每个人能发挥什么作用？为了使最终的工程尽可能详尽，让人满意，我们应该如何开展代码测试？书中的单元测试，功能测试，集成测试，场景测试，系统测试等会对测试产生什么影响？我们应该在什么时候开展这些测试？
软件和软件工程
软件在阿波罗计划计划的初期还被当作初初学步的孩子一般对待，完全不像其他工程学科；例如像硬件工程那样的受到重视，而且在大家的眼光中他就像是艺术、魔术一般，而不是一门科学。
一直以来Margaret Hamilton坚信这项发明流着艺术与科学的血液，虽然当时很少人是这么想。因此，她致力于为软件以及那些发明者争取应有的正统性与尊重，所以她开始使用“软件工程”这样的字眼来将之与硬件还有其他工程学类做出区别。
当她第一次使用这样的语词时，大家都觉得有些好笑，甚至有很长一段时间被当作笑话。他们常笑她极端的想法。但最终，软件学科确实得到了应有的尊重！
流行的源程序版本管理软件和项目管理软件
Microsoft TFS
TFS有对复杂环境的良好支持。比如，报表，SharePoint的整合，支持跨多域，分布式数据库等等。
在上图中，每个系统都有独立的存储空间，资源标识集，命令和工具集。要让整个系统工作起来，就像把一组自定义立体组件联接在一起：可以实现，但工作量巨大，而且可能在一些地方出现纰漏。
我更想要的就是这样一个系统，它可以将这些工作整合到一起并实现我默认的工作流程。
这个整合实现了一些非常常见的场景。例如每天我会编辑源代码，生成产品并测试它，报Bug并修复它，周而复始。当有一个整合的系统可以全部支持这些工作流程时，那么所有的工作就可以被关联起来。例如，当我签入Bug的修复时，我很想看到那些缺陷被解决时这个变更集能被纪录下来。（详见下面的例子）
TFS的基础配置可以让你精确地做到这些。这跟简单的源码管理相比是一个巨大的进步。TFS的完整版将会加入一些新的特性，包括自动化测试，虚拟实验室的部署和架构验证。下面是扩展后的工作流程：
当你使用Visual Studio 加强版和旗舰版的时候，你可以根据需要选择安装这些新组件。
有许多方法可以访问TFS。开发人员经常会通过Visual Studio来访问它。测试人员可以通过新的Test and Lab Manager来访问TFS（没有必要安装VS）。如果你是项目经理，你也可以通过web接口，Excel，Microsoft Project，或者dashboards的MOSS支持（VS2010的新功能）来访问TFS。
Git
Git是一款免费、开源的分布式版本控制系统，用于敏捷高效地处理任何或小或大的项目。
Git是一个开源的分布式版本控制系统，用以有效、高速的处理从很小到非常大的项目版本管理。Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。
Torvalds 开始着手开发 Git 是为了作为一种过渡方案来替代 BitKeeper，后者之前一直是 Linux 内核开发人员在全球使用的主要源代码工具。开放源码社区中的有些人觉得 BitKeeper 的许可证并不适合开放源码社区的工作，因此 Torvalds 决定着手研究许可证更为灵活的版本控制系统。尽管最初 Git 的开发是为了辅助 Linux 内核开发的过程，但是我们已经发现在很多其他自由软件项目中也使用了 Git。例如 最近就迁移到 Git 上来了，很多 Freedesktop 的项目也迁移到了 Git 上。
Git的功能特性：
从一般开发者的角度来看，git有以下功能：
1、从服务器上克隆完整的Git仓库（包括代码和版本信息）到单机上。
2、在自己的机器上根据不同的开发目的，创建分支，修改代码。
3、在单机上自己创建的分支上提交代码。
4、在单机上合并分支。
5、把服务器上最新版的代码fetch下来，然后跟自己的主分支合并。
6、生成补丁（patch），把补丁发送给主开发者。
7、看主开发者的反馈，如果主开发者发现两个一般开发者之间有冲突（他们之间可以合作解决的冲突），就会要求他们先解决冲突，然后再由其中一个人提交。如果主开发者可以自己解决，或者没有冲突，就通过。
8、一般开发者之间解决冲突的方法，开发者之间可以使用pull 命令解决冲突，解决完冲突之后再向主开发者提交补丁。
从主开发者的角度（假设主开发者不用开发代码）看，git有以下功能：
1、查看邮件或者通过其它方式查看一般开发者的提交状态。
2、打上补丁，解决冲突（可以自己解决，也可以要求开发者之间解决以后再重新提交，如果是开源项目，还要决定哪些补丁有用，哪些不用）。
3、向公共服务器提交结果，然后通知所有开发人员。
优点：
适合分布式开发，强调个体。
公共服务器压力和数据量都不会太大。
速度快、灵活。
任意两个开发者之间可以很容易的解决冲突。
离线工作。
缺点：
资料少（起码中文资料很少）。
学习周期相对而言比较长。
不符合常规思维。
代码保密性差，一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。
Mercurial
Mercurial 是一种轻量级分布式版本控制系统，采用 Python 语言实现，易于学习和使用，扩展性强。其是基于 GNU General Public License (GPL) 授权的开源项目。
相对于传统的版本控制，具有如下优点：
更轻松的管理。传统的版本控制系统使用集中式的 repository，一些和 repository相关的管理就只能由管理员一个人进行。由于采用了分布式的模型，Mercurial 中就没有这样的困扰，每个用户管理自己的 repository，管理员只需协调同步这些repository。 更健壮的系统。分布式系统比集中式的单服务器系统更健壮，单服务器系统一旦服务器出现问题整个系统就不能运行了，分布式系统通常不会因为一两个节点而受到影响。 对网络的依赖性更低。由于同步可以放在任意时刻进行，Mercurial 甚至可以离线进行管理，只需在有网络连接时同步。
GitHub
Git是一个分布式的版本控制系统，最初由Linus Torvalds编写，用作Linux内核代码的管理。在推出后，Git在其它项目中也取得了很大成功，尤其是在Ruby社区中。目前，包括Rubinius、Merb和Bitcoin在内的很多知名项目都使用了Git。Git同样可以被诸如Capistrano和Vlad the Deployer这样的部署工具所使用。
作为开源代码库以及版本控制系统，Github拥有140多万开发者用户。随着越来越多的应用程序转移到了云上，Github已经成为了管理软件开发以及发现已有代码的首选方法 。
如前所述，作为一个分布式的版本控制系统，在Git中并不存在主库这样的概念，每一份复制出的库都可以独立使用，任何两个库之间的不一致之处都可以进行合并。
GitHub可以托管各种git库，并提供一个web界面，但与其它像 SourceForge或Google Code这样的服务不同，GitHub的独特卖点在于从另外一个项目进行分支的简易性。为一个项目贡献代码非常简单：首先点击项目站点的“fork”的按钮，然后将代码检出并将修改加入到刚才分出的代码库中，最后通过内建的“pull request”机制向项目负责人申请代码合并。已经有人将GitHub称为代码玩家的MySpace。
在GitHub进行分支就像在Myspace（或Facebook…）进行交友一样，在社会关系图的节点中不断的连线。
GitHub项目本身自然而然的也在GitHub上进行托管，只不过在一个私有的，公共视图不可见的库中。开源项目可以免费托管，但私有库则并不如此。Chris Wanstrath，GitHub的开发者之一，肯定了通过付费的私有库来在财务上支持免费库的托管这一计划。
“是的，我们正是这么计划的。通过与客户的接洽，开发FamSpam，甚至是开发GitHub本身，GitHub的私有库已经被证明了物有所值。任何希望节省时间并希望和团队其它成员一样远离页面频繁转换之苦的人士都会从GitHub中获得他们真正想要的价值。”
在GitHub，用户可以十分轻易地找到海量的开源代码。
Bitbucket
BitBucket 是一家源代码托管网站，采用Mercurial和Git作为分布式版本控制系统，同时提供商业计划和免费账户。
特点：
无限制的私有仓库个数
无限制的磁盘空间
同时支持https/ssh
Bug 跟踪
项目Wiki
API 支持
灵活的权限控制
可自定义域名
RSS 修改记录输出
自定义下载
Trac
Trac是一个为软件开发项目需要而集成了Wiki和问题跟踪管理系统的应用平台，是一个开源软件应用。Trac以简单的方式建立了一个软件项目管理的Web应用，以帮助开发人员更好地写出高质量的软件；Trac应用力求不影响现有团队的开发过程。
用trac管理一个项目，就要做好以下几方面的工作：
●划分里程碑
●划分项目components
●划分ticket
●熟练掌握Ticket的运作机制
●熟练掌握Change History的查看和使用
●熟练掌握Milestone的查看和使用
Bugzilla
Bugzilla 是一个开源的缺陷跟踪系统（Bug-Tracking System），它可以管理软件开发中缺陷的提交（new），修复（resolve），关闭（close）等整个生命周期。 Bugzilla是一开源Bug Tracking System，是专门为Unix定制开发的。
功能表现
强大的检索功能
用户可配置的通过Email公布Bug变更
历史变更记录
通过跟踪和描述处理Bug
附件管理
完备的产品分类方案和细致的安全策略
安全的审核机制
强大的后端数据库支持
Web，Xml，Email和控制界面
友好的网络用户界面
丰富多样的配置设定
版本间向下兼容
Rationale
Rationale 是一流品质的"争论处理"软件。使用 Rationale 可以创建争论地图，推理和论点图表。Rationale 将帮助学生学习良好的推理，重要思维，论文写作的基本原理；并且还将有助于专业人士（比如律师，分析师，政策制定者）更加方便有效地进行复杂的推论。
Apple XCode
Xcode 是运行在操作系统Mac OS X上的集成开发工具（IDE），由苹果公司开发。Xcode是开发OS X 和 iOS 应用程序的最快捷的方式。Xcode 具有统一的用户界面设计，编码、测试、调试都在一个简单的窗口内完成。