我们项目组做的项目是一个老项目，大部分时间都在维护，少部分时间在做新需求。项目类库是用2.0的，一直没有更新。

          这个需求的周期是一个月， 需求初期都在讨论逻辑和数据库的设计， 没有讨论编码风格和一起共同遵守，共同调用模块的问题，需求确认后，数据库设计好后，大家都都着手工作了， 项目采用传统三层开发，除了Model, BLL就是aspx，项目也比较大， 每次编译一次我需要4分钟左右。  项目管理源代码采用VSS2005管理，数据库用SQL2008， IDE用VS2008，  项目中沿用的习惯： 数据库字段统一小写， 类名首字母也是小写， 也没有使用驼峰命名法，ORM用的是公司自己的类库，全自动化的，使用起来不是很好用，有一点比较好用， 就是可以封装表单字段为实体类。

          开始开发这个需求了，我在做自己的模块过程中，沿用项目项目的风格，类名，属性，变量，跟项目保持一致。这一部分东西就完了，此时项目组一位老员工就问我，为什么类名首字母不大写，命名也不规范，我回答，跟项目保持一致。 而后我继续开发，随后写了一个列表的查询，查询时我从页面封装查询条件，查询到后台，在类库里用拼接查询条件，然后查询视图， 大概20行左右吧， 随后老同事又问我， 你写的这些行代码想干啥呢，底层都跑那去了，还Select呢。 首先我表示程序开发过程中，由于经验不足，确实有不足的地方，同事，领导，老员工提出来，那么我们就一定想办法去优化他，但是在这次共事过程中，从那位老员工的口气中，让我感觉到好像我是在给项目搞破坏，我想表示自己的想法，说了两句，老同事表示别跟他说话了，赶紧改就完了，让我感到无语， 既然有人负责这次的需求开发， 开发时又有规范要遵守，那么为什么不提前开会说明呢，偏等开发一半了才提出来， 提出来后又是这种口气， 作为一个coder，一些最起码的职业道德和职业操守我们还是懂的吧，面对自己写的代码，我们每天都会不断的思考，那些地方还能写的再好，那些变量是多余的，那些地方逻辑处理不是很好，又或者是自己写的代码别的同事能看懂不等等。  沟通有这么困难吗？ 就是个民工整天在工地上搬砖垒墙也得有点说话的权利吧,我们用的自己的ORM，常见的CURD使用起来也非常方便，当然有些地方还是需要手动写sql，而且有的查询必须配置Model，在Model里利用属性操作，有几个类区别很小，我用了继承，但是在配置orm时又出现了问题，无法使用，我又不得不把代码在copy,paste一下， 随后还有几个删除方法我手动写的sql，原因很简单，删除时没有使用主键删除，故老同事查看代码说这删除怎么不用底层啊，我又表示，能用orm的地方我一定用，更何况手动写个sql总不至于弄的见不得人吧。

          我想说大家有缘在一个项目组里共事，目的都是为了把项目做到极致，实现共赢，这么大的项目，做了几年了也没做完，出问题应该不是什么大事吧，有问题直接提出来，咱们想办法优化它，而不是拐弯抹角的说这个扯那个，大家都有自己的原则， 也有自己的底线。 

         规范化对于每个项目组都很重要，项目管理，敏捷开发更是重要，当然我们对于敏捷还有很长的路要走，在这次的开发中，我很用心，  既然对规范化对我们很重要，又老项目维护，那么我觉的有必要在心需求开发前培训编码风格和一些遵循的地方，也或者为了省时间，拿出来自己写的东西，让大家看一看，学习下好的风格，好的习惯，同时大家也可以看看到底同事写的代码是不是优质产品呢， 我想这些事情，对于大家来说都是学习的过程吧。

       经验尚浅，还请大家指导。

     

 

      编程的路还远，继续努力！