對日軟件開發體會之一
以前從事對日軟件外包工作，覺得很多日本企業的開發流程過於死板，開發框架也過於老套，對開發人員的技術要求極低。但他們的文檔要求卻不是一般的高了。在文檔這一點上我們是不是可以參考一下他們的做法。
日本人的需求文檔的作者一般是項目負責人，這類人需要有很強的代碼功力，因為需求文檔上需要寫下詳細的邏輯設計，細到一個判斷語句，細到一條SQL 語句。可能你認為這樣很BT，因為我們總是認為設計歸設計，SQL之類的都是開發人員的事情不需要在文檔上寫明，但這樣做的好處是只要開發人員一拿到需求 文檔只要完全按照文檔上的思路來實現代碼，原則上只要文檔的思路沒有錯誤就不允許修改邏輯（有時需求上的邏輯判斷很冗余，比如a>b並且 a>c的情況下去判斷b大於c，其實這樣的判斷邏輯開發人員覺得可以改為(a>b)&&(b>c)看起來更清晰更優 化，但這是不允許的）。因為一旦實現的代碼和文檔上的需求邏輯對不上就不利於維護，以后需求有變更的時候文檔的修改和代碼得不到統一，這樣容易產生風險； 同時也不利於測試人員的用例設計(對日軟件的測試傾向於白盒測試)，測試人員是根據需求文檔的邏輯來寫case的，一旦代碼的實現和需求上的邏輯不統一， 用例就不能完全覆蓋代碼，這樣也容易產生風險。
在這一年的對日軟件開發中，我體會到日本人主要把精力放在了前期的需求文檔上，文檔包含了代碼的實現邏輯，SQL語句的編寫等等，使得在開發上花很少很少的時間就可以實現程序，產生的bug率會很低。
當然我們的UC不可能像日本人那樣連代碼的邏輯思路也寫完整，但UC需求是不是應該由開發人員來寫我這里有個疑問。首先，開發對需求了解的度應該不 是百分之百的，由他他來寫UC是不是會容易遺漏細節(很多遺漏的細節在UC評審中可能會被忽略)；其次，開發寫UC容易根據自己主觀上的代碼實現的難易程 度來適當的調整需求(他們總是有理由說如果不這樣做會代碼的難度會增加多少倍，但換位思考一下，要知道用戶並不會因為實現技術有多難而體諒我們，用戶只關 心結果)。
我覺得UC的編寫是不是可以讓PD或者項目經理來完成呢？由他們編寫出來的需求文檔我想后期需要改動的地方會很少，實現的頁面用戶體驗也高，相對來說可以很好的減少測試人員和開發人員的溝通成本。
對日軟件開發體會之二
多數日本企業在軟件開發流程中各個組的組長一般只做review工作，review你的用例是否全面覆蓋了你的需求，review你提交的成果物有 沒有錯誤。Review是一份很細致的工作，需要對需求的把握十分理解。除了組長做review工作外，測試和測試之間還要做交叉測試，各自造不同的數 據，在提交成果物之前確保找出所有的bug。
這種交叉review和交叉測試的過程其實每個企業都有提到，但一方面是人力的問題，另一方面是時間的問題，似乎很少有企業能真正做到位。
然后對日軟件開發中測試人員的要求比開發人員的要求高，在項目的時間計划安排上也是測試時間遠遠要比開發時間多，一般開發時間安排為1人/日的話， 測試時間起碼是2.5人/日。因為在前面文章中我已提到需求文檔上已經把所有的代碼實現邏輯寫好了，開發人員幾乎在開發時只要將需求上的邏輯加一件“外 套”，就像現在我們使用的ruby腳本一樣，在業務流代碼已經完成的基礎上我們只要給將業務流代碼加個驅動方法使它跑起來就結束工作了；而測試人員比較辛 苦，開發人員在開發的這段時間一般還不夠測試人員寫TC的；在測試的時候還要保留證據證明你是完全按照case來執行測試的。比如在執行某一個用例的時候 用到了哪些數據，如果是測試前台頁面的，那就需要將頁面上文本框的內容截圖出來，如果是測試后台批處理程序的，那么需要做一個輸入數據文檔，同時將程序跑 出來的日志、生成的各類統計文檔等全都保留下來，將這些文檔的內容和預期結果做對照，來判定測試的用例是否通過。
當然我們是否也需要花那么多的時間去做這一系列的產出物我覺得需要探討？就目前我們的業務來說，我個人覺得沒有必要，但那樣做確實有一定的好處，首先很規范，不會馬馬虎虎一測了之；其次，一系列的輸入數據文檔便於回歸測試，也便於下次業務有變動后可以節省造數據的時間。
對日軟件開發體會之三
多數日本企業在軟件開發流程中喜歡把模塊細分化，細分到一個很小很小的功能點，比如一個彈出框，一個查詢按鈕等等，然后每個細分好了的功能點寫一本需求文檔，這樣做也有一定的好處。
首先，對測試人員來說容易寫testcase（相對一個有很多很多操作鏈接的復雜頁面來說，確實這樣細分了的話寫case的思路會清晰很多），然后寫出來的case對需求的覆蓋率幾乎是百分之百的；
第二，對開發人員來說相同的機能點無需再次開發（比如淘江湖中的投票模塊有一個“分享給好友”的好友選擇功能，在推薦模塊中也同樣有這么一個功能，我們在做的時候卻是分別開發，這樣對測試人員來說不僅增加了工作量，而且往往開發出來的兩個機能點的風格不統一）。
第三，對測試人員來說對不同模塊的想同機能點無需再次測試。比如淘江湖的評論模塊，幾乎在淘江湖的各個子產品中（如推薦、投票等）均有評論功能，在投票項目中如果已經測試了評論，那么在后期添加進來的推薦模塊就不需要再次測試評論功能了，因為用的都是同一個封裝。
第四，維護起來方便。可能你會認為這樣的模塊細分化的程度有些過分，本來我一個頁面寫一頁UC就可以了，現在卻要一個功能點寫一個需求（一個頁面上 會有很多個功能點，比如刪除、查詢、添加等），會增加很多工作量，同時在代碼整合的時候也需要很多的時間。其實在新增功能模塊的情況下卻是如此，但如果這 個功能模塊需要經常變動的情況下你會發現維護起來很方便，比如現在需要優化“分享給好友”這個機能，那我們只要將“分享給好友”這本需求文檔做一下變動就 可以了，然后開發人員和測試人員只要關注這本需求的改動背景和改動點就可以了，代碼調用的接口還是一樣的，無需再次整合，從而可以大大地縮短維護時間。
當然這個模塊細分化的概念對淘寶可能並不適合，畢竟我們的項目和日常非常多，需要快速的發布產品，沒有那么多的時間來搞這么多的文檔，但是從中我們 是否可以借鑒到某些方法來適用到淘寶呢？我想應該是有的，比如我們可以將模塊細分化到一定的程度，不需要把他拆解到最小單位，這樣應該能夠很好的把握這個 度。
本文出自：Taobao QA Team