Week7阅读笔记

 

关于银弹：

Brooks在他最著名的这篇文章里指出，在软件开发过程里是没有万能的终杀性武器的，只有各种方法综合运用，才是解决之道。而各种声称如何如何神奇的理论或方法，都不是能杀死“软件危机”这头人狼的银弹。在软件工程中，虽然各种高阶语言的使用有效地移除了次要复杂度的问题，但是软件本身的必要复杂度却无法被移除掉。就比如我们平常的作业，面向课程中的电梯调度，电梯的状态变化和各种属性都必须考虑和实现，如果参考现实生活中的一些实际例子，情况就变得更加复杂。总而言之，要得到一个理想的程序，必须考虑多方面的问题，多人合作开发一个复杂的软件时，因为每个人的想法各有不同，团队初期的磨合过程也很费劲。

 

 

大泥球：

因为时间紧急，有时开发者会走捷径，拷贝相似功能的代码来赶进度，并且争取尽快发行第一个版本。他们一开始进展迅速，但是代码最终会变成大泥球，导致结构系统不够清晰。然而在时间和预算等现实因素的制约下，追求程序的完美又是不可能的，这就是一个纠结的地方。这个时候，代码复审，结对编程，有利于解决大泥球问题，结对编程时，一个人写代码，一个人在旁监督，相当于两个人的智慧的叠加，这样代码的可读性和正确率都增加了。

 

 

瀑布模型：

定义：瀑布模型（Waterfall Model） 是一个项目开发架构，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来。

瀑布模型的优点

1）为项目提供了按阶段划分的检查点。

2）当前一阶段完成后，您只需要去关注后续阶段。

3）可在迭代模型中应用瀑布模型。增量迭代应用于瀑布模型。迭代1解决最大的问题。每次迭代产生一个可运行的版本,同时增加更多的功能。每次迭代必须经过质量和集成测试。

4）它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。

 

 

教堂，集市：

《大教堂与市集》以Linux的核心开发过程以及作者自己主持开发的开放原始码软件──Fetchmail为讨论案例，对比两种完全不同的开发模式：绝大多数商业公司所采用的“大教堂”模式和Linux世界采用的“集市”模式。

• 大教堂模式（The Cathedral model）：源代码在软件发行后公开，但在软件的每个版本开发过程中是由一个专属的团队所控管的。作者以GNU Emacs及GCC这两软件为例。

• 市集模式（The Bazaar model）：源代码在开发过程中即在互联网上公开，供人检视及开发。作者以Linux核心的创始者林纳斯·托瓦兹带领Linux核心的开发为例，亦引用fetchmail的开发为例。18:14:05

 

 

个人项目、结对项目和团队项目，它们给了我很多不同的体验，我的感受集中在以下几点：

 

• 凡所学皆有用。

在之前我时常抱怨某些课程的“不人性化”，比如上个学期的面向对象课程，我的印象太深刻了，直到现在那些记忆仿佛都还是历历在目。我们相互查错，并且直接转化为相应的得分，所以我们经常看到谁又与谁发生冲突和争执，听说谁又在鸡蛋里挑骨头扣了多少多少分……整个学期充满了火药味，这是很残酷也很现实的竞争机制。然而这种高压确实在推动我们向前发展，不论是在技能上还是在心智上，我们都有很大的提高。

 

之前上过的一系列课程，比如C++、操作系统等等，都是在打好扎实的基础，这种基础包括能力上的，对编程的熟练程度，也包括表达上的，你和其他人之间的交流与协作的过程，是多方面的。有些我曾经会觉得质疑觉得多余的部分，现在回过头来再看看，也许会感到那是一笔宝贵的人生财富。你所学习的东西，或许在现阶段显得无足轻重，甚至你觉得不屑一顾，但是绝不是毫无用处。

 

 

• 计划赶不上变化。

永远都要做好至少提前三天的计划安排，永远都要准备好plan B，因为你不知道下一秒会有什么变化出现打乱这个安排。每个队员都有自己的事务，不仅是这个项目，还有其他别的麻烦，学校的各种竞赛，实验室布置的各种任务，留学生的事务，课程的变化，很难精打细算地在一个时间点把大家都聚集在一起。要做好计划的安排，也要注意到计划的时效性，不能雄心勃勃制定一个超长的时刻列表，也不能步步为营苛责每一个小的细节，这种对突发情况的应对能力，也是一个对团队非常重要的影响因素。

 

 

• 注重个体间的交互。

大学前两年，大部分时候我们都在做个人编程，然而在结对项目和团队项目中，我们需要把更多的注意力放在其他人身上。在结对和团队项目中，出现一些问题，这些问题中大部分都是与人与人之间的问题。比如任务分配没有交代清楚，截止时间没有完成任务等等很多种情况，这些不是在个人编程时能够约束和预见到的。出现这些问题，非常影响团队的士气和进度。而在敏捷软件开发中，团队的构建是一个非常关键的过程，一个优秀的团队，队员间的沟通、协调、合作的交互能力，比每个个体的单纯的编程能力、工具的掌握情况更加重要。同理，和用户保持交互关系，了解他们的需求和优先等级，对工作有益。

 

 

• 重视团会会议

团队会议非常重要，与人交互的最直截了当也是效率最高的方式就是面对面的交谈。仅仅通过电话，短信告知的零碎的信息帮助很少，团队会议让所有队员集思广益，讨论出一个最佳的方案。在团队士气低落时能够起到鼓励的作用，增强队员之间的信任和理解，在团队出现一些错误时也能起到反思和自我反省的作用，从而将之拉回正道，无论如何，在一个团队中，个人都应该为团队让步。