第8章 白板上的即时贴
获得更好进展的关键是将软件改进到程序员自己可以使用的程度。
白板上的即时贴：用贴纸，每张纸表示大致同等的工作量。每张即时贴代表各开发者一个月或两个月的工作时间。先在墙上循“点号版本”的顺序贴上，然后就能对每一轮计划的工作和自己是否脱离显示一目了然。用贴纸法来讨论项目各个小版本应该具有的功能特性，也是敏捷开发里重点推广的。
“吃你自己的狗食”的意思是开发者必须使用自己正在做的产品。
在传奇般的施乐帕罗· 阿尔托研究中心(20 世纪70 年代发明了现代个人计算技术），研究队伍领导人鲍勃· 泰勒提出了这种说法：
“吃狗食则是迫使开发者把鼻子伸到产品的问题中、加速发现和修正缺陷的低调且实用的方法。”
WebDAV 的工作机制是扩展HTTP——Web 服务器和浏览器之间赖以互相通讯的协议——增加了让用户在远端服务器上编辑文件的新命令。
Chandler一直具有两面性——一方面，它是用户管理信息的软件应用；另一方面，它是—种“应用框架”或“平台”一开发者可在上面添加新酷特性的一种基础。由于卡普尔和OSAF 团队逐渐勉强接受了不能两者得兼的事实，他们首先选择做应用程序。
第9章 方法
从Chandler 项目的最早期开始，卡普尔就坚持要做诚实、现实的计划和进度安排。但项目在满足进度方面却拥有不佳的记录：平均6个月能发布一个版本，但计划却总假设应在3 、4 个月内完成一个版本。部分原因或许是在软件开发和其他领域中计划总是超出了能预见的范围。
Chandler项目的软件开发者很少成组地共同开发一系列项目：他们不太像运动队或是军队单位，也不太像合唱团，而更像是专才们为制作一部电影而临时组合然后解散，再重新为下一部电影组合起来。每次到新团队中开始做新项目时，他们大概还是会按下”重置”按钮， 根据某些首要原则设计出一套新的工作流程。
结构化编程的主要规则：“程序的每一层都该自成一体。”
为了摆脱软件制作的焦油坑，无数软件实行者在不断探索。只有个体开发者为个人工作制定计划并遵循，项目才有控制和管理的基础。想法是好的，但往往很少有人将之付诸于行动。软件的速度和质量造成人月神话的恶性循环，但是质量是保证软件继续发展的前提。
汉弗里在IBM 执行强制进度纪律的成功基于两条原则：
计划是强制性的；
计划必须符合现实情况——“从底向上”，依据那些负责按计划执行的程序员的经验和知识而来，而不是“从顶至下”，靠管理者拍脑袋或对市场的期望而来。
在SEI，汉弗里和同事们创建了软件成熟度模型(Capability Maturity Model, CMM ), 作为一种衡量软件开发组织品质的准绳。
CMM 原则的简单的概述
位于第一级的组织基本上什么都没做。
第二级组织做一些计划、跟踪、配置管理工作，也讨论质量保证之类的话题。
第三级组织开始定义过程——如何工作、如何完成任务、可训练的事项等。
第四级，他们采用衡量准绳。他们有一套真正跟踪和管理自己所做工作的框架， 一种可统计跟踪的系统。
第五级组织拥有持续改进的过程。
CMM主要目的是帮助规模庞大的组织改进软件进度和质量。
模式运动让个体程序员有了一条解决问题的新路子，并且提炼经验、供同事所用。但它并不太有助于找到在更大项目中协调工作的方法。
瀑布模型
将项目切分为依序进行的多个独立阶段，比如需求定义、设计、实现、集成、测试和发布。每个阶段需在下一阶段开始前完成。
这套做法在纸上看似合乎逻辑，但实践起来却总是导致延误、混乱和灾难。每个阶段都耗时无算，但没一个工作正常的。“大设计优先”引发大延误，“大爆炸式集成“一一单独编写代码的各个主要部分，在项目将近结束时拼到一起——导致系统崩溃。
螺旋模型
将开发切割为六个月到两年的“迭代周期”——更快生产出可工作代码的小瀑布，从部分完成的产品使用中得到反馈、指导下一步迭代。
快速应用开发(Rapid Application Development)
RAD承诺通过快速原型设计和更紧迫的迭代周期，依靠新工具让计算机处理一些繁重的编程工作，加速完成软件的交付。RAD 帮助软件公司更敏捷地工作。
敏捷软件开发(Agile Software Development)
个体和交互胜于过程和工具
可工作的软件胜于面面俱到的文档
客户协作胜于合同谈判
响应需求胜于遵循计划
尽管右栏条目有其价值，但我们更看重左栏条目。
争球式开发(Scrum)
将项目分解为30 天一轮的“竞跑"'强调每天开例会、维持项目在正轨上运转。
极限编程
采用了一系列广为接受的方法，并将这些方法的使用推至极限。
祖尔测试
索伯斯基提出了祖尔测试( Joel Test)，基于他自己的经验和“集体智慧＂，给出一套快餐式原则， 判断开发组织是否符合这条原则—— “不会叫人头疼的CMM”。
祖尔测试询问以下十二个问题：
1）Do you use source control? 你们使用源代码控制吗？
2）Can you make a build in one step? 你们一步就能完成构建吗？
3）Do you make daily builds? 你们做每日构建吗？
4）Do you have a bug database? 你们有缺陷数据库吗？
5）Do you fix bugs before writing new code? 你们会在写新代码之前修复缺陷吗？
6）Do you have an up-to-date schedule? 你们有与当前工作吻合的进度安排吗？
7）Do you have a spec? 你们有规约吗？
8）Do programmers have quiet working conditions? 程序员工作环境安静吗？
9）Do you use the best tools money can buy? 你们采用了市面上最好工具吗？
10）Do you have testers? 你们有测试人员吗？
11）Do new candidates write code during their interview? 你们会要求应聘者在面试时写代码吗？
12）Do you do hallway usability testing? 你们做走廊可用性测试吗？
“得12分为最佳，“索伯斯基写道， “11分还可以接受，得10分或更低就说明你们问题大了。其实多数软件组织只能得2、3分，他们迫切需要帮助，因为微软等公司一直都得12 分。”
第10章 工程师和艺术家
软件设计有两个意思：“其一是我们要打造的产品。其二是让产品得以实现的软件工程。我相信有两种不同的角色一一主题专家和软件工程师。”
延后绑定是计算机科学中的—个术语，表示编程语言提供给程序员以更多灵活性的能力。
兴趣决定了编程是工程师的工作还是艺术家热爱的作品，为之创新和废寝忘食的魔力。培养兴趣对学习者很重要，而坚持兴趣对工程师很重要。
在计算领域中，变化不可避免，我们设计的系统应该让我们从变化中学习、并且反过来影响变化。
在PARC 时，我们的理念就是，既然你永远不会踏入同一条河流，用户界面的第一要素是一种学习环境——可以从不同途径探索，随用户使用该环境的时间进程不断改变。“换言之，用户从计算机处学到新东西后，就能自己修改系统，以期发挥所学。
高德纳写的书名叫《计算机程序设计艺术》，他在1984年获得图灵奖时发表感言说，“计算机编程是门艺术”。写《计算机程序设计艺术》这本书他花了十年，写TeX和metafont程序没想到也花了近10年。他宣称，写软件要比写书“难多了”。
第11章 通往狗食版之路
“吃你自己的狗食”的意思是开发者必须使用自己正在做的产品。
在传奇般的施乐帕罗· 阿尔托研究中心(20 世纪70 年代发明了现代个人计算技术），研究队伍领导人鲍勃· 泰勒提出了这种说法：
“吃狗食则是迫使开发者把鼻子伸到产品的问题中、加速发现和修正缺陷的低调且实用的方法。”
吃自己的狗粮，这种思路确实有助于提升软件质量和用户体验，想想连自己都不屑一用的软件凭什么去折磨用户呢？
软件中的递归很危险，因为它必须要有出口。否则，奇异循环就会变作无限循环，而计算机就会堆栈溢出。终结条件是递归定义中最重要的部分。
标签：Do,读书笔记,代码,项目,工作,开发者,狗食,软件,梦断 From： https://www.cnblogs.com/zzfdbk/p/17471081.html