軟件作坊模式工件應用論

軟件作坊模式是指一個小規?；蛄闵⒌膱F隊負責不同類別系統的開發、維護、測試等軟件工作，強調的是單兵作戰、個人全能型的模式。軟件作坊模式下，單個程序員由于工作需要可能時而是需求調研、時而是自己選擇開發平臺進行系統開發、時而是接手他人系統進行維護、時而又是負責第三方軟件的測試工作。對該模式下的團隊來說，開發平臺的多樣性、輔助工具的隨意性、軟件工程化的低程度、系統轉接維護的高難度等，一方面對程序員的能力要求存在矛盾；另一方面對團隊的職能是極大影響。尤其在負責他人或第三方軟件廠商轉交的工作中，上面的弊端完全顯現出來。

這種模式在當前非純軟件制造企業的IT機構普遍如此，外包大型軟件、內產小型系統，盡管或多或少都采取了軟件工程中一些規范化作法、流程和工具，但一旦成員變動，轉交工作時由于不同的作法和工具，所產生的結果對負責承接工作的人來說是不可移植、不具有可讀性和可理解性的，結果是從頭開始整理系統。這和軟件工廠模式是不一樣的，該模式下，統一的開發平臺、統一的工具、統一的文檔。

基于統一的開發平臺，在技術上而言，可移植可重用的軟件模塊便會在內部流轉而不需要每個程序員去單獨開發，同時，每個程序員獨立負責一個模塊開發在速度、效率、技術含量上都會有質的不同，更重要的是，統一的開發平臺只要代碼編寫規范便會產生可讀性很高的代碼，而且由于都處在同樣開發平臺上，轉接工作不需要承接者學習或熟悉或重新搭建一個平臺。比如統一在J2EE平臺上開發。但一個本來熟悉.net平臺的程序員，突然要去承接J2EE平臺的代碼來開發和維護，顯然是不可取的。在軟件作坊模式下，就有可能產生這種情況，可能原來開發系統的某程序員是熟悉.net平臺的，于是在.net下開發了，現在轉交另一程序員，而該程序員則熟悉J2EE平臺，這個時候該程序員由于工作需要就不得不重新學習.net平臺才能勝任這份工作。不同開發平臺的切換對技術的深入是不利的。

統一的工具、統一的文檔、統一的流程效用是一樣的。比如UML工具Rational，學習這個工具的成本是非常高昂的，不能為了一個系統去熟悉使用這個工具，但如果是統一的則任何適合使用的工具去學習都是必需的。這就好比如一個印鑒，這些統一的方式構成了一致的模子，不管誰來操作，結果都是一樣的。任何程序員，輸入是上一流程傳來的標準化成果，輸出的是下一流程需要的標準化成果，這中間程序員所作的就是在統一基礎上用統一的方式加工輸入產生輸出?！皹藴?、開放、共享”始終應該是IT精神的核心。軟件工廠中每個程序員就是生產流水線上的一員，不需要理會太多，只需要拿起手上統一的器械加工到手上的半成品再轉交給下環節。

對于程序員而言，軟件工廠模式和軟件作坊模式究竟哪個更有利于發展不再本文論述之內，軟件作坊模式也不一定要采用軟件工廠模式，由于工作性質不同，也不能同而化之。本文要論述的是如何在軟件作坊模式下建立“統一”的意義，貫徹“標準、開放、共享”的IT精神。如何為之呢？筆者認為發揮工件的作用或可達到目的。何謂工件，筆者定義為取之工具部分，裁剪為適合可用之玲瓏簡化工具。軟件工程的之一目的在于建立于對工作成果的共同理解，所以任何流程、任何說明（文字或圖形）只要能達到效果即可，正是基于這一認識，筆者認為可以在軟件作坊模式下裁剪一套簡單而可行的工件，供團隊成員使用。

無非是要描述工作成果以達成共同理解，在軟件作坊模式下，不凡多采取表的形式來表述成果。筆者在本文所建議的工件大多是以表的形式體現成果。這里提取幾大軟件工程階段所需的工件，需求階段的敘事表、設計階段的類點卡和類序表；對于架構說明，筆者建議和開發平臺一起介紹，并就開發平臺搭建作說明；在代碼編寫階段，適當的規范是必要，但不需刻究，只需在類序表和類點卡的設計中補充說明各屬性和函數作用，以便接手者盡快切入系統；測試階段尤其是面臨第三方軟件的測試，測試文檔建議結合早前需求和第三方提供的功能和性能說明以測試用例形式表現，集成測試則采用案例測試進行。本文這里重點說明需求階段的敘事表、以及貫穿設計、代碼、維護階段的類序表和類點卡和開發平臺與架構圖說明。

