多想是少走弯路的捷径

   在做项目的过程中，发现我们很多时候不太喜欢思考。在解决一个问题的时候，很多人都是想到一个方案就立马实施。感觉效率很高，其实不然。

   我就遇到多很多效率高的，但做的东西质量确不高。如果最终的结果来衡量的话，其实效率反而不高。

   有一次开发中式样要求是：根据项目的内部名不同，这个项目的值的取得SQL的方法也不同。但这些项目中有30多个项目的取得方法是一样的。结果一个哥们很快就写完了，代码一大堆，生产率狂高。

   但仔细看过后发现30几个项目的取得方法都拷贝粘贴的，ifelse一大堆。这个就是典型的想到就做的结果。实在上同样的30几个项目用一个正则表达式判断就可以。最后还是改成成了用正则表达式去判断。前面做的工作就白做了。这样高生产率我称之为伪生产率。

   还有一次，邮件模板中的置换文字的置换方法问题。例如置换文字中有$item_1 、$item_2 、$item_11。如果按照这个顺序置换的话，$item_11这个置换位子首先被$item_1替换成XXX1，而没有替换成$item_11的东西。那该怎么解决这个问题呢？

   结果有个家伙很快就改好了，方式自己写了一个排序方法，先置换位数多的置换文字。$item_11 、$item_2 、$item_1。这样做在逻辑上是没有问题的。不过问题是自己写了一堆代码，增加了bug的可能性。

    那有没有其他方法呢？其实再多花一点时间考虑的话，就能够想到其他方法。比如在从数据库查询置换文字的时候，就根据置换文字位置降序取得。这样的话，代码就不用修改了，只改了SQL。这样修改范围小了，效率反而更高。说不定还有其他办法呢?

   还有很多时候，有现存的方法不先去找一下，自己想要什么就自己就写什么，造成同一个工程中重复方法一大堆。自己写的弊端就是bug多，重用性不好，最终效率不高。

   还有人只见树木不见森林，只顾自己的功能实现，而不去考虑是不是会影响到其他功能。

 

   很多时候我们都懒的去思考。想到一种方法就不想去想其他的了。实际上任何问题都有很多解决方法，至少也得列举出2种方案。从中选一种相对好的方案。多思考，多想能减少做无用功。能切切实实提高效率，提高客户满意度。

   中学语文老师经常教导我们写作文的时候要先构思，而不是立马就写，因为构思虽然花掉一部分时间，但由于有整体的思路，作文质量反而很高。其实做项目，解决问题和写作文是一样的，在有限的时间内想出一些方案，然后择优对应。

   多想是少走弯路的捷径。