最近在啃一部大部头 《代码大全》，这本书是我最近迫切得想看的一本书。这一年在新入职的公司负责移动端方向的前端开发，从无到有的搭建出一个工程，并在上面针对各种需求，进行业务代码的开发。而随着项目的逐渐庞大，需求的复杂度不一，在对软件构建时，功力不够的缺点就慢慢体会出来。比如在接到一个大需求的时候，能够完成正常的符合业务要求的代码，但是在这个需求完成之后，回头去审视自己在这个模块的文件结构组织、封装复用和是否使用某种合适的设计模式使得代码干净整洁好维护这些方面的成绩，往往是不够优秀的。

这些的缺点，也是在同事之间相互 review 代码的过程中逐渐自我意识到的，在这个背景下，我迫切的想阅读代码大全这本书，希望能通过这本书中的经验，提高自己在构建软件时的各方面意识。

本书第一章从软件构建的是什么这一角度切入，带我们进入软件开发的大门。

书中大量引用构建一词，如果你不是很理解，你可以把这个词理解成编码，他们是一样的意思。

为什么我们要认真的对待编码阶段的工作？因为每个项目都有着自己独特的类型，对于不同类型的项目，我们的开发方式也就不同，例如我们如果一个软件非常的小并且需求单一，那么我们可能就不需要需求分析以及测试这个阶段，直接开发它就可以了。而如果一个项目非常的庞大，并且需求复杂，那么做好需求分析工作以及编码完成后的测试工作就非常的重要。而在这个过程中，不论项目大小，有一项工作是必须要做的，那就是程序员必须针对这个项目，编写代码。并且有数据来支撑，证明编码在整个项目过程中占据了大量的时间，因为我们没有理由不去做好这件事情。

软件构建是软件开发的核心活动，构建活动是每个项目中唯一一项必不可少的工作。

书中列举出软件构建活动中，包括以下几个部分：详细设计、编码、调试、集成、开发者测试（包括单元测试和集成测试）。结合自己日常的开发工作，来分析这几个软件构建中的活动，自己完成的如何，我有以下几个地方做的并不好。

1、持续集成，当前项目中，前端会通过脚本自动打包，这是持续集成的一种体现，但是我自己并没有对 CI 做过特定的研究，包括该如何通过 git hook 触发 jekins 的 job，完成自动单元测试、打包等等一系列流程，这是我应该去尝试一遍的事情，去搞清楚这个流程中，有什么部署难点，并且把这些经验，应用到以后搭建的项目中，能够在构建的初始阶段就开始主动的去考虑持续集成这件事。

2、单元测试在目前的项目中不被重视，尤其是对于前端项目，如何对组件进行单元测试，如何对业务逻辑进行单元测试，这些都是需要考虑的问题，但是现在没有，所以之后我会在这方面下功夫，首先寻找到前端单元测试的最佳解决方案，其次是将这些解决方案应用进日常的编码中，最好能够将单元测试跟代码提交、持续集成串联在一起，形成项目中的构建流程。

说了这么多，其实核心就是想表达一件事，构建活动的质量对于软件的质量有着实质性的影响。你写的代码，你设计的架构能够轻而易举的影响整个项目的质量，尤其是当这些代码需要他人维护、修改环境，设计出结构良好的代码，更能方便团队伙伴来维护、阅读、debug。

而对于构建活动的理解程度，也决定了一个程序员的优秀程度。能够写出高质量代码的程序员，才是一个好的程序员。第一章的结尾的这一句话，我无条件的同意。