企業資訊化與軟體工程迷思

      在IT資訊化過程中，軟體工程技術持續演化，各個行業都需要IT資訊化，資訊系統融入基於日常工作中。 在通常軟體行業的公司內資訊化往往比較健全，而非軟體行業的公司做得就相差甚遠。 非軟體行業公司在這兒，主要指非以軟體研發，電子商務網際網路為首要贏利的公司與企業。 筆者曾經看到過某個國內上市公司，內部連一個門戶Protal都沒有。整個公司內部使有QQ做為工作溝通與檔案分享工具。一些上千人的國企公司也是如此，大都缺乏資訊保安意識，協作平臺。又如一個非軟體行業公司，自行組建研發團隊做資訊系統研發。而這種情況下，缺乏熟悉對某個領域專業知識，加之業務部們對業務不精通，研發出來的系統往往流程低效。有些業務流程有問題，居然也不做知道，甚至系統中一些業務邏輯錯誤操作的情況。這也是領導者一個意識的問題，回到根本就是沒有深刻理解企業資訊化本質，以及未能從全域性來規劃資訊化，各處都是資訊孤島。反思一個非軟體行業的公司需要CIO嗎？領導資訊化意識差，更別談網際網路思維。非軟體行業公司資訊化如何做得好呢？ 大型公司一般會實施ERP，SCM。可以看到是

      在資訊系統研發過程中，這本身也是一個軟體工程過程。按高層領導的想法想快速做一個系統，而他們認識裡面往往只有開發這個過程。對於軟體測試，部署，實施完成沒有意識。總是在不斷催促下開發一個資訊系統。到最後，2個月系統開發完成。勉強投入使用，後面發現某個功能點又不能滿足需求了。系統中BUG不斷出現，沒有辦法，不斷有工程師陷入到系統BUGS修復，維護過程中。後續又想繼續做新專案時，發現人力資源完全耗在遺留專案維護中了。這樣的領導往往不知道，修改程式比開發程式所花費的時間要大得多。接著出現的就是軟體系統存在質量問題，測試過程薄弱，釋出更新效率低的症狀。想實施成熟的CMMI，但企業急功近利的情況下，完全不現實。最後演化為邊做邊改開發模式。開發工程師深受其苦，導致各類不標準，不規範的開發過程產生。專案在出現延期的跡象，但決策者不瞭解Brooks'Law：“往一個已經延誤的專案里加人力資源，只能讓那個專案更延誤”.

