项目是先做规划还是先做功能？

首先做下简单描述，本人从事技术开发也就两三年的功夫，介于经验基础开发过程并没有很成熟的解决方案，公司也没有技术大佬，公司是小型技术团队（10人都不到），所以平时都是自己淌浑水。

上面的描述是背景，正是由于这样的背景，才有了我下面的亲身体会。好了，开始正题。

最近公司的有个半成品的项目，所以打算在开发的过程中，进行重构一下，总体算是重新做吧，大家理解为一个新的项目就好。

1、拿到项目的第一步当然是：规划。

刚开始雄心壮志的苦思规划方案。前端怎么规划，后台怎么规划，controller怎么放，service怎么依赖。并且考虑了以后项目变成分布式该怎么搞，经过九九八十一天，终于，结构规划好了。

2、规划好了，当然是开发功能喽。

每个项目成员，分配到相应的任务，开始做吧。按照规划好的结构，把相应的东西放到相应的位置（完美）。然而鬼知道发生了什么，项目中的代码依旧是乱，相当乱。举个最简单的例子：获取产品信息，跟我们数据库打交道的dao层，本来一个方法就搞定了，但是我们三个项目成员竟然写了三个类似的方法，等等类似的问题，就这样，对于强迫症的我看的着实难受，但是没办法，项目得上线啊，管不了那么多了，先做功能吧。

3、上线。

最后按照步骤2的习惯，我们的项目上线了。

出现bug了（bug很正常），开始改，同事一个核心代码，改啊改，我的印象中大改不下5次，小改更多，最后还是总有问题。

天灾来了，这个同事有事请假了，有幸（呵呵）去改别人的代码了，我的天呐，我看到了什么，一个整的业务逻辑看到头皮发麻，完全没看懂什么意思，方法调用之前，一堆参数用的map传递，心里一惊，硬着头皮改啊改，最后还是没有结果，跟技术负责人商量之后，决定重新写一遍。因为该业务比较关键，但是我还是一个属于一个比较心细和负责的性格，又有前一个同事的例子，所以，开始没有急于写代码，画了几张详细的流程图，再次跟技术负责人确定之后，开始重写，加上调试经过一周的时间，这个功能算是搞定了。

bug越改越少，现在基本正常稳定了。

4、优化。

针对客户的反馈，以及我们客服人员的反馈，开始针对功能进行优化和完善。

5、扩展。

我们的业务要扩展，但是现在的项目太乱了，又跟技术负责人商量一下，确定将我们要扩展的业务重新梳理一遍，好好规划一番，前期的经验告诉我，这次规划的要更细致了，需要建几个接口，几个抽象类，几个实现类，统一弄好之后，准备大干一场了。

我们技术负责人看到我的规划之后。跟我说，你这规划的太细致了，影响进度，按我们现在技术团队，没有提高效率反而会影响维护成本，技术这东西，不要去套那些生硬的结构，以解决问题为基础。我泄气了，停止了计划。关于这个问题，我自己思考了整整一天，觉得我的规划确实太细了，这样的确会影响进度，好的东西并不切合实际、不实用是没有任何价值的。

以上就是本次项目的亲身经历和过程中的一些问题感受。那么，我们的问题来了，项目开发之前（或者说功能开发前）要不要规划？

首先规划一词是没有标准的。规划一辈子成为什么样的人，规划一年的关键目标，规划一个月的关键目标，规划一天具体的计划。我想这些都叫规划，但是每次规划的内容不一样，你实际做的内容也不一样，负责程度更不一样。

那么我来说说我对项目规划的理解。项目需不需要规划取决于实际情况，哪些情况（简单举几个例子）：

a)、BAT这样的公司（大型技术团队）：技术人员那么多，如果不规划，岂不是乱套了，并且我认为要进行详细的规划。

b)、中型公司（中型技术团队）：技术人员相对较多，也需要进行规划，但是可以不用到那么那么细微，要看公司实际情况

c)、小型公司（小型技术团队）：向我们这样的公司，技术人员不到10人，个人认为，规划一下大概项目任务就可以了，所有东西，不管通过什么方式，先做出来，如果真的有需要，后期再做（或者说等真的有这样的需求的时候再做），完全没有必要前期浪费大量时间规划的太细致

我相信有很多人都是屈居于C类型这样的公司的，然而每天都很烦在改东西上，但是没有办法，还是切合现实吧。如果你的实力足够，并且厌烦了改东西这样的流程，请自行离职，找一个合适的公司；如果你的实力不够，又厌烦了这种流程，那么请你静下心来让自己成长，待有能力时，逃离这样的环境。

所以加油吧，少年，努力奋斗。过自己想过的生活，做自己想做的事。