【读书笔记】——《代码大全》（一）

Welcome to Software Construction

之前总听到老师、师兄谈到构建、重构之类的词语，一直认为“构建”就是“编码”。读完了第一章，才对“构建”有了进一步的认识。构建活动主要关注于编码与调试，但也包含详细设计、单元测试、集成测试以及其他一些活动。

 

构建不是机械化的，它需要可观的创造力和判断力。一个不那么完美的软件的开发，也许缺少需求分析、架构设计与系统测试，但一定不会缺少构建活动。

 

Metaphors for a Richer Understanding of Software Development

这一章作者启发我们运用隐喻的方式来更好地理解软件构建的过程。我的理解是，隐喻，在这里指建模，它没有绝对的正确与错误之分，而只有贴切与不贴切之分。

  

对于软件构建来说，“努力创造真正的原创成果”的开发效率，往往低于专注于重用以往项目的一些设计思想、代码以及测试用例的开发效率。软件开发并不像写信或写作一样只需肆意凭借灵感来实现原创，它更需要的是仔细的规划和设计。

 

增量式开发，并不是在别人的基础上开发，而是先搭建一个骨架，以支撑起未来将要开发的一个个部分。

 

将软件架构的过程比喻成建造房屋，真的很巧妙。就像建一栋房子一样，在动手之前，你必须做好精心的设计，只有这样，才不会浪费时间去修正那些本可以避免的错误。

 

Measure Twice, Cut Once: Upstream Prerequisites

俗话说：良好的开端是成功的一半。项目的成败很大程度上取决于前期的准备工作。联系到我们自己的团队项目，前期的需求分析、项目规划、任务分配等都是为了减少后期的压力与风险，使项目在未来能够尽可能平稳地进行。

 

“发现错误的时间要尽可能接近引入该错误的时间。”这句话令我很有共鸣。因为在开发过程中错误会像滚雪球一样，如果不在早期及时修复，雪球就会越滚越大。

 

在做需求分析之前，我们要从客户的角度弄清楚我们要解决的问题到底是什么。在团队项目中，老师一直在强调市场调研的重要性，鼓励我们更明确地找到用户的痛点。这就关乎需求分析的重要性。可是很少有需求是稳定不变的，“尽早把哪些是最关键的需求要素和架构要素确定下来”对我们的团队项目有一定的启发意义。也许我们最开始的调研的覆盖面并不完备，所以我们一开始先确定了我们的项目的最基本、最迫切的功能，留有余地去应对未来的需求变更。

 

“架构的先决条件”这一节我还不能完全理解。目前的理解是，架构是更细节的设计，需要去思考程序的组织结构，包括各个模块的功能、类的使用、数据库的结构与内容等。还有用户界面设计、代码安全性、容错性、健壮性等的考虑都是架构的组成部分。希望在推进团队项目的过程中，结合实践对架构理解的更深入一些。

 

 

 

 

转载于:https://www.cnblogs.com/Esther-SE/p/8721337.html