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》描述了一种高度迭代的开发法,注重迭代地开发需求和设计,同时结合构建。极限编程法几乎不提供长期的可预见性,但它提供了高度的灵活性。