項目總結

從南京回來也2周整了，最近幾天一直在CSDN上閒逛，看着IT男女們自己發表的博文，有談論技術總結的，有談論工作總結的。自己心裏不由得也想總結下自己在南京這段時間(5個月)所學所見所聞。

我們項目組有16個開發人員，其中一個爲項目負責人，另有3個項目組長。我們是2012年03月26號去的南京，回來是2012年08月20號。去的時候還穿着長袖及外套，到那就感覺明顯比北京溫度高很多，呵呵。一句話先總結下這段時間的收穫吧，就是感覺：苦受了，很值得！

項目最初期就是寫項目概要設計文檔，這個任務還好不是忒麻煩，週期大概就是一週左右（加業務人員的評審，就是開發人員講解業務人員提意見及糾正）。我們組4人，一個組長（我們帶隊人，也是公司一架構師），三個開發人員。其他組同樣是4人，一共分了4組，

其中一組組長是江蘇分行派的人，項目臨近結束時撤走了，他們那組來來回回也流動了好幾個人。而業務人員是4個，其中3個是農行總部的一個好像是山東分行的，一期項目就是他們跟着，顯示二期也是他們搞的，所以時間還是挺長的。至於3個月後陸續續來的各地測試專家就不用多說了，各塊人員分配大致就是這樣了。

我們項目名稱爲“金庫業務（調撥）系統”，分18個模塊（12個交易模塊與6個查詢模塊），包含系統維護、現金調撥、重要空白憑證、有號物品、有價單證、箱包管理、假幣調撥、貴金屬調撥、清分管理、金庫檢查、機具管理、其他無號物品及其他幾個查詢模塊。

我們組做的是系統維護、金庫檢查、貴金屬調撥、其他無號物品這4個模塊，其中系統維護是我們大家在北京已經做好了，但是後面一些維護及變更及新功能是我們搞了，這模塊是所有模塊的基石。我做的主要是貴金屬，同時還有系統維護、金庫檢查，而其他無號物品有維護。貴金屬模塊包含貴金屬維護、貴金屬調撥、貴金屬查詢、貴金屬庫存修改、事件單狀態特殊維護。其中貴金屬維護有企業維護、品種維護、規格維護，貴金屬調撥分系統內調撥（又分非掛靠行與金庫間的出、入庫錄入與複覈），貴金屬查詢有庫存明細查詢、出入庫查詢、事件單明細查詢、交接單查詢、品種規格查詢、庫存修改歷史記錄查詢。

菜單如圖：

貴金屬查詢如圖：

先介紹介紹貴金屬的維護吧！企業維護主要是對企業代碼進行增、刪、改功能。已經存在的企業代碼是不能重複添加的。而刪除功能到上線後是要屏蔽的，不能隨便進行刪除，而現在刪除也是有限制的，它下面有品種代碼引用的話是不可以刪除，同理，品種代碼下有規格引用也一樣。規格代碼下有庫存引用也不可以刪除。品種、規格維護如同企業維護。一點業務規定：企業代碼長度3位，品種與規格最多6位。

1）貴金屬調撥分系統內與系統外出入庫錄入與複覈。非掛靠行出庫調撥需要AT系統（與G系統交互的一個系統）發送審批信息供實物出庫時進行校驗是否存在調撥關係即將要調入的行部是否正確。第一次審批信息（調出行、調入行、調撥日期）傳入G系統插入初始調撥單表中，第二次調撥單信息（含調撥單明細）插入原始調撥單表一份同時插入新調撥單（真正交易的調撥單）。交易操作：點選“系統內出入庫錄入“顯示調撥單列表，點擊調撥單號彈出調撥單明細框是可以覈對下出入庫信息與過來的實物是否相符，不符的話可以進行取消交易操作，讓AT系統從新發送，當然在確定時G系統會校驗調入行是否相符，不符同樣會拋出異常進行相應提示。否則，進行出庫錄入交易並改變調撥單狀態等待進行復核操作。

當然，系統內錄入也可以批量錄入操作。金庫間出庫調撥同非掛靠行，不同一點是金庫間出庫後會隨時生成入庫調撥單（在G系統生成）。