如何提高軟體系統質量呢？

     第一，需求階段。從軟體工程的源頭開始，需求是否充分分析，在需求不清楚的情況下，做到敏捷需求開發。很大一部分取決於業務需求分析能力。在系統設計階段，非軟體行業的公司往往缺乏，對系統分析設計深入相對較少。系統沒有經過設計就開始進入編碼過程，最後沒有系統設計任何文字留下來。從來沒有說敏捷開發，就不需要系統設計，架構設計。對於大型資訊系統，架構設計更是重要。在RUP（Rational Unified Process），統一軟體開發過程，RUP最重要的它有三大特點：1）軟體開發是一個迭代過程，2）軟體開發是由Use Case驅動的，3）軟體開發是以架構設計（Architectural Design）為中心的。在今天軟體研發過程中，審視我們能否快速的迭代就能發現很多問題，再看是否有Use Case，Use Case是否設計合理，第三是否有系統架構設計，設計是否滿足質量屬性。

     第二，系統設計階段，分析和設計（Analysis & Design）工作流將需求轉化成未來系統的設計，為系統開發一個健壯的結構並調整設計使其與實現環境相匹配，優化其效能。分析設計的結果是一個設計模型和一個可選的分析模型。設計模型是原始碼的抽象，由設計類和一些描述組成。設計類被組織成具有良好介面的設計包（Package）和設計子系統（Subsystem），而描述則體現了類的物件如何協同工作實現用例的功能。設計活動以體系結構設計為中心，體系結構由若干結構檢視來表達，結構檢視是整個設計的抽象和簡化，該檢視中省略了一些細節，使重要的特點體現得更加清晰。體系結構不僅僅是良好設計模型的承載媒介，而且在系統的開發中能提高被建立模型的質量。與建築學類似，如果軟體系統沒有一個好的架構是不可能成為成功的軟體系統的。沒有圖紙的建築地、沒有設計的造橋工程都是不可以想象的混亂世界。建築工程如是，軟體工程中亦然！架構設計是人們對一個結構內的元素及元素間關係的一種主觀對映的產物。架構設計是一系列相關的抽象模式，用於指導大型軟體系統各個方面的設計。之前寫過一些，架構相關的文章，其中有資料庫的網際網路資料庫架構設計思路，對於企業架構涉及有企業架構轉型重構與治理，企業IT架構介紹。架構設計中軟體架構風格介紹，企業級應用架構模式N-Tier多層架構，軟體架構中質量特性。網際網路行業的電子商務基礎技術架構，網際網路電商搜尋架構演化之一。我們看到巨頭公司的：

      檔案的橫向擴充套件。以Google的搜尋技術為例，檔案被分割為多個小塊並分別拷貝到多個伺服器中。這樣搜尋可並行地完成，並通過合併各個伺服器所給出的結果得到最終的搜尋結果。
      架構的橫向擴充套件。以Amazon的做法為例，事務會被切分為多個服務，每個服務使用特定伺服器實現。當事務存在瓶頸時，可在多個伺服器上覆制服務，並且每個服務由一個半自治的“雙比薩”團隊負責。

     第三，編碼階段，在敏捷開發過程，提及可以工作的軟體勝過面面俱到文件。這就意味著我們對原始碼質量要求比較高。原始碼可讀性，可維護性、可測試性尤其重要，還有效能。如何做到程式碼優雅，《The Art of Readable Code》一書已做詳細描述。一個優秀的程式設計師效率超過10/100個普遍的程式設計師。有了優質的原始碼，後續可能出現的BUGS就相對較少。所有一個大型軟體產商，他們最重要一個過程就是Code Review. 其次開發人員，需要自行編寫單元測試。在很多小公司這一塊兒完全沒有，很多人寫幾年程式設計師居然不知道單元測試，這也就是非軟體行業的環境造就的問題。也是體現專業性。之前這篇文章也談到軟體開發的專業化 ，還有有提到 靜態程式碼分析與程式碼質量安全 。

     第三，測試階段。迭代的方法，意味著在整個專案中進行測試，從而儘可能早地發現缺陷，從根本上降低了修改缺陷的成本。從全面質量管理，測試能力成熟度TMM，到全面的軟體測試。以及敏捷軟體質量保證的方法與實踐。 微軟，GOOGLE等公司把軟體測試推上更高臺階。誕生了SDET這樣職位。SDET，屬於開發和測試中間，屬於白盒測試範疇，要求發現程式碼中的問題。SDET要求人員對質量的要求很高，並且喜歡拆東西，弄明白它是怎麼工作的，而且喜歡改善它。一個SDET的最基本要求就是對質量的熱情：一定要找到所有的瑕疵從而達到完美。其次，喜歡鑽研、分析、並改善事物是成功的SDET的又一潛質。在今天移動網際網路時間，需要移動應用App測試與質量管理一， 構建移動應用測試(一)，我們需要基本的IT持續整合之質量管理，到底自動化測試做什麼，梳理流程軟體測試流程參考一，同時演化DevOps的基本原則與介紹

     第四，部署釋出階段。工作流的目的是成功的生成版本並將軟體分發給終端使用者。部署工作流描述了那些與確保軟體產品對終端使用者具有可用性相關的活動，包括：軟體打包、生成軟體本身以外的產品、安裝軟體、為使用者提供幫助。我們需要構建高效的研發與自動化運維。涉及運維，之前提及IT運維監控解決方案介紹，技術架構下的運維治理。也有移動端運維體系建設. Infrastructure As Code ，對著容器、容器編排技術進行編碼，讓“無人值守”、“智慧運維”真正成為可能。持續整合（Continuous Integration）、持續交付（Continuous Delivery）、持續運維（Continuous Operation）是DevOps的具體環節和手段，它相當於把一條純數字化鏈路上不同的參與者關聯到一起 – 無論是開發工程師還是運維工程師

