本文共 1228 字，大约阅读时间需要 4 分钟。

我们项目组一直在维护一个老项目，虽然大部分时间都在做项目维护，但偶尔也会有新需求需要开发。项目库使用的是2.0版本，很久没有进行更新了。这个需求的周期大约是一个月。需求初期我们主要讨论逻辑设计和数据库结构，虽然在编码风格和模块协同调用方面没有进行过深入的讨论。直到需求确认并完成数据库设计后，大家才开始共同着手开发。项目采用传统的三层架构，Model层和BLL层均为aspx开发，项目规模较大，每次编译需要大约4分钟。

在项目管理方面，我们使用的是VSS2005来管理代码，数据库则采用SQL2008，开发工具是VS2008。项目中的一些习惯性做法包括：数据库字段统一使用小写，类名首字母也采用小写形式，未使用驼峰命名法。我们自行开发了一个ORM类库，虽然使用起来不太方便，但有一点比较好用，就是可以将表单字段封装为实体类。

在开发这个需求时，我在自己的模块开发过程中始终遵循项目的风格和习惯，保持类名、属性、变量的一致性。然而，项目组中一位资深员工在看到我的代码后，询问我为何类名首字母没有大写，命名也不规范。我回答说是遵循项目风格一致。之后，我继续开发，随后写了一个列表查询。在查询部分，我从页面封装了查询条件，传递到后台，然后使用拼接查询条件的方式在数据库中执行查询，代码量大约20行左右。此时，老员工再次提问我写这些代码的目的，以及查询方式是否合理。我表示由于经验不足，确实存在不足之处，同事和领导提出的建议我们会认真考虑优化。但在这次项目中，由于老员工的态度，我感到被指责，仿佛我的代码对项目造成了破坏。我试图解释自己的想法，但老员工态度冷漠，要求我立即修改，感到无语。作为开发人员，面对代码的改进和优化，我们应该更加成熟地处理这些事情。难道在需求开发前不提前沟通规范问题，等到一半阶段才提出，这不是对团队沟通的负责任态度吗？

在编码过程中，我使用了公司自行开发的ORM工具，虽然在CURD操作上有一定方便性，但仍需手动编写SQL语句，尤其是删除操作时，通常不使用ORM。老员工在查看代码时指出删除方法中缺少直接使用数据库操作，这让我感到困惑。我表示在ORM支持的地方会优先使用ORM，但手动编写SQL并不是为了弄得见不得人。这种交流方式让我感到无奈。

我认为，在一个项目组中大家共同为项目付出，目标都是尽量做好项目，实现共赢。这么大的项目用了几年还未完成，出现问题并不是什么大不了的事情。但重要的是要坦诚面对问题，积极沟通，而不是拐弯抹角地批评。我们都有自己的原则和底线，应该能够理性处理。

规范化对于每个项目组都至关重要，尤其是在老项目维护和新需求开发中，规范化能够帮助我们更高效地开发和维护项目。为了项目的长远发展，我认为在需求开发前，应该对编码风格和规范进行培训，或者在项目开始前将代码风格和规范公开，这样大家才能在开发过程中遵循统一的标准。同时，让同事们了解彼此编写的代码质量，通过学习和交流共同提升编码水平。

经验尚浅，恳请各位指导。

转载地址：http://ysbaz.baihongyu.com/