2）接下來要進行出庫複覈交易，點擊”系統內出入庫複覈“進入事件單列表頁面，點選事件單號彈出事件單明細，複覈後會進行出庫交易操作，庫存進行相應操作。複覈時候會驗證金庫錄入與複覈人是否是同一人，此交易不能爲同一人。如果進行取消交易操作會需要主管授權，授權成功後此事件單纔會設置爲取消狀態（相當於事件單已經失效）。而入庫操作需要校驗實物與事件單信息是否相符，不符合的話按照實物進行事件單調整。現在是系統內的出庫交易，其它所有的都需要校驗調撥行是否開啓，至少有一個需要開啓，不然的話沒法進行調撥操作。調撥情況分：1）只有一個調撥行，如出庫行開啓就是系統外調出。2）只有一個調撥行，如入庫行開啓就是系統外調入。3）有二個調撥行，二個行都開啓就是金庫間出庫調撥。4）有二個調撥行，如出庫行開啓入庫行關閉就是非掛靠行領用。5）有二個調撥行，如入庫行開啓出庫行關閉就是非掛靠行上繳。

而系統內中入庫交易除了覈對實物並可以改變事件單外，其他都大同小異。

非掛靠行：

金庫間：

3）掛靠行出入交易有點不同，掛靠行出入庫錄入需要在G系統操作與AT沒什麼關係。掛靠行就是自己行往自己行調撥。錄入界面如圖：

錄入界面：

流程圖：

掛靠行出入是根據自己選擇確定的，而事件單明細是根據選擇不同企業進行一條一條添加的。此處用了個2級聯動下拉。另外還有自動計算總重量與動態填寫總重量（大寫），提交後會生成掛靠行的調撥單。此處，事件單明細不允許添加相同企業下，同種品種不同規格。

錄入成功後，則進行後續複覈交易，同非掛靠行。

4）系統外是從AT傳入的事件單中只能有一個行，調出行存在就是系統外調出的事件單，調入行存在就是系統外調入的事件單。系統外調撥的事件單中有調撥批次號。系統外入庫錄入需要在G系統錄入調撥單明細（品種代碼、規格、數量、總重量、狀態）。下拉選擇品種代碼、規格代碼、數量，然後系統自動計算總重量，提交後添加調撥單明細，同時右側“刪除”按鈕也可以對添加的明細進行刪除操作。

此交易也有取消交易操作，當然也需要進行主觀授權，主觀授權成功後才修改調撥單狀態，出庫置爲：06入庫置爲：03

5）貴金屬庫存修改

功能：根據輸入條件（行號、企業代碼、品種代碼、規格代碼、實物狀態）查詢庫存明細。

點擊“行號”彈出庫存明細修改框，可以輸入調整方式（成品、破損、其他、凍結）、操作（增加、減少）、調整數量（大於0的數字）。調整方式指將原來實物狀態調整爲的實物狀態。操作指對實物是增加還是減少。調整數量就是要對實物增、減多少個。當爲實物間轉換時，如：成品到破損，操作不可編輯，只能填寫數量，如數量填3個，即成品減少3個而破損增加3個。如果爲同實物轉換，如：成品到成品，操作可選增加或減少，此時就是直接對當前實物進行增或減操作。

此交易只針對同企業、同品種、同規格下不同實物狀態間的轉換。修改操作也需要主管授權，授權成功後纔可進行修改庫存。

圖1：

圖2：

庫存修改需要校驗，最基本的要校驗庫存實物數量減去凍結後的數量是否夠實物間轉換。因爲凍結的實物不能做出庫操作與轉換交易。不同狀態下實物數量總和=凍結+非凍結=庫存總量。對庫存修改的每筆交易都有記錄，在貴金屬查詢模塊中可以對沒筆操作記錄進行查詢。

模塊爲“庫存修改歷史記錄查詢”。

新增庫存就是對庫裏沒有維護的庫存明細進行添加。輸入要素：企業名稱、品種名稱、規格代碼、實物數量。此處下拉框爲2級聯動。同樣新增也需要主管授權。

6）事件單狀態特殊維護

功能：其主要目的就是對金庫間出庫完成的調撥單進行取消交易，同時進行庫存還原，原來出庫操作現在進行入庫操作。從AT過來的金庫間出庫調撥完成後會生成入庫調撥單（G系統生成）。當在G系統中金庫間入庫調撥單進行取消交易後，則之前出庫的明細需要還原即向庫裏再添加那些實物。由於需要操作之前出庫調撥單，所以提供了此菜單。而其他交易（非掛靠行、掛靠行等）只需根據AT流水號就可以找到出庫調撥單信息了。

根據入庫調撥單信息（事件類型、AT流水號、狀態、調撥日期）去查出庫調撥單。選擇某條調撥單，點擊“取消交易”可以對此出庫調撥單狀態置爲：06，同時修改庫存。當然取消交易也需要主管授權。

7）貴金屬查詢模塊

此查詢模塊總共有6個查詢，有查詢與打印功能。

貴金屬基本功能就如此了，當然，去南京之前還做了系統維護中“反假行部維護”，這塊暫時還沒用到。具體幹什麼的也不是很清楚。技術就是對左邊一顆樹進行操作的，有基本的增、刪、改、查，而右邊是一些關於機構樹的信息。也有相應的基本操作。

