房子是一砖一瓦砌成的而程序是一个一个代码敲出来的，大家有没有觉得其实写程序跟建房子很相似的，但是为什么很少有房子倒塌而程序却经常崩溃？郑州软件开发！

      因为建筑师在建昂子之前会制定好详细的计划，构造一个蓝图以便建房时使用，而程序员则不会。蓝图可以保证建筑师设计的建筑按规划建成，建筑设计师和他们的客户在着手建造之前，也会通过蓝图来沟通，以理解他们将要建造成的建筑的样子。这样周密的计划才是房子的不会那么容易倒塌的原因吧。但是程序员又有几个会这样做呢，哪怕一个简单的草图都没有吧。

      其实大部分程序员不构造蓝图是因为他们觉得任何和写代码无关的都是在浪费时间，所以就不愿干，但是他却不知道没有一个好的构图怎么入手写代码呢，在没有想好就开始编码，那样只会产生糟糕的代码，我们应该思考些的代码需要实心什么功能，然后如何下手，这样在来写代码就会很顺畅了。

      蓝图让我们想清楚我们打算要建造的建筑。在写下一段代码之前，我们应该先写蓝图。软件的蓝图称为技术说明书。已经有太多的借口说撰写技术说明书只是浪费时间。比如：技术说明书毫无用处，我们不能通过它来产生代码。这就好像说建筑设计师应该不要画蓝图，因为他们最终还是需要承包商去建造房子。另外一个反对撰写技术说明书的争论也能够用蓝图的例子来反驳。

      还有一些程序员争辩说，把蓝图和技术说明书作比较是无用功，毕竟程序不是建筑物。他们认为推倒一堵墙要比改变代码难多了，所以程序的蓝图不是必须的。错!改变代码也很难，特别是如果我们不想让程序有缺陷的话。

      我最近需要修改一些不是我写的代码，从而给程序增加一个小小的功能。要完成它需要理解一个接口。我花一整天用调试器来研究该接口到底是干什么的——这种事读读技术说明书只要5分钟就能搞定。为了避免导入缺陷，我不得不弄清楚我每次修改之后的结果。因为没有技术说明书，这个事情变得更加困难。我必须要阅读上千行代码，我花了数天来琢磨怎样才能修改尽可能少的代码。最后，我花了一周，新增、修改了180行代码。这可仅仅是这个程序的一个很小的变更啊。

      修改代码只是一项大任务中小小的一块工作，大多数代码已经是我十几年之前写的了。尽管我几乎不记得这些代码是干嘛的，要修改它还是挺容易的——通过阅读我写的技术说明书，很容易就能找到我要修改的地方。尽管这些修改工作量不少，而且还影响到其它代码，我还是能很快搞定它。

      我所说的技术说明书到底是什么?通常它被认为是以正式的技术语言写就的东西。但是撰写正式的技术说明只需要偶尔为之，如果我们仅仅是盖个工具棚的话，就不需要画摩天大楼所要求的那种蓝图。对于大多数软件来说，我们不需要正式的技术说明书。然而就算是写小程序也不能不写技术说明，否则就像没做任何计划就要盖工具棚一样。

      我们做的很多事看上去都是那么的简单无用但是没有它你的很多事都做不了，就连一粒沙子也有它的用处，所以说在做事情之前一定要先思考，只有思考了才能将错误降低到最底线。