當pageIndex遇上pageNo

標籤：style   blog   http   使用   io   ar   資料   2014   問題   

我們的項目程式裡，由於趕項目進度，同時，大家缺乏相應的溝通，在服務層提供的介面裡，涉及到分頁查詢的，有如下三種情形：

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。開發經理在review大家的交付成果時，顯然就出現bug了。 於是，倡導統一就顯得很迫切了，但是由於項目比較龐大，怕修改會帶來新的麻煩。

架構師觀點：從使用習慣上來看，pageIndex是從0開始的，index嘛；而pageNo表示計數，所以從1開始就比較容易理解了。

技術總監：不管是叫什麼名了，就約束前端調用方從1開始傳遞這個參數。（技術總監的英語水平用一個名牌形容就是TCL）。

我覺得這種重構是值得儘快來做，越往後拖的話可能就越糟糕，就執意堅持。 最後，和開發經理花了2個小時，並做了一些檢查，最終修複成如下方案：

分頁查詢使用統一模型PageModel，其中，頁碼屬性使用PageIndex，調用方從0開始傳參。即第一頁的話pageIndex=0，第二頁pageIndex=1，et cetera.

 

畢竟這是Team 專案，底層架構、技術預研、服務層邏輯、前端UI，大家有不同的分工。我想，即使是完全交給某一個人來做，遲早他也會亂的。因此，尤其是team leader，應該儘早在做code review時發現這些問題，並統一開發規範。這就完了嗎？沒有，接下來是…………………………………..………………………………….…………………………………..………………………………….………………………………..………………………………….………………………………..………………………………….………………………………..………………………………….………………………………..………………………………….……………………………..………………………………….………………………………..…………………………………. …………………………………..………………………………….…………………………………..………………………………….………………………………..…………………………………. …………………………………..………………………………….…………………………………..…………………………………………………………………..…………………………………. …………………………………..………………………………….…………………………………..…………………………………………………………………..…………………………………. …………………………………..………………………………….…………………………………..…………………………………………………………………..…………………………………. …………………………………..………………………………….…………………………………..………………………………….…………………………………..…………………………………. …………………………………..………………………………….…………………………………..………………………………….………………………………..…………………………………. …………………………………..………………………………….…………………………………..………………………………….…………………………………..…………………………………. …………………………………..………………………………….…………………………………..………………………………….…………………………………..…………………………………. …………………………………..………………………………….…………………………………..………………………………….…………………………………..…………………………………. …………………………………..………………………………….…………………………………..………………………………….…………………………………..…………………………………. …………………………………..………………………………….…………………………………..………………………………….…………………………………..…………………………………. …………………………………..………………………………….…………………………………..………………………………….…………………………………..…………………………………. …………………………………..………………………………….…………………………………..………………………………….…………………………………..…………………………………. …………………………………..………………………………….…………………………………..………………………………….…………………………………..…………………………………. …………………………………..………………………………….…………………………………..………………………………….…………………………………..…………………………………. …………………………………..………………………………….監控大家的執行情況。

 

跑題了，接著聊一點規範吧。在你的開發組的項目裡，

l  就商品/產品的命名上，是否同時存在product和goods？

l  是否存在一些全域變數（在使用時才聲明變數，這是個好習慣，全域範圍極易因使用不當而帶來潛在風險）

l  調用別人介面得到list後，是不是不判斷為null（有時還需判斷其Count>0）就直接使用？（不要輕信別人的代碼，即使他確信不會返回null）

l  ……

 

繼續，我的一點實踐總結：

l  對於List對象的命名。通常以-List結尾，比如productList、orderList。另一種方式，對於名詞，可以以其複數形式來命名。如products、orders，而對於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)

傳入的資料是bytes, KB, MB 還是GB？

改成public void CreateCache(int cacheSize_mb)

一目瞭然，並且會減少調用者傳入錯誤資料的可能。

 

繼續跑題，說下產品設計方面，在我們產品經理設計的商城頁面裡，其中，採購平台頁面裡有一個欄位叫最新上架：

在另一個一級分類頻道頁裡，也有一個取數邏輯相同的欄位叫新品到貨：

 

個人認為，全域角度來看的話，這2個欄位應該取相同的名字。難道同一個商城裡你能有些頁面稱商品為商品而有些頁面稱商品為產品嗎？

 

BTW，老早就想寫這篇部落格了，總是找各種理由推脫。周二晚上下班和一同事一起乘公交回去，我告訴他我次日上班後就抽時間寫一篇部落格。誰知，到了周三中午我同事問我寫了沒有時，我卻發現我由於工作忙給忘記了。——我借故忙給推脫了，直到現在，8月份的最後一個工作日。

說到忙，這段時間，精確的說，是有3個月了，是有些忙，倒是沒少加班，每到周五晚又搭車80公裡回家看孩子，每周一5點起大早又匆匆趕回來。為什麼老回家？我家新添了兩名小成員，我的雙胞胎閨女，小飛飛和小揚揚，真是不知不覺，她們已經兩個半月大了，這期間的每個日夜，妻子默默付出了很多。。。

 

當pageIndex遇上pageNo