8）模塊查詢

查庫模塊做了3個查庫查詢（違規情況查詢統計、批處理違規問題清單、金庫檢查扣分情況查詢），不能說複雜，也是有點麻煩的。其實說麻煩歸根到底都是拼sql。一個功能做到最後你會發現都是在拼sql，sql拼接出來了，基本問題都搞定了。至於性能那是後話，性能調優那可能是小程序員能力範圍之外的事情。我們這塊都是我們老大搞的，建索引啊，存貯過程啊、sql調優啊等問題。然後，還有現金管理查詢中的現金領用超限額情況查詢、現金領用超限額情況查詢統計、現金限額設置查詢及各自打印。

系統維護查詢中有機構信息查詢、員工信息查詢、行部調撥關係信息查詢及他們各自的下載。另外還有機構信息維護中的調撥信息、現金審批信息頁面端的校驗及效果。

9）文檔

最後開發基本完成後就剩文檔了，除了概要設計文檔需要進一步修訂外還要寫詳細設計文檔，有貴金屬的、系統維護的（200頁），還有DB詳細設計文檔，主要是貴金屬的。

除了上面這些工作外，還有每天對數據的維護，主要是我們測試環境的測試庫，有數據更新啊、表字段有改動啊、數據的導入導出啊，都由我這在測試環境停止運行後進行統一改動。

雖然這些介紹的很粗略，但是項目還是很大的。項目架構：jsp+struts+spring+ibatis+sybase，裏面用到一些前段技術，像ajax、jquery、javascript等。開發工具是Plantix2.0，可能有的用過這個開發工具，好多人都沒聽說過呢，這工具還是很強大的，其實就是Eclipse的一擴展。這項目裏有模板下載（自己加入的）、模板打印、潤乾報表、字典翻譯（標籤那塊）、工作流（挺重要一塊）。前臺好多用的都是自己的標籤，這些東西如工作流都經過農行封裝了。而發佈服務器用的是IBM的websphere。

項目總結

其實經過此項目，我自覺得技術倒是沒學得特多，主要是學到了如何去解決問題及整個項目開發的流程，還有整個項目團隊是什麼個樣子（業務、測試、開發、項目經理）。感觸最深的應該還是最初一個多月，被老大狠狠地批。當那麼多人面，嗓門很大的批。當時都快崩潰了，因爲這也是自己第一次出差，第一次出差就封閉開發，並且當時還有點想家，所以壓力老大了。不過差不多2個月後就好起來了，自己能力上也有所提升（包括溝通及解決問題能力），再加上老大脾氣有所好轉，然後慢慢剩下時間就不錯的過來了。其實老大是認事不認人，再加上他脾氣不是一般的大。逮住誰批誰，大家也都被他批怕了，有時候有問題都不敢問他了。這樣吧，也有一點好就是可以鍛鍊臉皮薄的人。現在我臉皮就ok了，沒以前那麼薄了哈哈。

*****現在可以總結出一句話：一個項目最重要的是業務，核心人物也是業務人員。這也是自己感覺。業務搞懂了，技術幾乎沒有實現不了的，這也是老大告我們的。之所以最初犯錯及效率不是很高，就是看需求文檔不仔細，沒好好理解業務到底是怎麼就盲目去做，到後來與業務想要的有出入。說白了需求文檔作用就是一份給技術、業務、測試人共同去看，去完成上面方案的一文檔。那是業務人寫出來的，是開發人員開發、測試人員測試的依據。如果沒有文檔，業務人讓你做成什麼你做好了，回來要是需要改了，他說。。。其實不是那樣，無憑無證的，到那都說不清楚，測試那塊也是如此。所以需求文檔時必須的。現在回味回味着幾個月，自己最缺的就是細細讀並理解需求文檔到底要幹啥，說白了開發人員要一句一句去看，看不懂或不明白的及時與業務人員溝通，看是否是那麼回事。適當的時候自己可以挑重點的自己簡單記錄下。都能懂了，對開發人員來說就是去實施編碼了，怎樣將文檔中的需求一點一點變成自己手下的代碼，然後又變成可實現功能的可操作的界面。這過程也是要面臨好多問題的，包括頁面上的還有做出來的與實際不相符，這都需要改動。開發的時候一定記住：做好一功能一定要讓業務人員或測試人看下，是否正確。不要盲目的全做完再去辦這事。正常的項目應該都有每天的工作彙報這麼一個會議或交談，這一般都是組長彙報。對成員而言，彙報時不要亂報（多報、報一些沒完成的或根本沒做的）爲了贏取組長的信任或歡心。這樣子不好，對整個項目進度及本組都不好。做多少就是多少，把自己完成的彙報下就ok了，真的沒完成也要及時說明情況。這樣方面項目經理或組長跟蹤項目進度。當然，某些小問題，自己加加班啊完全可以搞定，提前報下也沒什麼。

