千萬别輕視了登陸子產品

相信大家都有做過登陸功能的子產品，而且大部分的教程也是以登陸來示範代碼功能的，是以也給了人們一個錯覺，登陸就是一個基本的功能子產品，也是基礎子產品，這個是最容易的功能，在項目組裡誰的技能相對最弱就讓誰去做吧。而現在我卻要說，千萬不要輕視了登陸功能，有時它會牽動整個項目的程序。

這是我的親身經曆。記的當我剛入項目組時，剛好新項目才啟動，客戶指定要使用ofbiz架構來實作。一個項目組的人對于ofbiz來說都是新手(雖然别人比我多看了幾個星期的資料)，大家都在一個從零的起跑線上開始飛奔了起來。由于是靈活開發模式，客戶在第一個demo show中就要去看基本效果了，無奈下，大家都是鴨子上架，邊看資料就邊開發了。

我是剛入項目組的新手，剛被調入項目組時他們正好都在開分析會，于是我就在那會上被認領了......，接着就跟着他們開會，講的是什麼？我是一頭的霧雨，ofibz？什麼東東？架構？沒聽過啊！一個組加上我正好六個人，組長基本上不做開發，當時正好在第一階段要求四個子產品，那就沒我的事了？呵呵，組長分完的任務突然又來了句，“啊，差點忘了，還有個登陸功能沒分，正好，小丁，給你做了吧，這個是比較簡單的。”，“哦！”傻呼呼的就那麼迷糊的點了點頭。

接了任務，又花了一天的時間去走馬觀花的看了點資料,(關于ofbiz的資料當時幾乎是沒中文的，英文的入門pdf資料400多頁，郁悶了)。就開始熱火朝天的幹起來了，由于架構的特殊性，為了和資料庫互動，為了頁面的渲染，為了控制器的轉發，所有的都自成一家，終于是在一天的下班時間來臨之前調好了，我的第一個任務，登陸。

當時所做的實作，應該是很普遍的一種實作，就是在session中自定義一個常量名，加入一個登陸對象來做登陸了，以後就跟據這個登陸對象來判斷登陸了，思路很簡單，功能也不複雜。不錯，第一個任務完成了。

在這以後的持續開發中，一直都很正常，但慢慢的，從學習ofbiz資料的越來越深入，實踐使用代碼開發所遇到的困難裡越來越發現有問題。因為無論是從官方介紹還是詳細資料裡都指出，ofbiz是一個功能很強大，開發中調整很便捷，适應度很高的一個架構，為什麼我們就沒有感覺到這些優點？在一次中途的sprint結束後，我暫時少領了任務，開始了對架構的全面分析和代碼研究。最後找出了原因，問題出在了我身上，就是我當初所寫的那個登陸功能，牽制了整個項目的開發。

其實，如果要把原因說清楚很難，因為那要把ofbiz的實作機制和他們架構操作思路都理新了才會知道那裡面是一環套一環，不是随便玩的。這裡我隻簡略的說個實作意圖。ofbiz架構中已經有很多實作好的功能，比如操作記錄，通路者記錄，權限控制，工作流，paypal支付，訂單系統仿ebay等等，但這都是建立在一個loginWorker的對象基礎之上，而這個對象可以說就是登陸的實作入口。也就是說如果當時我不是自己建一個登陸使用者表而是使用ofbiz所提供的對象功能，那麼之後的郵件發送，驗證碼，權限，訂單，支付等等就可以避免很多重複的輪子了，而到我發現這種情況時，項目已經進入了中期，再改所花的成本将更大，無奈之中隻能繼續走下去了，不過從那已後，我就深入的研究其源碼，至少在項目後期的開發中少走了不少彎路。

從中得到的教訓，不僅僅是ofbiz架構，對于任何項目來說，沒有那個子產品或功能是簡單容易的，他們都是一個整體，做為一個項目上司者更是要眼光罩住全局，統一排程和整合，不然下面就是戰國時代，各自為王了。也許我這隻是一個極端的例子，但是，告誡大家和提醒我自己，千萬别輕視了登陸子產品的這種小功能，任何的輕視都會為之付出代價的。