我过去是怎么做的：
单纯把编程作为工作
这样做为什么不好：
没有乐趣就没有动力
解决办法：
第一章 焦油坑
- 编程系统产品
只有编程系统产品才是真正有用的产品，是大多数系统开发的目标。
-
职业的乐趣
-
创建事物的纯粹快乐；eg: 当自己写完第一个hello world时候的欣喜
-
来源于开发对他人有用的东西；eg: 现在的组队项目bbs
-
将相互啮合的零件组装在一起
-
持续学习，和don't repeat yourself（《程序员修炼之道》里有讲） 原则相一致
-
来自于在易于驾驭的介质上工作
-
职业的苦恼
- 源于追求完美
- 由他人设定目标，供给资源和提供信息。
- 依靠他人不合理的程序真的很痛苦
- debug真的很酸爽
- 产品完成了却显得过时了
第二章 人月神话
缺乏合理的进度安排是造成项目滞后的最主要原因！
-
我们对估算技术缺乏有效的研究（《程序员修炼之道》有讲估算的技巧），更加严肃的说，它反映了一种悄无声息但并
不真实
的假设——
一切都将运作良好- 这句话说的太精辟了！一切都将运作良好根本不存在的！以前定每日计划每周计划，都坚持不久了就会fact！=plan，这就是自己在列计划的时候，默认了一切都将运作良好
-
错误的将工作量和进度相互混淆
- 每日能完成的就那么多，进度需求大了，你还是能完成那么多，不会有超能力
-
对自己的估算缺乏信心
-
对进度缺少跟踪和监督
-
当意识到进度的偏移时，下意识（以及传统）的反应是增加人力。
- 这就像汽油灭火一样，只会更糟。
- 当计划赶不上变化导致进度变慢，不应该用蛮力来搞定。
-
乐观主义
错误的假设：一切都将运作良好，每一项任务仅花费它所”应该“花费的时间
所遇到的延迟是一个概率分布曲线，‘不会延迟’具有限定的概率。
- 人月
人员和时间的关系：较小的组合更方便
我觉得我们可以最近前后端分开工作，前后端的交流给前后端的组长来完成。
- 系统测试
单元调试和系统测试是对进度安排最大的可能出错的地方。系统测试的安排常常是编程中最不合理的部分。
软件任务经验安排的经验法则：
1/3 计划
1/6 编码
1/4 构件测试和早期系统测试
1/4 系统测试，所有的构件已完成
这也是对我们的团队project的一个指导吧，给的时间看起来就不多了，实际留给编码的时间更少
- 空泛的估算
做出可靠的估计是很难的（尤其当缺乏数据的时候）
解决方案：
开发并推行生产率图表、缺陷率图表、估算规则等
坚持估计，确信自己的经验和直觉总比从期望派生出来的结果要强的多
- 重复产生的进度灾难
在新的进度安排中分配充分的时间，以确保工作能仔细、彻底地完成。从而无需重新确定时间进度表！
向进度落后的项目中增加人手，只会使项目更加落后
第三章 外科手术队伍
效率搞和效率低的实施者之间个体差异非常大，经常能够达到数量级的水平。
- 问题：效率&完整性 vs 时间上的要求
- Mills的建议（职责分配）
- 首席程序员
- 副手
- 管理员
- 编辑
- 两个文秘
- 程序职员
- 工具维护人员
- 测试人员
- 语言专家
第四章 贵族专制、民主政治和系统设计
- 概念的完整性
这应该是最重要的考虑因素，它就是说，为了反应一系列连贯的设计思路，宁可省略一些不规则的特性和改进，也不提倡独立和无法整合的系统，哪怕它们其实包含着许多很好的设计。
- 获得概念的完整性
目标是易用性，功能和概念的复杂程度的比值才是系统设计的最出众测试标准，但是功能本身或者简洁都无法成为一个好的设计评判标准。
- 贵族专制统治和民主政治
概念的完整性必须由一个人，或者非常少数互有默契的人员来实现。
- 必须将体系结构和实现区分开来
第五章 画蛇添足
-
结构师的交互准则和机制
-
牢记开发人员承担创造性和发明星的实现责任，所以结构是只能建议，而不能支配
-
时刻准备着为所指定的说明建议一种实现的方法，同样准备接受其他任何能达到目标的方法
-
对上述的建议保持低调和不公开
-
准备放弃所坚持作的改进建议
-
自律——开发第二个系统所带来的后果
史前时代，焦油坑吞噬了成千上万的大型猛兽，正如今天的大型软件项目则令无数庞大的开发团队陷入无从逃脱的窘境。软件程序按其规模和目标的不同，对开发过程的要求也有极大的不同，这给软件开发这一职业带来无穷乐趣，同时也是这一行业苦恼的根源。对啊，任何事都有它的两面性。
标签：02,神话,读书笔记,编程,系统,完整性,进度,测试,估算 From： https://www.cnblogs.com/Arkiya/p/17338218.html