【读书笔记】——《代码大全》(一)
Welcome to Software Construction
之前总听到老师、师兄谈到构建、重构之类的词语,一直认为“构建”就是“编码”。读完了第一章,才对“构建”有了进一步的认识。构建活动主要关注于编码与调试,但也包含详细设计、单元测试、集成测试以及其他一些活动。
构建不是机械化的,它需要可观的创造力和判断力。一个不那么完美的软件的开发,也许缺少需求分析、架构设计与系统测试,但一定不会缺少构建活动。
Metaphors for a Richer Understanding of Software Development
这一章作者启发我们运用隐喻的方式来更好地理解软件构建的过程。我的理解是,隐喻,在这里指建模,它没有绝对的正确与错误之分,而只有贴切与不贴切之分。
对于软件构建来说,“努力创造真正的原创成果”的开发效率,往往低于专注于重用以往项目的一些设计思想、代码以及测试用例的开发效率。软件开发并不像写信或写作一样只需肆意凭借灵感来实现原创,它更需要的是仔细的规划和设计。
增量式开发,并不是在别人的基础上开发,而是先搭建一个骨架,以支撑起未来将要开发的一个个部分。
将软件架构的过程比喻成建造房屋,真的很巧妙。就像建一栋房子一样,在动手之前,你必须做好精心的设计,只有这样,才不会浪费时间去修正那些本可以避免的错误。
Measure Twice, Cut Once: Upstream Prerequisites
俗话说:良好的开端是成功的一半。项目的成败很大程度上取决于前期的准备工作。联系到我们自己的团队项目,前期的需求分析、项目规划、任务分配等都是为了减少后期的压力与风险,使项目在未来能够尽可能平稳地进行。
“发现错误的时间要尽可能接近引入该错误的时间。”这句话令我很有共鸣。因为在开发过程中错误会像滚雪球一样,如果不在早期及时修复,雪球就会越滚越大。
在做需求分析之前,我们要从客户的角度弄清楚我们要解决的问题到底是什么。在团队项目中,老师一直在强调市场调研的重要性,鼓励我们更明确地找到用户的痛点。这就关乎需求分析的重要性。可是很少有需求是稳定不变的,“尽早把哪些是最关键的需求要素和架构要素确定下来”对我们的团队项目有一定的启发意义。也许我们最开始的调研的覆盖面并不完备,所以我们一开始先确定了我们的项目的最基本、最迫切的功能,留有余地去应对未来的需求变更。
“架构的先决条件”这一节我还不能完全理解。目前的理解是,架构是更细节的设计,需要去思考程序的组织结构,包括各个模块的功能、类的使用、数据库的结构与内容等。还有用户界面设计、代码安全性、容错性、健壮性等的考虑都是架构的组成部分。希望在推进团队项目的过程中,结合实践对架构理解的更深入一些。