不懂的问题
- 书中提到瀑布式的开发方式，在实现软件开发过程中，各个阶段都可能会有遗留问题，并可能使得下一阶段难以进行，因此需要回头解决问题。在实际的开发过程中，分配给每个阶段的时间都是有限，可能为了做出某个效果而给后续的开发留下问题，这样迭代下去会产生很多麻烦，会有很多反复，怎样较好的避免这种情况呢？
- 第一章中提到软件的不常用功能并类比了飞机的安全功能，这些功能常常用来在软件出现异常时维持程序的正常状态，因此他们的存在是必要的。但是我们在写程序是通常要在调试时，等到异常出现了才意识到应该在哪里做这样的功能，那么在软件设计之初有没有什么方法考虑到这些功能呢？
- 第十三章讲到了测试的重要性，测试是软件的最后一道防线。在我的理解中，开发人员自身也应当做一些测试以保证程序基本的正确性，测试人员和开发人员相比所做的测试应该更加全面和细致。针对一个功能进行的单元测试应该在什么时候做？应该在完成代码前就把单元测试设计好还是应该完成代码后针对代码做单元测试？测试的标准应该是设计中的功能还是程序实际具有的功能？
- 书中提到结对编程和极限编程的思想是“将卓有成效的开发方法用到极致”，它似乎是一种非常值得推崇的方法，但是按照国内的情况来看似乎不那么受欢迎，按照我们到目前为止的认知，编程都是一件相当个人的事情。结对编程这种方式在实际的项目中是否可行呢？与个人编程相比，这样的编程方式又有什么样的弊端呢？
- 第九章中讲“PM做项目中出开发和测试以外的所有事情”，“PM的专业是理解和表达”，具备开发任务中所需的技术技能对PM来说是否是必要的呢？在项目的推进过程中，开发或测试人员难免会因为时间冲突、技术困难等原因无法按时完成任务，这时PM应该调整任务安排还是应该参与到开发或测试工作中，帮助完成任务？
- 第十一章讲到了设计与实现，从Spec到实现是将设计落实到功能上的过程。所谓的设计究竟应该包括哪些内容呢？进行设计时有时候划分了函数，确定了他们之间的调用关系，但是由于考虑不够细致后期仍然会发生较大的变动。在一些算法上也会遇到一些困难，与预估时间相比有较大的偏差。设计阶段应该细化到什么程度，是否应该细致的考虑所有细节？
- 第九章中说在团队中项目经理、开发人员和测试人员是一种平等的关系。但是人们往往会不自觉地认为能给自己安排任务的人都应该与自己存在上下级关系，至少要有比自己更为突出的能力，那么在这种平等的关系之下，如果项目经理并没有过人的技术，在进行项目的规划和安排时怎样才能合理的分配工作并且有说服力呢？
- 第八章中讲到在软件开发的过程中会不可避免的遇到“更改需求”这样的事情，无论是自己理解的偏差还是客户要求的改变，可能都需要在已完成的框架和功能上进行修改，往往会浪费之前付出的很多时间和精力，那么除了提高获取需求的能力和分析需求的准确性，从软件设计开发的角度出发，有没有什么减少损失的方法呢？
- 在软件开发过程中，每个人负责的不同功能模块可能会有交互，而没有清晰的界限，开发人员需要很好的沟通才能使项目的开发顺利进行，交互的部分应该怎样分配时较好避免冲突呢？
词汇
- 软件
- 概念：存储在存储程序计算机的存储器中的共处理器执行的指令
- 时间：1935年
- 地点：Alan Turing的文章Computable numbers with an application to the Entscheidungsproblem
- 人物：Alan Turing
- 软件工程
- 概念：以系统化方法应用于软件开发工程
- 时间：1968年
- 地点：前联邦德国
- 人物：北大西洋公约组织召开的软件工程会议
冷知识和故事
1987年，Ivar Jacobson离开Eric-sson，成立了Objective Systems公司。他吸纳了增量迭代的思想，开发出Objectory过程，并且把过程当软件卖，价格卖到25000美元一份，以至于Ivar Jacobson不想在Addison-Wesley等出版社出书公开他的方法，因为卖一本书才得到3美元。1991年，Ericsson收购了该公司， 并更名为Objectory AB（北欧出大师，所以我们常在软件开发的书籍和文章中看到××AB等文字，AB是瑞典语Altiebolag的缩写，意思是“公司”），Ivar Jacobson又回到了Ericsson。
1995年，Rational从Ericsson收购了Objectory，Ivar Jacobson开始和Grady Booch、James Rumbaugh一起开发UML。Philippe Kruchten则负责把Objectory过程和Rational公司多年的积累Rational Approach融合在一起，开发出了“Rational Unified Process”以及4+1视图模型。RUP的中心思想是：用例驱动、架构为中心、迭代和增量。虽然是一个商业产品，但详尽的内容和灵活的组织，使得 RUP成为软件团队中流传最广的软件过程模型，也成为团队学习软件工程和实施过程改进的重要资料。
Ivar Jacobson在IBM收购后离开了Rational。2005年，他发布了Essential Unified Process（EssUP）将之描述为“超轻和超敏捷的”RUP，并且提出了过程定义（PD）和过程（P）的观点，他认为统一过程是一个过程定义 （PD），不是过程（P），团队不能看着别人的P好，就想着拿来就用，必须要找到自己的点。 2007年，Ivar Jacobson的新观点是“过程够了，实践吧（Enough of Processes: Let's Do Practices）”。 Doug Rosenberg和Kendall Scott的ICONIX过程借鉴了Ivar Jacobson和统一过程的思想，而且以其小巧易懂，受到不少开发人员的欢迎。
敏捷运动在20世纪90年代中期兴起，当时敏捷过程被称为“轻量”过程。2001年，Kent Beck、Alistair Cockburn、Ward Cunningham、Martin Fowler、Jim Highsmith、Ron Jeffries、Jon Kern、Robert C. Martin、Steve Mellor、Ken Schwaber等人聚集在犹他州的Snowbird，决定把“敏捷”作为新的过程家族的名称，并提出以下宣言：个体和交互胜过过程和工具，可以工作的软件胜过面面俱到的文件，客户合作胜过合同谈判，响应变化胜过遵循计划
源程序版本管理软件和项目管理软件
没有找到近几年的相关数据，根据Top 4 Free Version Control Systems For 2012中的数据，按照受欢迎程度是git，github，Mercurial，Buibucket
| 名称 | 优点 | 缺点 |
|---|---|---|
| Microsoft TFS |
|
|
| GIt |
|
|
| Mercurial |
|
|
| GitHub |
|
|
| Bitbucket |
|
|
| Trac |
|
|
| Bugzilla |
|
|
| Rationale |
|
|
| Apple Xcode |
|
|
151
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