開發過程中遇到難題了，要及時問老大（之前是要想想、查查的），最好先問下同事。應該每個老大基本都喜歡多問而又好學的那種人，加上人又嘴甜、理解又好，辦事效率高，這樣子的人好帶，絕對討人喜歡。作爲一名程序員千萬不要在哪一直的悶着，有問題了也不問，也不聊個天（QQ或者小組羣裏）什麼的。適當的時候需要活躍一點。關於如何做人這些東西，我不想多說，因爲我自己也在努力學習中。開發時候可能會遇到測試人員百般的刁難，呵呵！不能算刁難，就是不斷的提bug，甚至有需求變更（大的變更會令人瘋掉），千萬不要發脾氣，這樣對誰都不好，畢竟大家都是爲了整個項目更好，要合理的去溝通與他們。一般提需求變更是需要申請或者與老大溝通好的，你只管實現就ok了。程序員就是這麼苦逼！因爲我們組的查庫那塊，需求變更搞得我們徹底崩潰了。特別是這需求變更，改過之後更應該及時讓他們驗證是否正確，不行就再改唄。作爲程序員要敢於承擔責任，不能說項目出現問題了，自個就推卸責任，遇到問題就勇於去解決，這才方顯英雄本色，嘎嘎！

開發時一定要嚴格按照文檔上的要求，不要自己想怎麼樣就怎樣做，就算有好的提議，要提前跟老大商量下，是否可行，ok的話再提給業務人員。其實在這個過程當中，也可以鍛鍊自己與別人的溝通能力，所以要積極溝通。不同的項目，領導要求也不一樣，這東西不能一概而論，有的項目測試人員是遠程的，有的是面對客戶現場開發，總而言之：嚴格按需求文檔做，好好溝通！

編碼結束或臨近結束時候，我們老大對我們這塊做了代碼檢查，其實這工作在一邊開發的時候就在做。不合理的或冗餘的代碼及時更正，當然我們項目每週還有個農行要求的工作，就是對項目進行代碼checkstyle（代碼規範），這是農行對項目要求的，必須按照他們那規範來，規範有：代碼一行不能超過100個字符，一個類不能超過2000行，還有方法要有註釋等等。這項工作後期是我做的，導出Excel後發給大家，有那組的那組成員改下。後面做壓力測試也是對代碼一個考驗，還有sql拼寫性能問題，如sql裏用or不用in，表加索引（老大統一加的）等。優化這方面都是有經驗的人來搞的。其實開發過程中，開發工具的使用會影響辦事效率，但開發工具都是小事，重要的還是學習快速使用陌生工具這種能力，一般工具都有幫助文檔啊，網上資料也挺多的，都可以拿來學習。同樣的，大師都說：編程，代碼都是浮雲，唯有思想纔是王道！呵呵！一件事情只要你想明白了，知道怎麼去做了，做起來就快了。一個項目也是，項目精髓不是代碼，而是這樣做能帶來什麼方便或優勢。我們這系統是調撥，就是行與行間的物品調撥，怎麼能實現調撥同時能帶來能好、方便的調撥。其歸根結底就是讓參與到這系統中的人更友好的進行操作，不能說實現功能就完事了。呵呵，這些只是我自個的理解。就技術而言，就是每塊技術的搭建（包括框架），一個框架好與壞直接影響到項目運行性能的問題，這些深入的東西都不討論了。項目上線前這段時間就是調試bug了，每天幾個，越來越少，現在幾乎沒什麼了。等上線的時候會有好多問題的，應該挺忙的。其實這個項目是2期的，一期都已經成型了，好多模塊。無非是2期新添了好多東西。同時也感覺出來，老大負責一個項目也是挺挺不容易的，雖然他工資高吧。

以前我總以爲技術NB了，什麼都有了，其實真不是那樣子，對業務的理解及業務能力很重要，當然不是說技術不重要了，這2方面都要抓。去一個公司面試，如問項目經驗，那你肯定說的就是業務那塊東西了，同時用到什麼技術啊，怎麼去實現啊。有些公司也不排除僅僅考技術。反正，我覺得好好理解業務第一！業務就是大師們的完成實際問題的一些構思或者思想。

這就是這幾個月來，自己所學所感吧。文采不怎麼樣，因爲本人不怎麼寫這樣子的文章，平時也不喜歡。。。呵呵！不要見笑啊。希望多多提寶貴意見，然後咱們一起進步哦！