【trueman共识提案】几个提效百分之三十开发效率的小经验

几个提效百分之三十开发效率及提升职业素养的经验之谈

以下开发经验适用于元数据和人工智能时代来临之前百分之99的系统。首先要遵守行业高度认可的编码规范是必须的，比如阿里巴巴代码规范。遵守这些其实很简单，我们常用的IDE，例如idea,vscode都可以实时提示代码存在的问题，甚至常见的问题IDE可以使用AI代码插件自动修复。

以下提及的是我从业近10年总结出的一些经验，这些经验有助于帮助开发团队保持统一的代码风格，提高开发效率。

1、唯一属性字段命名规则

在持久化对象字段设计中，字段的含义在各个地方保持唯一性，id除外，后面会讲ID的独特性和高安规格系统对id的处理办法。

比如栏目表（channel）名称和文章表（document）的名称，我们可以命名为channelName和documentName，而不是name，name无法区分是什么名称。考虑到“状态”通常包含较多业务逻辑，我们也不会用status作为字段，而是指明具体含义，比如channelPublishStatus,表示栏目发布状态。

如果表名称太长，字段属性我们可以使用简称，例如栏目配置表（channel_config）的配置类型（type）我们可以使用ccType,这样IDE工具就不会报错误单词提示。

好处

1. 考虑到冗余在高并发、分布式大型系统中的必要性，我们可以使用一行代码完成属性的设置BeanUtil.copyProperties(source,target),或者使用面向切面+反射技术实现0侵入自动冗余功能，这样开发者就不需要耗费精力在冗余处理（不冗余代码耦合代码写逻辑，冗余就得set get 值）上面。
2. 程序员可以花费更少的时间用在理解和比较字段含义上面，开发这些年我发现除了增删改查，百分之30的时间是用在定义和解析上，而这其中还要拿出大部分时间用来理清含义和传值，所谓难以撼动的”屎山“代码，一定是从混乱的定义开始的。

2、唯一标识之ID限用规则

ID是数据体的唯一标识，不随业务数据变化的ID，ID的生成可不考虑人的易读性。仅用于对该数据体的增删改查操作，不可在业务代码中写死，尽量避免用来处理复杂业务。

好处

1. 在高安全等级的系统中，ID会根据会话特征（比如设备编码，不同用户）对ID的值进行某种偏移运算，真实存储的数据ID通常不会反馈给前端。
2. 区别于code，用于复杂关系和业务。尽量避免ID在系统中任何地方写死，因为不好识别业务逻辑。如果非要写死可以使用code。

3、唯一标识之CODE（编码）限用规则

code是人类易于识别，根据某种业务运算得出或者人们输入的的唯一标识，常用于与其他数据体关联及业务处理。如果用在业务代码中，我们应该将其放在常量表中。用于非父子关系的关联键值。

比如【栏目表】和【文档表】他们之间有关系但不是父子关系，此时我们在文档表中定义channelCode字段，来标识，这篇文章呈现在此栏目下。

命名方式：其通常是由前缀加分类加序号等元素组成的，比如大学的班级代码我们可以定义为：前缀+学年+系部代码+专业代码+序号，看到这个代码我们可以理解为某某学年什么系什么专业几几班。

好处

1、对系统设计中的业务耦合情况有一个清晰的认识，更容易整理出系统接口逻辑实现情况的甘特图，以便对开发进度有一个量化指标。

2、编码是不易改变且具有强业务关联的唯一标识，可以避免我们增加重复数据，当编码变更时我们必然需要考虑关联实体的编码的更新及是否要变更某些业务，比如大学的班级是由系部代码专业代码需要组成的额，当专业代码变更时是不是意味着这个班级的学生变更了专业。所以遵守这个规则可以“强迫”我们考虑业务逻辑是否有遗漏，系统是否完整闭环，增强了我们业务逻辑的严谨性。

4、字典数据限用规则

1、用作字典的数据表现为常量、拥有唯一编码，不能随意变更。

2、敏感信息不存于字典。

好处

1. 通常用户随意输入和变更的数据不容易做国际化，常量化的数据容易应用于国际化，比如区划数据、语言、性别、国籍、状态等。
2. 存储成字典的数据分类通常是业务关联性强的一个大类，常量化易于编码。比如订单的签收状态，我们通常会根据几种类型编写业务逻辑。
3. 字典模块在前后端中非常通用。有些用户量大的系统、字典模块都是单独部署的，走前端实时翻译的路线，如果储存了敏感信息，就需要考虑数据访问权限这些，导致这个系统功能复杂，冗余、准增加开发成本。

