軟體開發中的一些疑惑和探讨

         我們今天聊一聊我們軟體開發中遇到的一些困惑和疑慮，一起探讨下其背後的深層次原因。

        做開發也許有好多年了，我們每次看到高端的架構思想方法時，總覺得沒有和應用很好的結合起來，我們就會起了懷疑，到底是架構設計實踐不夠，還是對各種實作的分析和思考太少了？其實，我們缺少的不但但是架構的實踐，還有不同場景的實踐，例如我們可能平時做企業應用架構，流量少，沒什麼資料，複雜的地方全在業務邏輯上，這個時候我們講大資料、高并發就很難帶入場景裡，還有一些架構，不自己搭一遍是很難了解其中的優缺點的。是以我們有機會要自己把看到的一些好的架構用原型搭一遍，造出一些資料，用工具模拟壓測一下，也許feeling就出來了。有的時候迫切的業務需求會促使我們更去跟實際應用相結合。

       正規的軟體開發流程，一般設計的規範文檔有哪些呢，作用又是什麼？對于瀑布模型，每個階段結束後都有對應的驗收文檔，靈活開發是根據項目需要寫必要的文檔。有些團隊在測試階段，有測試用例文檔、測試驗收報告，釋出前還有部署文檔、維護手冊，但是在靈活開發中這些都被自動化測試工具、部署腳本等替代了。是以我們總結必要的文檔，有設計類文檔，用來記錄需求設計、架構設計等評審，說明類文檔，用來規範API、配置、操作等，便于規範和統一，報告類文檔，用來驗收、故障、調研等。

      針對軟體外包問題，考慮人員水準參差不齊，穩定性差，我們需要考慮優先項目穩定、低成本運作，業餘可以考慮做一些新項目，甚至開源項目來提升自己的技能，當然我們在項目選型開源項目時要考慮開源項目代碼品質、有無測試、文檔的健全度、Issue的處理情況，最後更新時間、Star數量，google和stackoverflow的使用問答情況。

      對于技術選型，我們需要考慮技術可行性和風險是否可控，我的原則基本是成熟的好過新酷的、流行的好多小衆的、團隊熟悉的好過陌生的、簡單的好過複雜的、開源的好過商業的。

      關于項目架構重構問題，我們首先需要寫一部分自動化測試代碼，保證重構後這些測試代碼能夠幫助我們檢測出來問題，也就是測試驅動，然後在重構子產品的時候，老的代碼需要保留，用一些開關來回自如切換新舊代碼，自動化測試通過後再部署測試，完全沒問題了可以考慮删除舊代碼。

     網際網路架構和企業應用架構的差別和聯系；企業架構疊代快，使用者規模大，業務相對單一；企業應用通常業務比較複雜，針對特定行業結合，使用者規模要小，這些特點，都會影響架構設計的選擇。