(个人阅读作业2：http://www.cnblogs.com/jiel/p/4030382.html ）
一.教堂与集市
1.1 定义
“两种不同的自由软件开发模式：
- 大教堂模式（The Cathedral model）：源代码在软件发行后公开，但在软件的每个版本开发过程中是由一个专属的团队所控管的。作者以GNU Emacs及GCC这两软件为例。
- 市集模式（The Bazaar model）：源代码在开发过程中即在互联网上公开，供人检视及开发。作者以Linux核心的创始者林纳斯·托瓦兹带领Linux核心的开发为例，亦引用fetchmail的开发为例。
此书的要义是“让够多人看到源代码，错误将无所遁形”（Given enough eyeballs, all bugs are shallow）。作者表示大教堂模式的软件开发让程式除错的时间大幅增加，因为只有少数的开发者可参与修改工作。市集模式则相反。”
——摘自维基百科
1.2 关于 Lost in CatB
原文地址：http://queue.acm.org/detail.cfm?id=2349257
中文版: http://www.ituring.com.cn/article/9363
“这是由Raymond在其书中称颂的集市模式导致的悲哀的现实：一坨脓包似的权宜代码，被一群盲目的根本不知IT架构为何物的所谓IT“专业人士”永无休止地复制着，粘贴着。这事儿放在今天你也许很难相信，但就是在这令人无比尴尬的混沌之下，沉睡着美轮美奂的Unix大教堂的遗迹，而Unix恰恰是以设计简约、功能实用、执行优雅而著称于世的。（世间荣耀就此消失……）”
“所谓质量，只有在某人对它负责时才有意义，而这个“某人”只能是一个人，不能是几个人——二重奏外。”
至于我们的项目有没有出现这样的问题，我只能说暂时还没有，或者说问题还没有如此尖锐，毕竟我们团队是开发的一个全新的项目。我倒觉得那些要在前几届的代码基础上进行增量开发的团队更可能遇到这些问题。
看了一些评论，有人赞同，也有人觉得反映过激，基本上是围绕着开源这一主题。
摘录几个评论：
“市场大了，不能强求都是工艺品，工厂化的地摊货也有需求“
“其实，忽略了一个事实，不管开源还是商用，都需要商业机会和商用环境，这就是市场杠杆，在市场需要的基础上，去谈论技术优劣与否，才有意义，否则就是吵吵嚷嚷。 就技术论技术，意义何在？世上哪有完美的事物？ 开源不等于拒绝商业，有市场需求，就有其存在的空间，不管你怎么讨厌它。 ”
“The problem is in the use of "C" ”
“.. .We need at last a new start (maybe Java or a cleaner C with Java influences but certainly not C++)."-----（这意思是说C语言本身的缺陷才是罪魁祸首？）
总之，看评论是一件很有趣的事儿，不同思想间的碰撞~
二. Worse is Better
原文链接： The Rise of Worse is Better
关于Worse is Better，摘录原文里的几段话
”the right thing.“:
-
Simplicity-the design must be simple, both in implementation and interface. It is more important for the interface to be simple than the implementation.
-
Correctness-the design must be correct in all observable aspects. Incorrectness is simply not allowed.
-
Consistency-the design must not be inconsistent. A design is allowed to be slightly less simple and less complete to avoid inconsistency. Consistency is as important as correctness.
-
Completeness-the design must cover as many important situations as is practical. All reasonably expected cases must be covered. Simplicity is not allowed to overly reduce completeness.
”The worse-is-better philosophy“:
-
Simplicity-the design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design.
-
Correctness-the design must be correct in all observable aspects. It is slightly better to be simple than correct.
-
Consistency-the design must not be overly inconsistent. Consistency can be sacrificed for simplicity in some cases, but it is better to drop those parts of the design that deal with less common circumstances than to introduce either implementational complexity or inconsistency.
-
Completeness-the design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface.
the right thing:
四个性质的重要性：完整性>简单性;
一致性=正确性>简单性
总之，简单性处于重要性的底层位置(在简单性中，重要性：实现<接口)
worse-is-better：
四个性质的重要性：简单性>正确性, 简单性>一致性,简单性>正确性
总之，简单性处于重要性的顶层层位置(在简单性中，重要性：实现>接口)
随后我看了Is Worse Really Better，里面是这样总结的：
With the-right-thing, designers are equally concerned with simplicity, correctness, consistency, and completeness. With worse-is-better, designers are almost exclusively concerned with implementation simplicity and performance, and will work on correctness, consistency, and completeness only enough to get the job done, sacrificing any of these other qualities for simplicity.
我觉得这样的评判有失偏颇，特别是对于the-right-thing的总结，我完全不能同意：4个方面明显是有所侧重的，而非“equally concerned”，而且这两篇文章还是同一个作者写的，我实在想不通，或许是我太过字斟句酌而误解了作者的本意？
不过看完我确实挺讶异的，因为一开始看标题，我猜到这是一篇要反对自己之前所提的”worse-is-better”的文章，结果它后面根本不是反驳，而更像是一篇精悍的总结，再次重申了worse-is-better的有效性。不过我还是不能理解最开始的那段,语气像是很反对worse-is-better似的，难道是为了欲扬先抑？或者完全是我想多了？
三.瀑布模型
（原文链接：http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf）
1970年温斯顿·罗伊斯（Winston Royce）提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。
3.1定义
瀑布模型（Waterfall Model） 是一个项目开发架构，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来。
3.2核心思想
瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
3.3优点
1）为项目提供了按阶段划分的检查点。
2）当前一阶段完成后，您只需要去关注后续阶段。
3）可在迭代模型中应用瀑布模型。
增量迭代应用于瀑布模型。迭代1解决最大的问题。每次迭代产生一个可运行的版本,同时增加更多的功能。每次迭代必须经过质量和集成测试。
4）它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。
3.4缺点
1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
4）瀑布模型的突出缺点是不适应用户需求的变化。
3.5对于瀑布模型的误解
（http://www.youtube.com/watch?v=X1c2--sP3o0（这个视频做得好玩啊，音乐也很给力~）
误解是什么呢？
大家以为瀑布的生命周期的特点是顺序（sequential）、单次（single-pass）的，以为一个个阶段地完成下来就可以得到可用的软件了
实际是什么呢？
大家所以为的情形只是瀑布模型中最简单的一种情况，对于大型复杂项目而言，要做相邻步骤的回溯，解决上一阶段未能解决的问题。
四.敏捷开发
（原文：http://martinfowler.com/articles/newMethodology.html ）
4.1the reasons for agile methods
“…The most immediate difference is that they are less document-oriented, usually emphasizing a smaller amount of documentation for a given task. In many ways they are rather code-oriented: following a route that says that the key part of documentation is source code.
However I don't think this is the key point about agile methods. Lack of documentation is a symptom of two much deeper differences:
-
Agile methods are adaptive rather than predictive. Engineering methods tend to try to plan out a large part of the software process in great detail for a long span of time, this works well until things change. So their nature is to resist change. The agile methods, however, welcome change. They try to be processes that adapt and thrive on change, even to the point of changing themselves.
-
Agile methods are people-oriented rather than process-oriented. The goal of engineering methods is to define a process that will work well whoever happens to be using it. Agile methods assert that no process will ever make up the skill of the development team, so the role of a process is to support the development team in their work.“
参考百度百科上的翻译：
敏捷型与滞重型方法（Engineering methods？直译的话是工程化方法，但是还没找到比较权威的解释）有一些显著的区别。其中一个显而易见的不同反映在文档上。敏捷型不是很面向文档，对于一项任务，它们通常只要求尽可能少的文档。从许多方面来看，它们更象是“面向源码”（code-oriented）。事实上，它们认为最根本的文档应该是源码。
但是，我并不以为文档方面的特点是敏捷型方法的根本之点。文档减少仅仅是个表象，它其实反映的是更深层的特点：
敏捷型方法是“适配性”而非“预设性”。 重型方法试图对一个软件开发项目在很长的时间跨度内作出详细的计划，然后依计划进行开发。这类方法在计划制定完成后拒绝变化。而敏捷型方法则欢迎变化。其实，它们的目的就是成为适应变化的过程，甚至能允许改变自身来适应变化。
敏捷型方法是“面向人”的(people-oriented) 而非“面向过程”的 (process-oriented)。 它们试图使软件开发工作顺应人的天性而非逆之。它们强调软件开发应当是一项愉快的活动。
敏捷开发方法的核心思想：适应变化和以人为本
4.2 预测性VS适应性
1.将设计与构建分离
So the approach for software engineering methodologies looks like this: we want a predictable schedule that can use people with lower skills. To do
this we must separate design from construction. Therefore we need to figure out how to do the design for software so that the construction can be
straightforward once the planning is done.
2.需求的不可预测性
3.通过迭代去控制一个不可预测的过程
Mary Poppendieck
"A late change in requirements is a competitive advantage".
A predictive project is often measured by how well it met its plan. A project that's on-time and on-cost is considered to be a success. This measurement is nonsense to an agile environment. For agilists the question is business value - did the customer get software that's more valuable to them than the cost put into it. A good predictive project will go according to plan, a good agile project will build something different and better than the original plan foresaw.
对于可预测的工程而言，按时交付（on-time）、花费没有超过预算（on-cost）就可以认为是一个成功的项目；对于敏捷方法却并非如此：时间和预算不再是评判好坏的标准，取而代之的是项目本身的商业价值，要看做出的软件的价值是否超出了客户的投入成本。可预测的过程通常是依照计划按部就班地实行，而敏捷项目往往能够构建与原计划不一样甚至更好的东西来。
4.3 自适应过程
在每次迭代结束后，都需要开个小会，问自己以下问题
- What did we do well? 我们完成了什么？
- What have we learned?我们从中学到了什么？
- What can we do better? 我们如何能做得更好？
- What puzzles us? 我们有什么疑惑？
这样可以让我们下一阶段的工作做得更好，完成得更加顺利
例子：
Extreme Programming, Scrum, Lean Development,
XP begins with five values (Communication, Feedback, Simplicity, Courage, and Respect).
4.4最后的一些tips
1.首先，敏捷开发并不是适用于所有人的Using an agile method is not for everyone
2.敏捷开发是一个轻量级方法
it is much less of a step than using a heavyweight method
the light weight of agile methods is an advantage. Simpler processes are more likely to be followed when you are used to no process at all.
3.The first step is to find suitable projects to try agile methods out with.你得找到一个自己真心想要融入其中、为其工作的团队
4.start learning on a project of a more manageable size.团队的规模不要太大，易于管理的规模更适于你开始
5.take a project that's a little bit more critical than you are comfortable with. 如果一个项目成功与否没什么人在意，你在其中自然可以过的“舒服”，因为没有人在旁边监督项目的质量，可是这样就无法锻炼自己的能力了
6.find someone more experienced in agile methods to help you learn.向有敏捷开发经验的人寻求帮助
once you've found a good mentor, follow their advice.找到了好导师，听取他们的建议
One of the open questions about agile methods is where the boundary conditions lie….
7.it's so hard to decide what success and failure mean in software development, as well as too many varying factors to easily pin down the source of problems.
So where should you not use an agile method? I think it primarily comes down to the people.
自己不想要干，就不用强求I think that this means you should never try to impose agile working on a team that doesn't want to try it.
五.关于软件工程方法论的用处
原文：
（http://agile.dzone.com/articles/jez-humble-why-software
http://continuousdelivery.com/2012/08/why-software-development-methodologies-suck/ ）
As Daniel Kahneman says in Thinking Fast and Slow, there are “two basic conditions for acquiring a skill: an environment that is sufficiently regular to be predictable; [and] an opportunity to learn these regularities through prolonged practice.”
有规律的可以预测的环境、了解这个环境中的规律的机会
可问题是，一般的软件项目是无法保证一个可以预测的
But traditional software projects are the opposite of a regular, predictable environment. The only good measure of success of a project – did the end result create the expected value over its lifetime? – is so distant from the critical decisions that caused that success or failure that it’s rare for anybody from the original team even to be present to get the feedback.
The root cause in all these cases – the reason the environment is not regular – is that the feedback loop between making a change and understanding the result of that change is too long. The word “change” here should be understood very generally to mean change in requirements, change in methodology, change in development practices, change in business plan, or code or configuration change.
It’s virtually impossible for us to practice continuous improvement, to learn how to get better as teams or as individuals, and to acquire the skills that enable the successful creation of great products and services – unless we focus on getting that feedback loop as short as possible so we can actually detect correlations, and discern cause and effect.
作者随后在评论里也说道：
software projects can be made more regular through reducing cycle times
My point is that reducing cycle time and increasing feedback are necessary conditions for gathering scientific evidence. The problem is not that people aren't trying hard - the problem is they're trying hard to do the wrong things.
至于评论，有人感叹人才（smart people）难找，有人以自己的开发经历为例说了Tight feedback loops的种种好处，当然也有人觉得对软件工程方法论过于关注了：
I think much attention is given to issues of methodology instead of programmers skills which is the crux of every succesful software. Most methodologies takes up much time, thereby delaying the time frame for the project completion. Originators and proponents of such methodologies clamor for fame and superiority of their methods.
最后
总的来说，我自己对于软件工程的方法论也还没有什么心得理解，所以笔记也是很混乱，毫无逻辑性。不过通过这次阅读，到底是对软件工程的一些模型、概念有一些初步的了解，也算是不错的收获。