5、控制台输出异常限用规则

控制台输出任何类型的异常都不应该被忽略，被常态化，无论时运行时还是非运行时的异常我们都应该处理，下面是处理方法的经验之谈。

1、由用户正常触发的异常我们统一处理成message给用户提示，不要在控制台打印。

2、非正常的输入触发的异常通常是前端的交互逻辑异常或者系统入侵，我们可以打印或者记录到预警系统，比如设计上提现金额不能大于余额，如果发生了就需要我们检查是否是交互BUG还是发生了入侵。

3、如果非得需要参数才能定位异常可以记录到业务日志、或者短暂的调低日志级别，如果经过了一个测试的度【试运行、小规模测试等】，控制台仍然输出异常，就需要认证研讨程序是否存在逻辑漏洞或者被黑客入侵或者硬件资源缺乏。

好处

业务日志和控制台日志分而治之，控制台是我们发现程序漏洞、入侵、业务之外异常的地方。

TIPS:我做过头部保险公司和银行的项目，项目明确要求遵循用户信息安全隐私的规范，输出的日志要脱敏，所以我们排查问题时看到的日志信息也是极少的，所以控制台真没必要输出乱七八糟的东西，排查问题时看着都头大，牛逼的系统必然是控制台不动，风平浪静，控制台一动，神兵天降。

6、数据库设计原则

1、关系、常见的关系有一对一、一对多、和多对多，表关系要符合实际业务、数据结构契合表结构，例如不能用多对多关系的表存储一对多的数据。

2、不建议使用数据库的外键来约束数据，建议使用代码约束数据完整性、因为现如今解决高并发存取数据的常用方案是分库分表，使用数据外键约束不方便分库分表、不利于拆分模块。

3、不建议存储逗号分隔的字符串，逗号分隔意味着一对多，本体通常包含更多的信息，而这些常常是我们用到的，不利于面向对象的方式开发。

7、模块设计通用性及产品化原则

模块设计应该遵循通用性和产品化，通用性可以减少重复造轮子、预留商业化的空间。

以调查问卷功能为例

假设现有一个某团购app的需求，需要调研平台的使用体验，需要调研入驻商家某客服的服务态度、需要调研某入驻商家的产品使用情况。在这里商家客服系统和产品隶属于2个模块，下面是最低限度实现需求的三种设计。

A设计

设计成独立的云原生系统、为客服模块和产品模块赋能。预期开发耗时2人/天。

B设计

设计成独立的模块集成到客服模块和产品模块，以java spring体系为例,其实已经提供了模块设计的思想。预期开发耗时1.9人/天。

C设计

复制共性代码、针对个性的化的地方独立开发。预期开发耗时 1.9人/天。

D设计

各提供一套代码耦合到客服模块和产品模块。预期开发耗时 2.9人/天。

评价

D设计不评论了，设计出这样系统的项目经理建议“回炉重造”。A、B、C所用的时间成本看似差不多，但是C设计的维护成本是倍增，B设计比A设计看似成本低一些，但是商业化成本高一些，难以形成独立的产品。编者考量当下的技术生态更倾心于A设计，但是我们在开发过程中由于各种原因通常难以采用A设计，A设计意味着与公司高层沟通，考量多。

8、项目管理经验之谈

之所以与大家探讨项目管理、因为编者是一个近十年开发经验的老码农、大到万人之多小到十人以下（技术相关的人）的公司都呆过，经历过各类大大小小的项目，从开发到项目经理到总监再次回归到开发，踩过雷趟过坑，职场浮沉多年终于有一些对【职业素养】的见解，在这里分享出来希望能够帮助大家做好职业规划或者做好工程。这些见解离不开谈论人和职业，下面是从行业现状和项目成败最有争议的一个角色来探讨的，不是可以针对项目经理这一职位。

大家的共识中的项目经理职权是只关注于业务不关心技术，然而国内现状是百分之90的公司没有条件做到职权分明，这是当下很多项目经常面临着难以满足用户需求用户找茬或者满足用户需求但是开发成本高、沟通成本高的问题的原因吗？

