构建之法(第三版)读书笔记

我成为了一名职业程序员，但是我发现所有的算法别人都已经实现了，我只要调用就可以。似乎我们公司的软件与数据结构、算法的关系都不大。那我当初辛辛苦苦学习的数据结构和算法有用么？如何区分一个好的程序员和不好的程序员呢？ (Page 1)

体会：书中举的四则运算的例子做深了以后可能还涉及一些相对比较复杂的算法，可是在现实中接触到的系统很多是业务驱动的系统，用户量可能不会超过2000，CRUD，业务复杂流程交给成熟的工作流系统去做了，CRUD是很简单的数据库表操作，数据库操作有现成的框架，前端有现成的框架，后端有现成的框架，程序员要做的事情就是熟悉现有的框架，完成相应的业务模块的开发。典型的开发过程是：拿到一个业务需求，建模->转换成实体类->对这个实体类的CRUD->拖出一个工作流流程图->把流程涉及的表单用前端框架做好->调用封装好的工作流的方法实现业务流程操作。在整个过程中，似乎用不到任何复杂一些的算法和数据结构（最多可能会考虑一下实体类之间一对多之间的关系），但是仍旧有些程序员做的很好，bug非常少，功能也很稳定，有些bug很多，这样可以区分去好的程序员和不好的程序员么？

有人说一个人就可以快速成长为一名全栈工程师，这让我想起街头卖艺的单人乐队(One-man-band), 他们什么都会一些，可以很快地演奏一些曲子。 (Page 57)

体会：我大概听过两类企业，有一类是每个工程师就是一个螺丝钉，在自己的某个技术上发挥极致的能力，有一类是每个工程师类似一个"大杂烩"（这个比喻不知道恰当与否，就是表示工程师需要处理项目中各类技术方面的问题），前一类公司培养出来的工程师可能是强化自己现有的技术能力，而另外一类公司的工程师，就是在拓宽自己的技术能力，第二类公司培养的人员，似乎就有点像作者所说的"演奏家满场奔跑，操作各种乐器"，可是我认为这种方式并非不好，因为现在很多开发模式是前后端工程师分开开发，但是前后端工程师开发的速度可能有差别，所以，最大化时间利用率是前端开发完毕以后，可以支援后端开发，反之亦然，这样就可以让项目进度整体加快，而这就需要"演奏家满场奔跑，操作各种乐器"。其次，作者在第17章17.3.4节中介绍 团队的 创造阶段（Performing）的时候说到一点：团队成员相互支持，相互依赖，角色和职责能够根据项目的要求自然转换，没有人为此担心或发牢骚。这里说的自然转换，是不是就是 "演奏家满场奔跑，操作各种乐器"？最后，是不是精通某个技术就是要放弃其他技术的学习，这两者要怎么平衡呢？比如一个工程师，前后端都可以上手做项目，他到底应该怎么去精通某个方面呢，完全放弃前端专心做后端？还是完全放弃后端做前端？

技术产品的发展周期（萌芽->成长->成熟->衰退->结束） (Page 367)

体会：这里的技术产品包括编程语言么？很多语言虽然语法不一样，但是都能实现同样的功能，可是还是会有火/不火的区别，这样的话，如何准确判断一门编程语言的发展阶段，从而在学习的过程中不会浪费时间到最后学了一门被淘汰的语言？此外，我在学习过程中，总会存在一种不安全感，总觉得学这个可能会淘汰，然后去追逐一些新出的技术，或者热门的技术，如何克服这样的不安全感？

如何给一个系统的所有源文件都打上标签，这样别人可以同步所有有这个标签的文件版本？(Page 254)

我最早接触的打基线（针对项目源码）的方式，是将每次发布的版本源码放到一个文件夹下面，比如这次发布的是1.1版本，就在版本管理库（用的是SVN）里面的tag目录下，建立一个名字V1.1的文件夹，然后把V1.1版本的源码都放进去。这样做的方式维护起来比较麻烦，V1.1发布以后，要改一些临时修复的紧急bug，还要在tag下的V1.1文件夹中建立一个patch文件夹来放修改bug涉及的源码文件，非常麻烦。

后续想了一个比较好的方式，就是在发布的时候，在版本管理库的根目录下做一次空提交，提交的备注就是@release+版本号，如：@releaseV1.1，表示这是V1.1版本发布的时候的版本，这样的话，看提交历史就可以很清楚的找到LKG版本，而且也容易回滚。

看到这里想到一个场景，就是很多系统在开发的时候，配置文件里面会记录数据库连接，在开发的时候，用的是测试库的数据库连接，在发布的时候，要修改成正式数据库的连接，最早的时候，我们会区分两套源码，一套源码是连测试库的，用于日常开发，发布以后，把连接生产数据库的源码打到基线区，后续想到一种更优化的方式（针对Maven项目），会存两个配置文件：

prod.properties --> 生产配置

dev.properties --> 测试配置

然后在打包的过程中，通过命令行参数来控制采用那个配置文件，比如默认的打包命令是：

mvn clean package

这样打包就读取的是dev.properties中的内容

加上一个参数 -Pprod

mvn clean package -Pprod

这样打包读取的就是prod.properties的配置文件

运行/编译的时候类似，都是通过命令行参数来控制，这样的话，就只需要维护一套源码即可。

 

在看到初始效果和了解实现细节后，小飞开始写设计文档，写好之后，他可以请同事一起来复审设计文档。(Page 240)

 

我了解的很多用敏捷开发的公司的做法是：在看到初始效果和了解实现细节后，小飞开始写......代码，

 

因为情况只有如下几种：

 

1. 需求很简单，不需要设计文档，一次性就可以搞定的。如：实现抓取某个新闻列表和详情的数据接口。这种情况，写设计文档似乎有点耽误时间。或者。。。先开发，后面可能公司这边需要再补充设计文档。

 

2. 需求看上去好像很简单，但是实际写代码并测试以后，发现当初的技术方案无法达到要求，比如：在抓取某个人待办数据详情的时候，我们开始是用抓取页面元素的方法，后来发现渲染页面速度太慢，导致显示数据详情常常会超时，后来就优化成直接发送ajax请求而不渲染页面的方式。像这样需要不断尝试并优化的开发方式，写设计文档这件事更加有点马后炮的意味，因为毕竟实实在在的Coding和效能测试才能发现和找到问题所在并修正。

 

转载于:https://www.cnblogs.com/greyzeng/p/7143764.html