zoukankan      html  css  js  c++  java
  • 支付中心接口设计之参数命名

    目前,java版支付中心处在研发阶段。下午,特有钻研精神的云龙同学饶有兴趣的问我“战哥,你觉得表字段用哪种命名方式比较好呢?”

    所用的db是mysql,他是想征求一下我的看法,是用驼峰式命名还是小写加下划线方式。

    我直截了当地说用驼峰式。为什么? 我认为,像java语言或.net语言,实体类的属性一般是遵从驼峰式命名的(稍有不同的是java一般首字母小写,而.net是首字母大写)。我们的程序里的数据访问层一般均采用ORM框架。如果表字段是小写字母+下划线,那么,相应的POJO/POCO实体类的属性也会是小写字母+下划线,这样,违背了驼峰式命名规范,有违代码的整洁度。

    接着,如我所期,云龙问“那你支付中心对外的api接口参数为什么用小写+下划线的方式呢?”

    我答道,对外提供的接口,

    • 如果用驼峰式。 首先,我们用word编写接口说明文档时,在参数表格列里输入参数名后,如果按tab键,则word默认首字母是大写的。而如果恰好我们的首字母是小写时,如果我们在编写时忽略了这个细节,这就会给对接者带来疑惑(产品设计上有一条重要的原则:Don't Make Me Think,同样适用于软件设计); 更甚之,如果签名规则要求的签名原串包括参数名时,那么,因字母大小写所致的验签失败往往不那么容易排查出来,进而造成双方的“不必要”沟通。
    • 如果用小写+下划线。 首先,这种方式规避了上面驼峰式命名的不足。 其次,考虑到商户对接存在不同的编程语言如php/java/.net,跨语言程序员之间也都会认可。

    云龙和伟业听后表示赞同。
    我解释,我们在接口开发和商户对接支持这些事情上踩过的坑太多了,逐渐的就要考虑这些细节。

    【另面观】

    其实,也许是从事IT项目管理的职业病,我喜欢考虑项目成本,系统设计方面,始终坚持通过合理设计规避不必要的沟通甚至互撕。

    像上面支付接口的参数,如果不考虑命名形式,用驼峰式,势必会增加后续甲乙双方联调过程中的沟通成本。那么,倘若我们改为小写加下划线的形式,就会规避这些真的是不必要的沟通。 ——这就是软件意识。

    有些程序员一天的工作就是商户接口对接联调支持。有些领导看到下属员工一天忙碌的对接,认为其工作很饱满。 

     

    【延伸】

    我也饶有兴趣,忽然在想,我们支付中心对外提供的这种接口在技术层面叫作什么呢? api是应用程序接口,即程序包里的公开的方法及对这些方法的说明。而这种通过http发布的接口,是什么呢? rpc接口?rmi接口?webapi? 我也去找云龙和伟业探讨,他们说就是接口嘛,笑我太爱琢磨了。

    我常常就这样较真儿,当然,我也不认为这种较真儿是什么缺点。于是,为了一个细节,我会去查看好些技术帖子和blog。于是,我也再了解了一下rpc、web Service、web api。

    今天周六,加班的同事早已回家。我从洗手间回到工位,办公区周围的昏黑,窗外三环上疾驰的车辆,CBD夜景灯火阑珊,不觉中渲染出我的孤寂。大周末的,是时候回家陪陪孩子做点家务了。

  • 相关阅读:
    每天一道LeetCode--141.Linked List Cycle(链表环问题)
    每天一道LeetCode--119.Pascal's Triangle II(杨辉三角)
    每天一道LeetCode--118. Pascal's Triangle(杨辉三角)
    CF1277D Let's Play the Words?
    CF1281B Azamon Web Services
    CF1197D Yet Another Subarray Problem
    CF1237D Balanced Playlist
    CF1239A Ivan the Fool and the Probability Theory
    CF1223D Sequence Sorting
    CF1228D Complete Tripartite
  • 原文地址:https://www.cnblogs.com/buguge/p/6979948.html
Copyright © 2011-2022 走看看