当我遇到项目需要优化时

   最近参加的项目，当我加入的时候就已经到了后期完成时。项目并不大，团队也只有四个人，基本上是三个人干活，一个监工。刚刚加入的时候没有任何文档和交流，感觉很莫名其妙，后来和一个同事聊天，说起这个项目的时候，他说，这个没有文档，是敏捷开发，当时感觉挺汗的，敏捷开发最重要的一点在于口头交流，实际上是将文档交流的形式改为了口头交流。这样的“安静”开发实在不知怎么能够叫做敏捷。

      没有文档，没有交流……

      不知道会不会有这样的程序员（我更喜欢叫软件工程师）：认为水平高的工程师可以通过自己看代码来得到想要的信息，比如开发的框架、开发的流程等。

      我的确不是水平很高的工程师，可是我可以确定这不是高效率的开发方式。

      在开发的初期，我还是本着十分信任自己的团队去看项目的源码，但是看了一天以后我的怀疑就迅速上升……以致于到进入开发以后我就本着怀疑的态度去看项目的源码，经过确认以后才敢调用……一边确认源代码的正确性，一边开发，一边改源码的日子就开始了。随着上线日期的逼近，项目显得就比较紧急了，我这样的开发速度就显得效率很慢。这时候我也开始感觉有些着急了，但是随着对源码的深入了解和对项目业务的了解，发现整个项目的开发没有什么规划，整个项目中没有什么抽象、封装、继承，很像是面向过程的开发，很多相似的功能就是用复制粘贴。

      到这个时候，我就陷入了一种犹豫之中，面对这样一个即将结束而且马上要上线的项目，对其重构肯定来不及，而且说实话，我也不一定有这个权限。但是看着如此凌乱的项目，几乎每当实现一个功能的时候都可以对其进行一些至少代码上的优化和修改。项目的进度一天比一天催的紧……我的选择是新加的代码或者功能，尽量抽象、优化一些，对于原有的地方，尽量不改或者做一些业务的修改。

      给我一个很大的影响就是：这样一个很小的项目就如此没有规划，不知道这样的项目或者比其更大的项目会怎样。曾经对于中国的软件业还抱有很多希望。现在担忧多余希望。不是因为项目开发怎样，而是因为我发现我的同事们，他们从心底并没有热爱自己的工作，只是觉得这是一个工作而已，我看不到他们对于软件的热爱、对中国软件行业的热爱。甚至当出现我发现的那些问题的时候，他们并不觉得这是问题，而是顺应项目框架，继续完成。

在每天繁忙的工作之中，我也很少有时间来吸收消化自己想到的很多想法，直到他们曾经生长出来然后在慢慢消失。再繁忙一些的时候，我就甚至连去增长自己见识的时间都没有了。

      当遇到项目需要优化时候，是一个比较纠结的问题，时间、能力，最重要的是团队是否同样有默契和团结。我们也许来不及优化重构现有的项目，但是可以从中吸取一些经验教训，在投入到下一次项目中的时候，在项目开发之处就想到要计划、规划、优化。

      项目，或者说代码，不是写出来滴，而是规划出来的。而当一个团队共同开发的时候，交流、沟通十分重要，在瀑布模型中，采用的是规范的文档，而在敏捷开发中更多的交流沟通是采用面对面的口头交流，这些交流当然也会有必要的文档形成。交流会大大提高效率，不仅仅是在开发的过程中，也在规划和调试过程中大大减少队友的时间，使得整个团队的效率提升。

      网上经常流传一句话：程序员一个最大的特点就是看不起其他人写的代码。这样其实也是一种对队友的不信任，也是由于交流不足和严重欠缺规划带来的不良后果。现在的项目要么就是不规范的瀑布模型，要么就是无效交流的“敏捷开发”，曾经有人说真正的敏捷开发并不能真正的落实到项目开发中，因为，敏捷开发中的几个重要的点，现在的公司、团队都很难达到要求：

      1、信任团队中的每个人（事实上，团队中确实很难让大家互相信任）

       2、有效的交流

       3、准确的将工作分为小的task，并按时完成

      写到这里，感觉文章并不是很合乎题目，算是想到哪里写到哪里。不过这些都是由于“当我遇到项目需要优化时”想到的东西。

      一句话总结吧：

      项目是规划出来的，团队需要有效交流，至少是必要的交流。