整體

趨勢

     越來越多的系統正在向雲上遷移，雲就是未來。相比於大多數預製的資料中心，雲更便宜、更穩定、更安全並且更具擴充套件性。將已有的應用轉化為基於雲的應用是十分具有挑戰性的。針對傳統資料架構所設計的應用如果不做大量的程式碼重構工作，就無法在雲中很好地執行。架構即程式碼解決方案：使用容器，實現了過程的標準化和自動化，容器影響開發者的開發方式、開發習慣，“強迫”他們去思考例如無狀態的服務、業務邏輯粒度的控制、資源的彈性伸縮、應用程式碼的釋出形態、系統裡面每一個細節的可監控性等等。無伺服器架構，以更低的價格提供了靈活的計算容量，軟體定義網路，使用軟體而非硬體實現了規模擴充套件。 Conversations as a Platform（CaaP）引導人工智慧, Containers as a Service (CaaS) 引導持續交付。再到響應式程式設計宣言的出現，軟體開發專案經歷了一些重大的重構：構建自組織的團隊模式，以增量和迭代的方式構建健壯的產品，從客戶那獲得快速反饋從而通知正在進行的工作。據Gartner稱，2020年企業中無雲戰略將極為罕見。

     企業資料庫是一個巨大的依賴性生成器。由於每個獨立團隊的工作必須要和其它共享同一資料庫的團隊協作，這導致每個團隊都無法實現自治的部署。聯邦架構是單一資料庫的替代技術，它將資料分割為適合各個獨立模組或服務需求的本地資料儲存，資料的存取只能通過API方法。API正在替代中央共享資料庫，並使物聯網成為可能。使用API是軟體工程的必備技術。API應作為有具體團隊負責的產品看待，並通過聚焦於API使用者來推進和開發新的功能。
     沒有必要盡力去實現系統零故障，我們可以換一種思維。當前很多的系統都是脆弱的，雖然它們在剛上線時都是魯棒的，但是隨著時間的進展，它們變得越發地難以維護。當今系統需要的是反脆弱，並具有面對故障的能力。在發生故障時，系統應能限定損害的程度，並從故障中恢復。如何獲取反脆弱系統取決於系統測試的方法，即如何通過注入故障產生給定的執行錯誤。為達到所期望的可用性和魯棒性等級，系統需要隔離故障並從故障自動恢復。
     為具備持續整合的能力，需要一個部署流水線；為獲得持續整合所承諾的優點，需要具有一個包括產品管理、測試和運營的跨功能團隊。部署流水線依賴於自動的測試、遷移和部署過程。持續整合需要所有團隊通過程式碼庫做交流，實現針對主幹分支的持續整合。團隊應維持軟體時常處於釋出就緒的狀態，如果事實並非如此，你必須停下來並做到上述要求。只要實現了持續的部署，一旦有用的軟體增量或功能就緒，就可通過切換或轉換實現軟體的增量釋出。
     持續交付提供了必要的端到端反饋。研究顯示在半數情況下產品經理是錯的，產品規格說明中會有三分之二的特性和功能是沒有必要的。導致這些問題產生的原因在於做實驗驗證某個特性是否可以真正地解決手頭問題之前，就試圖達成具體開發特性的細節。為確保開發的解決方案能很好地適用於所需解決問題，需要通過實際的使用產生快速的反饋，這也正是精益開發和敏捷開發實踐的真正價值所在。

     我們要讓IT技術驅動業務，提升協作效率，降低運營成本，提高ROI。

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

如有想了解更多軟體研發 , 系統 IT整合 , 企業資訊化，專案管理，企業管理 等資訊，請關注我的微信訂閱號：

作者：Petter Liu
出處：http://www.cnblogs.com/wintersun/
本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段宣告，且在文章頁面明顯位置給出原文連線，否則保留追究法律責任的權利。
該文章也同時釋出在我的獨立部落格中-Petter Liu Blog。