- 实际项目开发中，对于类和字段的命名，基本会达成一个共识，就是认为它们非常重要，主观上认为它非常重要，在行动上也要实践起来，不然，也仅仅停留在纸面上，不会创造出应有的价值。在过去的项目中，由于经历过不同的开发成员，在开始的时候，没有形成很好的命名规范，导致有很多不统一的地方。
- 有几处的印象比较深，在这里记录列举一下，一个是关于类的命名，对于不同的资源，对应不同的加入成员，成员的这个单词在英文中也对应着几个同义词，选择一个就能表明含义，后面的开发者也都能看懂。在项目中，不同的资源有很多的命名，它们的命名分别如下：
- 社区成员 Accession
- 讲座成员 Lecture::Attendee
- 课程成员 CourseUser
- 活动成员 Event::Member
- 群组成员 AccessionChatroom
- 训练营成员 Camp::Member
- 另一个是对字段的命名，有一个很小的点印象特别深，就是对于名称的命名，不同的表中分别有 title 和 name，导致需要统一使用的时候，需要在相应的表中都要添加 alias，还有其他的字段命名没有进行统一，这里只是举例说明一下。
- 项目的常用的单词的也就几百个，对于不同的业务单元有相应的专业名词，但数量也不会太多，一般也都能明白命名字段的表义。但如果项目中，对于同一个表义，有不同的命名，也不是不能明白，只是对于后期开发和维护，会造成比较高的认知成本，而且也容易出现问题，对于可以通用的功能模块，由于类的命名不统一，需要进行额外处理，出现 bug 的概率就会增高很多。
- 那如何才能形成统一的命名规范，并能很好的执行？下面是自己的一些思考和实践
- 在观念上要接受统一命名很重要，如果是团队的 leader，要反复地强调，并且以身作则
- 观念上接受，还要有相应的机制，在实际工作中践行，要有项目统一命名文档，团队成员要达成共识并遵守
- 统一命名要在事前进行，放在技术评审阶段，不能放在 Code Review
- 对于不遵守的成员，还要相应的“惩罚”机制，这里的惩罚当然不是扣钱，对于初中级的工程师，可以是安排一次技术分享，对于高级工程师的话，也可以增加几次 Code Review 的任务，并且在每次 CR 的时候至少要夸一次 coder，就是找到写的好的地方，写上这个地方写的太好了，也可以是其他形式，但就是不能以扣钱的方式
- 项目统一命名文档要进行定期更新