对于大部分有问题的项目来说客户心里是标杆并不高，不是故意找茬，之所以百分之90的项目经理还活着好好的，是因为客户不懂技术默认了行业现状，买了单还有就是头部企业或者开源团队的架构贡献。在这里向诸如阿里团队、github等平台开源大佬致敬。

分析原因、轻松超越同行

规避掉大部分人项目经理认为的“我理清需求和客户处好了关系就不是我的问题”的共识，剩下出问题的点就是系统架构不到位、程序员编码不规范。因为在这里是探讨项目经理，再排除掉程序员编码不规范的因素就只剩下架构了，虽然貌似是技术的锅，但是项目经理应该为项目结果负责。以下是结合行业现状和痛点来看几类项目经理的客观表现和成果，我们就可以总结出我们该怎么做才能成为合格的那个。

1类项目经理：

与客户良好关系、需求把握准确，引导客户设计合理的业务。对于技术，可以把握业内先进的架构，出色完成项目

2类项目经理：

与客户良好关系、需求把握准确，引导客户设计合理的业务。非技术出身，但是借鉴并执行业内先进规范和设计，可以良好的完成项目

3类项目经理：

与客户良好关系、需求把握准确，引导客户设计合理的业务。非技术出身，但能够寻求架构或者有经验的技术探讨完成 可以合格的完成项目

4类项目经理：

不能准确把握需求，频繁变更需求，出了问题PUA下属。勉强完成项目

5类项目经理：

职业素养低，不能做好自己的分内的职责，不能合理的协调人员，不把工作放在第一位，为个人利益PUA下属。

总结

每一项技能每个人有强有弱，每项技能在实际中的作用也不尽相同，只要我们找对方法就能出色的完成工作，因为我们有很多案例和前辈的经验可以借鉴。然而对于第五类项目经理以我的所见来看，大公司很多，习以为常，中型公司也有，但是害群之马，小公司通常会死在这类人手上。

在16年之前PUA是一门技术，使用的人通常情商较高，17年开始很多人懂了PUA，太多人用PUA干坏事，于是提起PUA人们最先想到的是这个人人品不咋地，要远离他，现在PUA已经完全变成贬义词，我甚至都觉得LOW,你们觉得呢。我对软件这行业是敬重的，可能是因为我从小有个科学家梦，后来几年我干疲了，甚至自嘲自己是搬砖的码农，但那会我还是以做工程的心态来做软件，什么是做工程，需要设计、论证、实施，而不是随随便便搬几块砖就能垒起来一栋房子，哪怕是民房你也不敢住吧。所以既然大家都是做工程的就少些情商多些直商吧。

9、云原生应用经验之谈

抛开云环境不谈，我觉得云原生应用像是从云服务模块进化而来的，因为springcloud兴起时大家还不知道什么是云原生，只觉得springcloud的模块化开发和模块化运行是一大靓点，但后来发现模块功能划分不好会有严重的耦合问题，反而加重了开发成本。后来兴起了云原生应用，看起来更独立更产品化（比如kubesphere应用市场解决方案）,不是说云原生和产品化有必然关系，但是云原生相比于类似于springcloud这样的应用更轻量化且在云上有很好的表现。

10、云环境经验之谈

1. 用作开发测试环境，至少可以让程序员的交付更简单，一键发布应用一键版本管理
2. 用作开发测试环境，至少硬件规模可以动态调配，让程序员更能清楚自己的软件的承载能力
3. 用作测试环境和生产环境，可以更好的查询日志，帮助程序员定位问题
4. 用作生产环境可以有效的管理敏感信息
5. 用作生产环境可以清晰感知流量应用流量（流量配比、镜像流量寻找线上问题）
6. 用作生产环境可以有效的管理和利用硬件资源
7. 可以让你的企业看起来更像一个科技公司

11、敢于归纳经验和定义标准

经验都是别人趟过坑，哪怕今天的经验明天有更好的解决方案，哪怕经验难以普适，但是定义标准可以让大家步调一致，方便合作。就像如果没有当初的http 0.9就不会有今天丰富的互联网世界，更谈不上http2和3。如果没有当初的ipv4也没有世界互联的景象。

总结

好的约束和总结能够提升我们的开发效率，如果太自由可能一时爽，最后很容飞鸡变成直升鸡。