刚进公司的那会，导师出差了，就跟着一个公司号称很牛的人一起开发一个工具。那哥们整天喜欢搞一些很神奇的技巧，简简单单的一个逻辑检查工具搞什么多线程，多线程就不说了，确实是有必要的，可惜他开发出来的框架，让我们这些写具体实现的小喽啰学习了将近一个多星期也没有整明白，不但没有设计文档，代码里面一切注释欠奉，别人去问他怎么搞，总是说你去看代码就知道了哦，当时作为新人确实是比较郁闷哦，想说也不敢说哦，记得当时实在是受不了跑去向该牛人请教一下他提供的接口该怎么用的时候，听到了一句俺一生都记得住的话：程序员之间是靠代码交流的，你去看我的代码！
狗屁哦！如果我有一天是老板了，我手下的员工要是敢说出这样的话，立马叫他滚蛋哦，真是shit！一份没有提供对外接口详细实现的文档的代码就不能接受了，如果加上在关键实现的地方没有注释的代码那就更不能原谅了，最可恶的要是负责提供公共方法的程序员居然神神道道的说让别人去看什么文档注释都欠奉的代码来了解公共接口怎么用，这样的员工不是浪费大家的时间吗，每个程序员编程的风格都是不一样的，实现同一个问题的思路也是不同的，你让别人去看你的代码，那要你实现公共方法有什么用哦，还不如让别人自己都来写方法算了哦！
记得这个事情曾经和现在的老大在外面抽烟的时候聊过，他的分析我就觉得很有道理哦，公司招人来编程是要效率的，每天的程序员的工资也是不便宜的，你让别人做一些重复的不必要的工作就是在浪费公司的资源，浪费公司的资源那就降低了效率，降低了效率那就是害群之马哦! 现在编程说是技术又能有多大的门槛，找几个中人之资的人基本上是可以抵得上一个在技术上比较牛的人了，什么技术找几个人每个人专门搞这玩意的一个方面，总是能赶得上一个牛人的。那你作为牛人一个人搞定了一件事，可是这件事情只有你一个人知道怎么做，不告诉其他的同事怎么去做，大家作为一个团队，整体的效率其实是低下的。
想想也是哦，当时我们小组的七个人写实现，花了一个多星期才弄明白那哥们写的框架是怎么搞的，这个框架整明白了，还要整他提供的公共接口又花了好几天的时间。呵呵，算起来也抵得上一个人搞两个月了哦，那工具让我一个写，我现在想起来以我当时一个对业务逻辑完全不熟悉的人估计一个月也能整出来哦，这样来算减法其实是浪费了不少时间的哦。再说啦，那所谓牛人写的工具的框架也不怎么样哦，整的是多线程可是深究下去其实还是单线程的设计思想，基本上没有体现多线程的优点，什么都往内存里面搞，跑起来随随便便就4G的内存消耗，线程之间的调度也是垃圾的要死，到这哥们离职的时候工具还动不动就挂掉了哦，早听我的在后台建立一个监控线程来调度各个线程也不用通宵调bug也找不来为什么了哦，呵呵幸亏中途离开了那个小组，导师回来的真是时候哦，要不然接手了那个烂摊子不把自己搞死哦，顺便为接受烂摊子的难友默哀一下！
呵呵，废话这么多 终于引出第一篇Blog的主题，没有文档的代码就是垃圾，我觉得一个项目开始开发的时候做的第一件事就是编码风格的确定，编码风格包括很多啦，不过其中的重点就是公共接口的规范化命名，注释的写法，文档的规范，这些东西允许有不同意见，可以在小组会议上提出来，大家经过讨论，哪怕是相互争吵，只要是有道理的就应该采纳。不过，不管怎么样只要确定了编码风格一定要强制执行，如果组员写出了不符合规范的代码，一定要让其重写，这样对以后的开发是大有好处哦！还有就是设计文档一定要同步于代码哦，俺们公司虽然是过了CMMI 3可这最基本的一点都做的不好啊，不过我们项目做的还是不错的啦。