在軟體研發程序中，往往隨著為了快速滿足業務要求的壓力，用戶需求的變更，軟體代碼的增多，以及版本的迭代，團隊成員的變化等等因素，導致一個軟體專案隨著時間推移，欠的技術債會越積越多，用戶使用容易出錯，部署流程也變得復雜，
技術債務不及時還掉，就會產生“利息”，進而導致軟體復雜度呈指數級增長，代碼行越多，邏輯越復雜，技術債務就會欠的越來越多，最終到了某個臨界點的特定時刻，軟體代碼就會變得失控，沒人知道里面改動會帶來什么后果，每一次的需求修改調整，引發即使很小的代碼修改，可能由于軟體復雜度變高，都會帶來新的問題，輕則導致軟體無法正常使用，重則導致出現嚴重的問題，甚至系統崩潰無法正常使用等問題，隨著時間的累積，導致問題處理和修復耗費大量時間，
而這種失控，在實際軟體開發程序中，是一個普遍的現象，熵增定律告訴我們，孤立系統總是趨向于熵增，最終達到熵的最大狀態，也就是系統的最混亂無序狀態，熵是無序的混亂程度，也就是說世界上一切事物發展的自然傾向都是從井然有序走向混亂無序，軟體也不例外，如果不進行適度控制和優化，也必然朝著混亂的方向行進，
在實踐中，團隊技術人員通過多種辦法來提高軟體研發效能，調整軟體研發模式，以流程、方法等方式持續提高軟體質量，最終提升軟體可用性，以及用戶體驗，從筆者的過往實踐來看，比較常見的有：
1.從需求分析與輸入端控制
2.從軟體架構與設計方面提升
3. 從團隊協作與組織方面提升
4. 從軟體代碼質量與測驗方面提升
5.從研發模式與作業流程方面
6.軟體專案管理與部署發布
這篇文章，下面就以個人粗淺的理解，概要式的進行一些初步的分析，后續我們針對具體的每個方向的主題，逐步再進行詳細的探討，
需求分析與輸入端控制
需求輸入端的重要性毋庸置疑，軟體要解決用戶的什么痛點，用戶會在什么場景下使用，做什么樣的操作，來達到什么樣的效果，解決了什么樣的問題，這些要做一款軟體需要考慮的首要問題，
而對用戶真實需求的分析，做出符合產品定位并滿足用戶使用的解決方案，其中需要有很多的思考和分析，如何以高效且低成本方式做好，是值得長期研究和實踐的話題，
ToC類軟體和toB類軟體的用戶屬性不同，需求側重點不同，在做需求分析時候，做好需求分析，需求挖掘，以及需求的驗證等也都不同，
在實踐中，往往也會存在很多的偽需求，以及被忽略的隱含需求，功能性需求只是一方面，但決定軟體成敗的，往往是隱含的非功能性需求，
在進行軟體需求分析時候，需要對于功能的完整性、功能前后一致性，以及邏輯合理性等進行論證，也需要考慮到需求是否可落地實施等，
需求分析和輸入端的分析和控制，對軟體的研發時間方向起著至關重要的作用，往往多一個需求，或者一個功能流程的變化，就足以使得后續的一系列軟體流程隨之改變，在軟體需求階段，做好需求分析，需求確認，以及需求評審，是很重要的一個環節，
軟體架構與設計方面
當需求確定之后，就需要進行軟體設計了，軟體規模的大小，用戶的使用場景差異，就決定著軟體的設計方式，就一般的普通軟體系統而言，采用單體軟體、前后端分離、分布式云架構方式，采取公有云、混合云、或者私有云模式部署，都對整體軟體設計影響很大，
軟體整體架構的選擇，不僅僅需要考慮功能方面，也需要對系統的可用性、性能、可擴展性、檔案存盤、訊息處理、介面協議、通信方式等進行考慮，從基礎模式上做好設計，
一般而言，常見的軟體系統由前端UI展示層、服務應用層、業務邏輯層、資料持久化層組成，不論是單體應用，還是分布式應用，以及微服務架構，乃至一些大的云廠商設計的Serverless架構，都在解決給用戶界面呈現，業務邏輯處理，與資料持久化的問題，只是在每一層里面，有更詳細的架構設計；以及由于業務屬性或者專案某方面的特點需要，導致做了一些特殊型的架構設計，如何巧妙地讓前后端協調起來，通過完整、準確、高質量的代碼實作，從而輸出一個穩定高效的軟體，是在設計方面值得下功夫去做的事情，并且值得持續演進和更新，架構設計是一個不斷演進的程序，也是一個產品長期演進和迭代程序中繞不開的必由之路，
實踐作業中，我們做的業務軟體系統，也需要隨著用戶需求的驅動，不斷進行技術選型的修改，軟體架構設計的優化，持續不斷地優化和調整，我們學習一些業界開源的經典軟體架構設計，會有一定幫助，比如下面這幾個：
Linux系統架構：
（上圖參考：https://retrage.github.io/img/lkl-architecture.png）
Openstack架構設計：
（上圖參考：https://object-storage-ca-ymq-1.vexxhost.net/swift/v1/6e4619c416ff4bd19e1c087f27a43eea/www-assets-prod/openstack-map/openstack-map-v20221001.jpg）
Kubernetes架構設計:
（上圖參考：https://raw.githubusercontent.com/kubernetes/kubernetes/release-1.2/docs/design/architecture.png）
一些開源的經典軟體設計很巧妙，在實際的軟體設計中，可以給我們很多啟發，在實踐中可以參考學習借鑒，以便少走很多彎路，
團隊協作與組織模式
當需求與軟體基本設計確定之后，團隊的協同與組織模型就進行相關協作與作業開展，基于一些常用的協作工具，如Jira、Redmine、Tapd、Worktile、Teambition、禪道、飛書之類進行產品需求、作業事務、專案進度、task、bug與軟體質量等的管理與跟蹤，大部分的工具現在都提供了對于任務優先級設定，人員、時間等的，可以根據自己團隊的時間選擇取用，各種工具皆有自己的優劣勢，選取一種作為團隊的標準化工具，再逐步優化和改善，目標是能夠實作資訊共享與同步，方便團隊協同，提高效率就可以，
軟體代碼質量與測驗
在人月神話中提到，軟體開發作業沒有銀彈，不為系統測驗安排足夠的時間簡直就是一場災難，由于軟體工程在實際中的復雜性，需要做好合理的時間規劃，并且需要注意風險，在實際的專案開活動中，前期未為測驗分配足夠的時間，就會導致大多數專案在后期長期維護修復，反復掙扎，導致實際上測驗花費了進度中超過一半的時間，軟體工程中進度計劃方面，典型的經驗是為1/3計劃、1/6編碼、1/4部件測驗以及1/4系統測驗，
在專案實踐中，許多專案在系統測驗之前還能保持進度，在進入系統測驗之后，就會陷入泥潭，時間不可控，因為專案為測驗預留時間較少，測驗介入較晚，在專案快完成的時候才開始啟動測驗，直到專案的發布日期，人們才會發現進度上存在問題，還有很多復雜的問題沒有處理完成，給測驗預留的時間不足，就會在專案快完成接近發布日的時候面臨延期的窘境，就軟體而言，實際往往需要經過數輪測驗，才能使得一個軟體能夠功能可用，而要達到好用，更是需要持續地精雕細琢，經歷更漫長的測驗，多輪的實踐，所以業界也有說法，好的軟體是不斷測驗之后才優化打磨出來的，所謂“不經一番寒徹骨，怎得梅花撲鼻香”，只有持續的深入細節測驗和優化，不斷打磨，才能使得軟體能用，直到最終好用、易用，
研發模式與作業流程
所謂”工欲善其事必先利其器”，選擇合適的開發工具與模式，會對實際的效率提升有很大幫助，首先建議團隊之間采用相同的標準SDK版本，相同的IDE版本，相同的專案管理工具與構建工具，節省一些由于版本差異導致的轉換等成本，其次，敏捷開發模式已經盛行多年，基于敏捷模式的快速迭代作業，采取小步快跑，小版本迭代，快速發布，循序漸進的模式，這種主流普遍的研發模式，團隊之間快速協作，更早的驗證軟體小功能，每一個Sprint都有對應的輸出，迭代式、增量交付，能夠讓團隊整體實作更高效的協作，以及最高效的交付，
專案管理與部署交付
在實際專案運行中，即使采取敏捷方式，基本的需求分析，編碼與單元測驗，集成與系統驗收測驗等關鍵環節也是必不可少的，而專案管理方面，就需要做好內外部的資源與時間等各方面的協調作業，控制好風險，確保團隊的進度滿足，整體進展與原計劃之間是匹配的，
軟體的部署與交付，是整體相對靠后的一個重要環節，通過持續集成結合持續交付與持續部署的方式，讓一切自動化起來，讓開發、測驗人員專注與業務的實作與測驗，讓代碼構建到發布的程序自動運行，采取流水線式自動部署，讓專案從代碼提交，代碼質量掃描、單元測驗、build構建，自動化測驗，自動化發布，并完成自動化部署，代碼提交即可觸發構建到發布的程序，實作全程無人值守即可完成，
把能固化的流程性作業交給工具，降低人工操作，可以減少錯誤，也可以提高效率，用程式測驗程式，用程式呼叫程式，用程式管理程式，從而提升整個發布與研發的運轉效率，
總體而言，軟體的研發、交付，也是個系統性的工程，只有快速地回應變化，持續提高效率，才能實作更好的結果，一些GTD工具、好的專案管理工具，一個小腳本，也會帶來效能方面的提升，培養好的習慣，養成良好的規范化標準對工程師而言很重要，
小結
本文很簡要地從幾個方面討論了一些效能提升的要點，在軟體研發實踐中，效能提升也不止上面幾點，而且以上提到的幾個方面也有更深入的細節，后續我們繼續分享交流，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/541149.html
標籤：架構設計