《代码大全》阅读笔记____[第三章] 三思而后行：前期准备

1、在构建活动开始之前，准备工作要做周全

 

2、关注质量就是提高生产力的最佳途径。

 

3、       如果你在项目的末期强调质量，那么你会强调系统测试

              如果你在项目的中期强调质量，那么你会强调构建实践

              如果你在项目的开始阶段强调质量，那么你会计划、要求并且设计一个高质量的产品

 

4、准备工作的中心目标就是降低风险：一个好的项目规划者能够尽可能早的将主要的风险清除掉，以使项目的大部分工作能够尽可能平稳地进行

 

5、如果不能首先把这项工作做好，那么做再多也没有意义

 

6、人生苦短，当有大量更好的选择摆在你面前的时候，在一个荒蛮的软件企业中工作是不明智的

 

7、在实现一个系统之前，你需要理解“这个系统应该做什么”，以及“它该如何做到这些”

 

8、在开始编码、测试、调试之前进行需求分析和架构设计----才能保证关键的方面都做正确

 

9、从管理的角度看，做计划意味着确定项目所需要的时间、人数以及计算机台数。从技术角度讲，做计划意味着弄清楚你想要建造的是什么，以防止浪费钱去建造错误的东西。

 

10、程序员是软件食物链的最后一环。架构师吃掉需求，设计师吃掉架构，而程序员则消化设计。

 

11、发现错误的时间要尽可能接近引入该错误的时间。缺陷在软件食物链里面呆的时间越长，它对食物链的后级造成的损害就越严重。

 

12修复缺陷的成本随着“从引入缺陷到检测到该缺陷之间的时间”变长而急剧增加。

 

13、忽略前期准备的迭代式开发法，最终明显会比“密切关注前期准备工作的序列式开发法”付出更高的代价。

 

14、“尽早把哪些是最关键的需求要素和架构要素确定下来”是很有价值的。

 

15、一条很有用的经验规则是，计划好预先对大约80%的需求做出详细说明，并给“稍后再进行详细说明的额外需求”分配一定的时间。

 

16、“问题定义”只定义了“问题是什么”，而不涉及任何可能的解决方案。

 

17、问题定义应该用客户的语言来书写，而且应该从客户的角度来描述问题。

 

18、“需求”详细描述软件系统应该做什么，这是达成解决方案的第一步。

 

19、如果你在编码过程中发现了一个代码上的错误，你只需要修改几行代码，然后就能继续工作。但是如果你在编码的时候发现了一个需求错误，那你就得改变设计，使之符合更改后的需求。

 

20、需求像水。如果在冻结了，就容易在上面展开建设。

 

21、如果没有好的需求，你可能对问题有总体的把握，但却没有击中问题的特定方面。

 

22、如果你的需求不够好，那么就停止工作，退回去，先把它做好，再继续前进。

 

23、演进交付是一种分阶段交付系统的方法。

 

24、“考虑自己的决定所带来的商业影响”的程序员的身价与黄金相当

 

25、是否详细定义了相互竞争的特性之间的权衡----例如，健壮性与正确性之间的权衡

 

26、需求是否足够清晰

 

27、是否每条需求都是可测试的？是否可能进行独立的测试，以检验满不满足各项需求

 

28、软件架构（softwarearchitecture）是软件设计的高层部分，是用于支撑更细节的设计的框架

 

29、架构指的是适用于整个系统范围的设计约束，而高层设计指的是适用于子系统层次或多个类层次上的设计约束（但不是整个系统范围的设计）。

 

30、一个经过谨慎考虑的架构为“从顶层到底层维护系统的概念完整性”提供了必备的结构和体系，他为程序员提供了指引----其细节程度与程序员的技能和手边的工作相配。

 

31、离开了良好的软件构架，你可能瞄准了正确的问题，但却使用了错误的解决方案。也许完全不可能有成功的构建。

 

32、如果你不能向一个六岁小孩解释某件事，那么你自己就没有真正理解它

 

