47、（代码大全2）能有效地开发高质量的人们，在长年累月中积累了大量的技术、技巧和决窍。技术并不是规矩，它只是分析工具。好的工匠知道完成某项工作要用哪样工具，也知道该怎样正确地使用。程序员也该这样。编程方面的知识学得越多，你脑中的工具箱中就会有更多的分析工具，也会知道该在何时用这些工具，以及怎样正确地使用它们。
在软件领域里，专业的咨询人员有时会让你专用某种软件开发方法而远离其他方法。这样并不妥当，因为当你百分之百地依赖于某一方法论时，你就只会用一种方法去看世界了。某些情况下，对于你所面临的问题还有其他更好的方法，你可能错失良机。这种“工具箱隐喻”能够帮助你把所有的方法、技术以及技巧留在脑海中--------合适的时候即可拿来就用。
48、开发商业系统的项目往往受益于高度迭代的开发法，这种方法的“计划、需求、架构”活动与“构建、系统测试、质量保证”活动交织在一起。
50、选择序列化还是迭代法的情况。
序列化：（1）、需求相对稳定
（2）、设计直截了当，而且理解透彻。
（3）、开发团队对于这一领域非常熟悉。
（4）、项目风险很小。
（5）、“长期可预测性”很重要。
（6）、后期改变需求、设计和编码的代价很可能较高昂。
迭代法：（1）、需求并没有被理解透彻，或者出于其他理由你认为 它是不稳定的。
（2）、设计很复杂，或者有挑战性，或者两者兼具。
(3)、开发团队对于这一应用领域不熟悉。
（4）、项目包含许多风险。
（5）、“长期可预测性”不重要。
（6）、后期改变需求、设计和编码的代价很可能较低。
事实上，在软件开发中，适用迭代式开发法的情况比适用序列式开发法的情况多得多。你可以使前期准备适应某个特定项目，办法是调整其正式程度和完备程度，到你觉得合适为止。
你应该首先确定哪些前期准备活动适合你的项目。有些项目在前期准备上面花的时间太少了，结果使得在构建活动中遇到大量不必要的反复修改，同时阻碍了项目的稳步前进。有些项目则预先做了太多的事情，固执地坚持原有的需求和计划，后来事实证明这些需求和计划是无效的，这同样阻止了构建活动的顺利进展。
51、（代码大全2）“一旦客户接受了一份需求文档，就再也不做更改“是一个美好的愿望。然而，对一个典型的项目来说，在编写代码之前，客户无法可靠地描述他们想要的是什么。问题并不在于客户是低级生物。就如同你做这个项目的时间越长，对这个项目的理解也就越深入一样，客户参与项目的时间越长，他们对项目的理解也就越深入。开发过程能够帮助客户更好的理解自己的需求，这是需求变更的主要来源。计划严格依照需求行事，实际上就是计划不对客户的要求做出回应。
典型情况下需求会有多少改动？ＩＢＭ和其他公司的研究发现，平均水平的项目在开发过程中，需求会有２５％的变化。在典型的项目中，需求变更导致的返工占到返工总量的７５％到８５％。
52、（代码大全2）如果你的需求不够好，那么就停止工作，退回去，先把它做好，再继续前进。当然，因为在此期间你会停止编码，所以感觉似乎进度会落后。不过，假设你正开车从芝加哥到洛杉矶，突然看到纽约的路牌，那么停下来查看路线图是浪费时间吗？当然不是，如果没有对准正确的方向，那就要停下来检查一下路线。
53、（代码大全2：关于架构的）架构应该描述所用到的主要文件和数据表的设计。它应该描述曾经考虑过的其他方案，并说明做出选择的理由。如果应用程序要维护一个客户ID的列表，而架构师决定使用顺序访问的列表来表示该ID表，那么文档就应该解释为什么顺序访问的列表比随机访问的列表、堆栈、散列表要好。在构建期间，这些信息让你能洞察架构师的思想。在维护阶段，这种洞察力是无价之宝。离开它，你就像看一部没有字幕的外语片。
数据通常只应该由一个子系统或一个类直接访问：例外的情况就是透过访问器类或访问器子程序――――以受控且抽象的方式来访问数据。
架构应该详细定义所用数据库的高层组织结构和内容。架构应该解释为什么单个数据库比多个数据库要好（反之亦然），解释为什么不用平坦的文件则要用数据库，指出与其他访问同一数据的程序的可能交互方式，说明会创建哪些数据视图，等等。
54、（代码大全2：关于架构的）系统构架需要考虑的问题：
（1）、程序组织 （2）、主要的类
（3）、数据设计 （4）、业务规则
（5）、用户界面 （6）、资源管理
（7）、安全性 （8）、性能
（9）、可伸缩性 （10）、互用性
（11）、国际性、本地化 （12）、输入输出
（13）、错误处理 （14）、容错性
（15）、架构的可行性 （16）、过度工程
（17）、关于“买”还是“造”的决策 （18）、关于利用的决策
（19）、变更策略 （20）、架构的总体质量
扫一扫
1297
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
