当pageIndex遇上pageNo

作者发现，本文被多个博客和网站转发。赠人玫瑰，手有余香!
本文版权归作者和博客园共有，欢迎转载，转载请注明出处: https://www.cnblogs.com/buguge

 

我们系统的程序里，由于赶项目进度，同时，大家缺乏相应的沟通，在服务层提供的接口里，涉及到分页查询的，有如下三种情形：

l  List<OrderInfo> GetOrderList(OrderQueryModel condition, int pageIndex, int pageSize);

l  List<OrderInfo> GetOrderList(OrderQueryModel condition, int pageNo, int pageSize);

l  List<OrderInfo> GetOrderList(OrderQueryModel condition, PageMode pagedInfo);

上面方法的签名里，同时涉及到了pageIndex和pageNo，加上缺乏必要的注释，前端开发组同学在调用时，尤其是获取第一页数据时，有的给的是0，有的给的是1。等到冒烟测试的时候，这些分页查询就出现bug了。 于是，倡导统一就显得很迫切了，但是由于项目比较庞大，怕修改会带来新的麻烦。

架构师观点：从使用习惯上来看，pageIndex是从0开始的，index嘛；而pageNo表示计数，所以从1开始就比较容易理解了。

技术经理：不管叫什么名字，就约束前端调用方从1开始传值吧。（技术经理的英语水平用一个名牌形容就是TCL）。

我觉得这种重构是值得尽快来做，越往后拖的话可能就越糟糕，就执意坚持。 最后，和开发经理花了2个小时，并做了一些检查，最终修复成如下方案：

分页查询使用统一模型PageModel，其中，页码属性使用PageIndex，调用方从0开始传参。即第一页pageIndex=0，第二页pageIndex=1，etc.

 

毕竟这是企业应用，是团队项目，底层框架、技术预研、服务层逻辑、前端UI，大家有不同的分工。开发规范该明确的必须要尽早明确。我想，即使是完全交给某一个人来做，迟早他也会乱的。因此，尤其是team leader，应该尽早明确并统一相关开发规范，并在做代码走查或codereview时发现这些问题。这就完了吗？没有，接下来是…………………………………..………………………………….…………………………………..………………………………….………………………………..………………………………….………………………………..………………………………….………………………………..………………………………….………………………………..………………………………….……………………………..………………………………….………………………………..…………………………………. …………………………………..………………………………….…………………………………..………………………………….………………………………..…………………………………. …………………………………..………………………………….…………………………………..…………………………………………………………………..…………………………………. …………………………………..………………………………….…………………………………..…………………………………………………………………..…………………………………. …………………………………..………………………………….…………………………………..…………………………………………………………………..…………………………………. …………………………………..………………………………….…………………………………..………………………………….…………………………………..…………………………………. …………………………………..………………………………….…………………………………..………………………………….………………………………..…………………………………. …………………………………..………………………………….…………………………………..………………………………….…………………………………..…………………………………. …………………………………..………………………………….…………………………………..………………………………….…………………………………..…………………………………. …………………………………..………………………………….…………………………………..………………………………….…………………………………..…………………………………. …………………………………..………………………………….…………………………………..………………………………….…………………………………..…………………………………. …………………………………..………………………………….…………………………………..………………………………….…………………………………..…………………………………. …………………………………..………………………………….…………………………………..………………………………….…………………………………..…………………………………. …………………………………..………………………………….…………………………………..………………………………….…………………………………..…………………………………. …………………………………..………………………………….…………………………………..………………………………….…………………………………..…………………………………. …………………………………..………………………………….…………………………………..………………………………….…………………………………..…………………………………. …………………………………..………………………………….监督大家的执行情况。

 

跑题了，接着聊一点规范吧。在你的开发组的项目里，

l  就商品/产品的命名上，是否同时存在product和goods甚至good？ 就手机号的命名上，是否同时存在mobile和phone和telephone甚至mphone甚至tel？

l  是否存在一些全局变量（在使用时才声明变量，这是个好习惯，全局作用域极易因使用不当而带来潜在风险）