為在軟件作坊模式下，為建立軟件開發人員與業務需求人員以及承接的其他軟件開發人員之間的理解和共識，可采用敘事板和敘事表形式。敘事表示意如表1敘事表。

敘事表中的字段可以任意填加所需要來補充說明以建立共同理解。優先級指該功能完成的等級，點數是指完成工作時間，一般以天為單位。這個表簡單明了地列出系統所需要完成的需求，并就需求進行等級和工作量估算，有利于業務需求人員和軟件開發人員建立理解，同時對于承接的軟件開發人員來說，功能的序列說明有利于其尋找相應的代碼實現點并盡快理解業務需求。

表1敘事表

序列號	敘事名	敘事描述	優先級	點數（估計）
1	登陸	通過id和密碼登陸	2	1

?????? 實際上，在軟件作坊模式下，外包下與軟件公司的交流還需要建立在軟件工程體系下，這里強調的是內部軟件開發人員自產系統下建立工件應用的意義。而敘事表就是建立在軟件開發人員之間以及與業務需求人員的標準工件之一。原則上就是：能夠達成理解，并可以移交，符合一定標準設計。這就是自做工件的原則，以這個原則，軟件作坊模式下的軟件開發維護團隊可以自我設計標準工件在內部流轉，并使之成為成員自覺完成工作的成果標志。工件既是工具，同時也是成果。如敘事表，表設計的字段和意義本身就是為了實現需求描述的一個工具，而其同時也是需求描述的成果。不需要另行使用需求分析方面的工具，降低學習成本，同時又能保證溝通和理解的進行。而實際上軟件工程最大的意義就在于用標準化工具產生標準化成果，這樣某人完成的成果便可以移交到另一個人去完成下步工作。而軟件作坊模式應用工件意義也正是如此，保證成員間的工作成果是可移植，相互間可理解。

確定需求后，設計上最重要的是確定架構以及實現架構所需的開發技術平臺。這個在軟件作坊模式下轉交工作尤為重要。筆者這里沒有比較現成的工件設計。但有兩點需要在這方面的工件應用上涉及：架構圖和開發平臺搭建說明。為架構建立一套可開發的平臺是必要的，同時應該給予開發平臺主要插件應用的開發說明，如工作流程開發中，jbpm的應用。需要給出簡單開發說明；如數據庫開發中hibernate的應用；又如解析XML的DLL應用。

在詳細設計和開發以及測試維護中，對于代碼需要做功能或類上的說明，這里筆者給出了兩種工件以應用。類點卡如圖1類點卡示例。類點卡主要說明所完成的功能函數及其屬性，如果有修改，則用時間表示其版本的前后。類序表主要是類之間關系及其與數據表關系的說明。類點表主要是完成類個別的說明，類序表則說明了類間關系。這兩種工件可以合在一起，目的是軟件開發人員明確代碼中類的作用及與其他類的協作關系，及與數據表的互動關系。這兩種工件設計的側重點在于不需要非直接開發的人員能夠盡快理解類關系及其具體類的功能，同時能對應起相關的表。類序表見表2類序表示例。

類名

類功能、業務方法、異常處理、安全方法、屬性或變量。 給出代碼中的類名、函數名、屬性名。

圖1類點卡示例

其他說明，如版本修改時間和修改者。

表2類序表示例

序列號	類名	控制類	協作類	數據表
1

?????? 本文立意的出發點即在于軟件作坊模式下，如何保證工作成果的可移植、可理解，而實現則在于工件的應用。至于具體工件的提出則依賴于具體軟件作坊模式下的團隊組成以及軟件工作的側重點，是維護還是開發。對電信下面的軟件部門來說，基本都屬于軟件作坊模式，設計怎樣的工件以應用應當受到重視，否則長期累積的系統爆發出問題的一天將是難以解決的。強調可理解、可移植是設計工件的前提，同時也是軟件作坊模式最大的缺陷。

總結

以上是生活随笔為你收集整理的软件作坊模式工件应用论的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。