之所以阅读这本书,是想在阅读风格较为轻松的《程序员修炼之道》之后阅读一本更细致、更严肃的“进阶”读物。
* 第一部分 打好基础
第一章 欢迎进入软件构建的世界
> 软件构建的定义:包括编码与调试、单元测试、规划构建、集成等,没有给出一个明确的定义。
> 软件构建的重要性:软件构建是编写大型项目最重要的、不可或缺的部分。
第二章 用隐喻来更充分地理解软件开发
> 对软件开发地隐喻不是明确的标准,而是微妙的启发,所以不要被隐喻限制而远离“不符合”隐喻的方法。可以将不同的隐喻结合启发自己构建代码。
> 一个好的隐喻是将代码构建比作珍珠的生长(accretion),从外在吸收材料并慢慢成长的过程。代码的构建应该是增量式的,从一个基础的框架开始每次增加一点点。假如一开始的代码没有完整的功能,也应该用dummy class搭起一个基本的框架,然后逐一替换成细致可用的代码。这个思想与《程序员修炼之道》中的“曳光弹”思想一致。
> 另一个好的隐喻是将代码构建比作建筑。
首先,越大的架构修正错误的消耗越大,所以需要从一开始就仔细地设计框架。然而对代码的设计不应该过于细致,应该始终保持解耦,细节随时可以在后期更换。
另外,代码构建可以引用第三方库,也可以根据需要自己编写库。
最后,不同的项目需求所需要采取的构建方式可以是截然不同的。
第三章 三思而后行:前期准备
> 根据数据,引入错误到发现错误的时间越长,修正错误的消费越大。进行充分的前期准备可以将需求、设计上的错误扼杀于萌芽。
> 软件大致分三种:商业系统、使命攸关的系统、使命攸关的嵌入式系统。
我们的项目属于商业系统,推荐采用敏捷的、增量式的开发,计划、管理可以非正式,需求可以非形式化,设计可以和编码同时进行,测试可以较少。
我有一点异议:尽管是商业开发,也应该有较正式的计划管理、形式化的需求与经常的测试,只是由于商业开发解决错误的消耗较少,所以这些不用过分冗余。
> 迭代式开发 vs. 序列式开发:
迭代式开发中,需求发掘、构建、设计等工作较为重合,伴随整个编码过程,检错修正的成本在过程中逐次交付。序列式开发中,各工作较为独立,每一个工作依赖于前一轮工作。
对两种开发方式,前期准备均可以大大降低成本。
对于需求稳定、设计理解透彻、开发者熟悉相关领域、项目风险小、需要长期可预测性、后期更改代码消耗很大的项目,推荐采用序列式开发。反之,推荐迭代式开发。
> 问题定义:需要用自然语言、从用户的角度定义,并不涉及具体的解决方式。
> 需求:明确的需求可以避免程序员错误地理解需求、避免开发者之间的争论。
需求不是稳定的。
如何处理需求的变更:经常评估需求的质量;确保每一个人都知道变更需求的代价以免心血来潮;在新需求过多的情况下建立变更控制程序;使用能适应变更的开发方法。
> 架构:本书没有将过多笔墨花在架构上,但私以为架构很重要。
架构的典型组成:
程序组织:各构造块的分工与合作;主要的类;数据设计;业务规则;UI;资源管理;安全性;性能;可伸缩性;互用性;国际化/本地化;IO;错误处理,及相关约定;容错性;架构可行性;是否需要冗余;使用第三方库还是自己构建,以及为何这么做;是否复用;应对变更的策略;总体质量。
第四章 关键的“构建”决策
> 选择编程语言:熟悉的语言比不熟悉的语言生产力高;高级语言(java, c++, python, perl…)比低级语言生产力高。
> 编程约定,如变量命名、类命名、函数命名、格式、文档等。
> 在技术浪潮中的位置:浪潮后期可以稳定持续地编写新功能,而浪潮前期需要耗费更多时间应对不完善的技术。
> Working in a language vs. working into a language
Working in a language意味着对一种语言不够了解,被语言本身的逻辑限制;working into a language意味着在了解已有语言的基础上,由思想确定使用的语言及使用语言的方式。
> 选择主要的构建方法,如编码约定、团队工作方式、质量保证措施、各种工具等。
标签:需求,架构,读书笔记,隐喻,代码,开发,构建,大全 From: https://www.cnblogs.com/zbw-m/p/16875048.html