33、维护“设计的缘由”至少与“维护设计本身”一样重要

 

34、每个构造块应该负责某一区域的事情，并且对其他构造块负责的区域知道得越少越好

 

35、构架应该详细定义所用的主要的类。它应该指出每个主要的类的责任，以及该类如何与其他类交互。它应该包含对类的继承体系、状态转换、对象持久化等的描述。如果系统足够大，它应该描述如何将这些类组织成一个个子系统。

 

36、架构应该详细定义所用数据库的高层组织结构和内容。

 

37、精心设计的用户界面架构决定了最终做出来的是“人见人爱的程序”还是“没人爱用的程序”。

 

38、架构应该模块化

 

39、架构应该描述实现设计层面和代码层面的安全性的方法

 

40、架构可以决定，在需要的时候，实在代码中直接嵌入字符串；还是将这些字符串封入某个类，并透过类的接口来使用它；或者将这些字符串存入资源文件。架构应该说明选用的是哪种方案，并解释其原因。

 

41、有人估计程序中高达90%的代码是用来处理异常请款、进行错误处理、或做簿记工作，意味着只有10%的代码是用来处理常规的情况

 

42、架构应该规定代码何时能抛出异常，在什么地方捕获异常，如何记录这些异常，以及如何在文档中描述异常。

 

43、可以将错误传递到专门处理错误的类进行处理

 

44、容错是增强系统可靠性的一组技术，包括检测错误；如果可能的话从错误中恢复；如果不能从错误中恢复，则包容其不利影响。

 

45、架构应该论证系统的技术可行性。

 

46、健壮性是指“系统在检测到错误后继续运行”的能力。

 

47、在软件中，链度的强度不是取决于最薄弱的一环，而是等于所有薄弱环节的乘积。

 

48、在现代的GUI环境中编程的最大好处之一是，大量功都能自动实现：图形类、对话框管理器、键盘与鼠标的事件处理函数、能自动与任何打印机或显示器打交道的代码等等。

 

49、因为对于程序员和用户来说，构建软件产品都是一个学习过程，所以在开发过程中产品很可能会发成变化。

 

50、软件构架师面临的一个主要挑战是，软构架足够灵活，能够适应可能出现的变化。

 

51、构架应该列出已经考虑过的有可能会有所增强的功能，并说明“最有可能增强的功能同样是最容易实现的”。

 

52、优秀的构架规格书的特点在于，讨论了系统中的类、讨论了每个类背后的隐藏的信息、讨论了“采纳或排斥所有可能的设计替代方案”的根本理由。

 

53、构架应该包含多个视角（视图）。

 

54、是否详细定义了数据库的组织结构和内容？

 

55、是否描述了用户界面设计的策略？

 

56、是否将用户界面模块化，使界面的变更不会影响程序其余部分？

 

57、构架是否为每个类、每个子系统、或每个功能域提出空间和时间预算？

 

58、是否提供了一套的错误处理策略？

 

59、是否证实了系统各个部分的技术可行性？

 

60、顶层设计是否独立于用作实现它的机器和语言？

 

61、是否说明了所有主要决策的动机？

 

62、如果需求在任何项目上都不稳定----无论正式项目或非正式项目----那就将需求分析工作视为独立的项目来做。

 

63、你是否辨明了自己所从事的软件的类型，并对所用的开发方法做出相应的裁剪？

 

64、构建活动的准备工作的根本目标在于降低风险。

 

相关书籍：

1、Kruchten,Philippe. 《The Rational UnifiedProcess:An Introduction》这本书展示了一种“以架构为中心，以用例驱动”的项目来发方法。----第3章 三思而后行：前期准备

2、Beck,Kent. 《Extreme Programming Explained:Embrace Change》描述了一种高度迭代的开发法，注重迭代地开发需求和设计，同时结合构建。极限编程法几乎不提供长期的可预见性，但它提供了高度的灵活性。