构建之法阅读笔记01

刚开始读《构建之法》这本书时，书上所提到的很多问题都是我们平常在写代码时候会犯的一些小的错误，就我个人而言，在我还没读《构建之法》这本书之前，我还不知道我平常在写代码中犯了这么多的错误，虽然这些错误都是一些小错误，并不影响代码的执行，但是看了《构建之法》这本书之后，才忽然明白原来一些小错误也会造成大的问题。、

过去，我在编写程序的时候没有充分的考虑用户体验。软件的用户界面的一些原则有：尽快提供可感触的反馈；系统界面符合用户的现实惯例；用户有控制权；一致性和标准化；适合各种类型的用户；帮助用户识别、诊断并修复错误；有必要的提示和帮助文档等。如果我们在编写程序时不考虑用户体验，那么用户可能会不愿意使用我们编写出来的程序。在以后，我们在编写程序时可以更加重视用户的体验。

很多主导一款嵌入式设备软件开发项目的负责人，其本人并不是一个优秀的程序员，无法真正把需求转换成相应的软件模型，无法很好地进行抽象。 在一个项目的开发过程中，需求分析，把需求抽象成相应的软件模型，思考使用哪种设计模式，框架代码如何拥抱变化。软件工程师不能阻止需求的改变，只能最大限度地拥抱它。软件应做到在只修改配置文件的基础上自由地扩展和裁剪功能。这些是需要在团队动手之前想好的，否则后期会很难受，尤其在项目进度压力大的情况下，一个需求的扩展可能就搞得整个团队紧张兮兮。 三．在战争中学习战争 我最近在主导一个功率计的软件开发，时间非常紧。有点像书中关于“团队”模式中所提到的“主治医师模式”，我通过与非软件的同事反复确认需求说明书中的条款，避免因表述不清而出现歧义，并转换成软件设计文档，文档中包括对需求的解读，如何用软件抽象该需求，软件模型是怎样的，框架设计细节。最终，使用C语言写了个MVC模型（C语言也是面向对象的，好不好），采用“分而治之”的思路，并把繁琐的逻辑拆分成独立的“插件”，逐个击破，通过配置文件决定是否调用某个“插件”的构造函数，实现“插件”的可插拔。 软件工程中的团队模式与足球中的战术体系，在本质上是一样的，谁动不动就强调他的个人能力，那么他一定不懂得配合队友，这是意识的问题。为了不断提高自己的水平，突破自身的瓶颈，我采用“做中学”的态度，结合《构建之法》中的原理，指导自己的开发工作，效率提升得很快。《构建之法》之于现在的我，就像《论持久战》之于抗战初期的中共，具有绝对的指导意义。