构建之法阅读笔记（三）

《构建之法》阅读笔记三

      这次阅读笔记我想记录一下我对“软件设计与实现”的学习和感受。

      通过阅读构建之法的第十一章，我对软件的设计与实现过程有了更加全面和有条理的了解。在我以前写一些程序的时候，我也会先对编程面向的对象进行分析，了解这些对象的属性和对象之间的关系，并对这些对象应该具有的活动进行相关的分析。但是也就仅限于此。对于需求分析，单元测试、每日构建以及bug的修复很少涉及到。尤其是对单元测试和每日构建，以前我对这些没有概念，当我第一次听说每日构建时还认为这并没有什么用，但是通过阅读这张的内容，并结合我们上学期三人团队开发的网页来说，每日构建真的很重要。下面就来详细的介绍一下。

      本章内容：分析和设计的方法、图形建模和分析方法、从Spec到实现、开发阶段的日常管理（包括每日构建等内容）。

      本章首先对分析和设计的方法进行介绍说明：在进行软件开发过程中，首先要对现实世界进行理解并抽象，构建出相应的对象，明确对象的属性及活动。其次要根据已知的情况，对问题进行建立数学模型，将开发过程有条理的组织起来，其开发流程和各个模块更加明确；再次我们可以使用UML的9张图来对我们的开发过程进行分析。当然我没还可以根据实际情况来建立我们自己的模型，或者自己对开发流程很明确不用建立相关流程图。根据我们建立的模型，我们要找到解决问题的相关办法。最后，我们就进行代码的开发了，要将我们上述的所有内容都通过代码来实现，这才是我们的最终目的！以上三步大概就是我们的进行软件开发的大致过程。当然其中还有很多细节和步骤学要我们一一实现。

      从Spec到实现，这一节具体讲述了一个开发人员进行开发的流程：预估开发任务的时间、写一些快速原型代码、写设计文档并复审、按照设计文档进行代码实现并解决实际开发过程中实现的问题、对写好的代码进行自我复审重构、进行单元测试修改出现的问题、发布测试版本交给测试人员进行测试，修复测试人员测试得到的bug，修改bug并嵌入代码库中。

这一小节关键是让我们了解一下具体任务的实现流程吧。

      最后重点问题来了。

      第一，关于闭门造车问题的讨论。在软件开发过程中，闭门造车对于程序员来说其实是很重要的一件事，对于一个团队来说，合作开发时交流很重要，但是也要留给程序员大量的时间进行程序代码的开发，不能经常性打断他们。对程序员的建议中我印象最深刻的是集中处理一些琐碎的小事，不要在开发过程中随时打断自己的开发时间去处理一些小事情，可以将这些小事情积攒下来进行统一的处理。对于“封闭开发”来说，其实没有太大的必要，我们要的“封闭”其实是“心理”或者“思想”上的封闭，是抽象意义上集中精力去做一件事，投入到当前这件事中去，而不是空间上的“封闭”，空间上的封闭在一定程度或某些关键时期中能获得良好的效果，但并不适合我们平时进行的日常开发工作。

      第二、关于每日构建问题。每日构建，听起来似乎并不重要，初涉开发的人员可能对此并不重视，我就是一个活生生的例子啊。但是其实他很重要。每日构建目的是确保你之前所写的所有代码和实现的功能能够在你的工程中顺利的实现，不会出现功能上的冲突。这样就在一定程度上保证了你所写的软件的健壮性，根基打牢了。就像书中所举得例子，盖房时先要搭起脚手架，要保证脚手架的牢固，因为是一栋大楼能够矗立起来的基石，同时这也是每个建筑工人所必须掌握的技能，否则就不是一个合格的工人。作为程序员的我们道理是相通的。话糙理不糙啊。

      第三、关于构建大师。我认为其实我们每一个人都应该成为构建大师。因为这是作为一个程序员的基本功。对于我们所写的所有功能，我们要能够实时构建出来，能够进行测试确保工程能够顺利的实现。就像我们以前团队开发的网站一样，我们三个人每个人都写了相关的功能，但没有进行及时的构建，在最后进行构建时出现了一大堆意想不到的错误，针对这些错误我们花了很长时间进行调试修改才最终完成。

      第四、关于小强地狱。这是一个很好的方法，当小强积累多了会对我们的工程造成很大哦的影响。因为，当小强出现时，可能就意味着我们的后续的开发（实现的新的逻辑和功能）是建立在这些小强上面的。额，底子都打错了，对上层建筑影响很大啊。

      在理论上，理论和实践是一回事，而在实践上，理论和实践是两回事。

      不审势即宽严皆误，从来治蜀要深思。

      多动手实践，多思考实现方法。