l  调用他人接口得到引用类型后，是不是不判断null就直接使用（集合对象有时还需判断其Count>0）？（菜鸟,新鸟,中鸟,老鸟，谁没遇到过System.NullReferenceException / java.lang.NullPointerException？--------不要轻信别人的代码，即使他确信不会返回null）  同样，是否也对接收到的响应参数做类似的判断？

l  ……

 

继续，我的一点实践总结：

l  对于List集合对象的命名。通常以-List结尾，比如productList、orderList。另一种方式，对于名词，可以以其复数形式来命名。如products、orders，而对于id集合，则最好命名为idList而非ids。

l  我们目前的项目是一个小型的B2B+B2C模式的电商交易系统，订单表名自然是喜闻乐见的orders。这个表同时存放这2种模式的交易数据，对于零售来说是零售订单，对于商家交易来说是采购单。下图是Orders表与会员（普通用户和商家）的ER图。对于交易涉及到的双方，orders表里有2个字段CustomerId和ShopId。随着业务逻辑梳理、服务层逻辑代码的编写、客户端调用、需求微调所致迭代等工作的不断进行，发现买家卖家登录后对这2个属性赋值查看自己订单列表时，存在诸多不便，尤其是理解层面。目前，项目在逐步将这2个属性改为BuyerId和SellerId（同样的CustomerName改为BuyerName，ShopName改为SellerName）。

l  在我们项目里，商城一些推荐栏比如推荐商品，这个功能是由运营人员通过后台来设置的，这个列表的显示需要有排序，这时在领域模型里就要有这么一个显示序号的属性，我们起初命名成了ShowOrder，后来改成了DisplayNo，为了避免让大家联想到订单。

 

 

 

我很赞同我们项目组架构师的一句话：“架构要考虑成本和效率”。他在面试求职者时曾提问：“如何做到你的接口不需要用户借助说明文档就能理解?” 值得我们思考。

真的是有最佳实践的，

如webservice的wsdl。

再如 public void CreateCache(int cacheSize) ，传入的数据是B, KB, MB 还是GB？改成  public void CreateCache(int cacheSize_mb)  一目了然，并且会减少调用者传入错误数据的可能。

再让我们看看微软底层对一些参数的命名：

public sealed class Thread : CriticalFinalizerObject, _Thread
{
        //
        // 摘要: 
        //     将当前线程挂起指定的时间。
        //
        // 参数: 
        //   millisecondsTimeout:
        //     线程被阻塞的毫秒数。指定零 (0) 以指示应挂起此线程以使其他等待线程能够执行。指定 System.Threading.Timeout.Infinite
        //     以无限期阻止线程。
        //
        // 异常: 
        //   System.ArgumentOutOfRangeException:
        //     超时值为负且不等于 System.Threading.Timeout.Infinite。
        [SecuritySafeCritical]
        public static void Sleep(int millisecondsTimeout);
}

 

 

继续跑题，说下产品设计方面，在我们产品经理设计的商城页面里，其中，采购平台页面里有一个栏位叫最新上架：

在另一个一级分类频道页里，也有一个取数逻辑相同的栏位叫新品到货：

 

个人认为，全局角度来看的话，这2个栏位应该取相同的名字。难道同一个商城里你能有些页面称商品为商品而有些页面称商品为产品么？

 

万恶的拖延症啊！老早就想写这篇博客了，总是找各种理由推脱，万恶的拖延症啊！周二晚上下班和一同事一起乘公交回去，我告诉他我次日上班后就抽时间写一篇博客。谁知，到了周三中午我同事问我写了没有时，我却发现我由于工作忙给忘记了。——我借故忙给推脱了，直到现在，8月份的最后一个工作日。

说到忙，这段时间，精确的说，是有3个月了，是有些忙，倒是没少加班，每到周五晚又搭车80公里回家看孩子，每周一5点起大早又匆匆赶回来。为什么老回家？我家新添了两名小成员，我的双胞胎女儿，小飞飞和小扬扬，真是不知不觉，她们已经两个半月大了，这期间的每个日夜，妻子默默付出了很多。。。