評審目標、評審清單、架構設計、**管理、日誌治理、日誌規範、配置規範、變更控制、配置審查
大部分的軟體開發最終在工程領域體現出來的是應用開發，涉及到前端應用，後端應用或者無線應用，如何將應用開發的過程抽象出來，盤點出核心環節，才能更好的把控應用開發的節奏，本文列出應用開發的全貌，試圖掃除應用開發過程的盲區，以此作為理論基礎指導應用開發出健壯高可用的軟體系統。
總的來說，需求評審就是乙個統一目標，明確需求，確定實現過程的會議。在需求會議上，產品經理需要跟大家明確需要解決的痛點問題，有哪些功能以及對應的計畫，然後大家在會議上挑刺，討論，甚至是撕逼，最終全體成員達成一致意見後開始開幹。所以，通常一些專案需求都是要經過幾次評審會才能完成的。
在正式的需求審查中，開發團隊應引導客戶完成系統需求，並解釋每個需求的含義。審核小組應檢查每個需求的一致性，並應整體檢查需求的完整性。審閱者需要做出如下檢查：
評審人員應指出需求中的衝突，矛盾，錯誤和遺漏，並正式記錄在評審報告中。然後由使用者，系統使用者和系統開發人員來協商這些已確定問題的解決方案。
介面規範，冪等，事務，重試，限流，降級，熔斷
係分設計
係分評審
具體參考《分布式架構》
**管理模組羅列出**治理的主要框架，具體可以參考《**三部曲》
日誌作用
日誌準則
日誌目標日誌分類
日誌**
日誌格式
常用日誌包含的必選字段：
可選字段：
關於日誌格式的定義，我們應當遵循以下的原則：
日誌檔案
不同業務範疇的日誌要有清晰的命名，才可以快速定位日誌資料，同時可以支撐日誌自動化分析。日誌檔案主要是命名規則的統一，和檔案的分類。
應用日誌：
中介軟體日誌：
日誌目錄
通常的日誌目錄會分為應用目錄，中介軟體目錄，系統目錄，具體目錄名稱可以用正規表示式來定義。
日誌級別
日誌級別是我們最熟悉不過的，按照對系統影響的嚴重程度從高到低排一次如下：
開發人員需要使用的資訊：debug級等
運維人員需要知道的資訊：error級等
系統使用人員需要知道的資訊：日誌的輸出和反饋等
系統審計人員需要知道的資訊：關鍵業務info級日誌
日誌規範管理原則
日誌框架
日誌記錄框架是專門用於標準化應用程式日誌記錄過程的實用程式，進而演化為框架。
框架選型：
框架對比：
日誌採集
日誌的採集業界有facebook的scribe、apache的chukwa、linkedin的kafka、cloudera的flume等；阿里有tt，tlog，xflush, logtail等，產品比較豐富的。從採集方式來分, 有推和拉兩種方式, 拉的方式以tlog為代表
日誌傳輸
日誌儲存
日誌儲存介質通常為文字型別或二進位制型別，可以分為以下的載體：
日誌檢索
日誌查詢有賴於清晰的日誌路徑，合理的日誌檔案命名，還有核心的日誌格式規範，在此基礎上才能做到高效的日誌檢索。通常我們對日誌檢索分為人工查詢和工具自動檢索，人工查詢根據不同的業務，查詢對應的日誌檔案，通過命令指令碼進行查詢，而工具自動化檢索則可以匹配目標日誌關鍵資訊，大大提公升檢索效率。
指令碼查詢的工具如下：
封裝指令碼的查詢工具：
中介軟體日誌查詢工具：
日誌分析
隨著雲技術的普及，日誌分析領域基本也被各大雲廠商瓜分，上來上節提到的日誌查詢工具，現階段廠商都提供了一站式的日誌一條龍解決方案，比如阿里雲的sls或者ekl都是優秀的產品。
日誌清理
通常日誌檔案都有生命週期，不同業務領域對日誌資料的持久化時間也各不一樣，所有對不同型別日誌指定不同的日誌清除策略，對應持久保留的日誌可以對接冷備檔案系統，如oss提供的服務。
軟體配置管理是軟體質量改進的核心環節。它貫穿於整個軟體生命週期，主要目標是在減少錯誤的情況下提高生產率。
根據維基百科的定義，軟體配置管理（software configuration management，簡稱：scm），又稱軟體形態管理、或軟體建構管理，簡稱軟體形管。界定軟體的組成專案，對每個專案變更進行管控（版本控制），並維護不同專案之間的版本關係，以使軟體在開發過程中任一時間的內容都可以被追溯，包括某幾個具有重要意義的數個組合，例如某一次交付給客戶的軟體內容。
實施軟體配置管理系統的主要原因是：
配置標識
配置標識是確定軟體系統範圍的一種方法，在此過程包含的步驟如下：
基線基準是軟體配置專案的正式版本，只能通過正式的變更控制程式進行變更：
變更控制
變更控制是一種過程方法，可確保在配置物件中進行變更時確保質量和一致性。在此步驟中，變更的請求將提交給軟體配置管理器
配置狀態
配置審查
軟體配置審核將驗證所有軟體產品均滿足基線需求：
應用程式開發是設計，構建和實施軟體應用程式的過程。這可以由擁有大型團隊從事專案的大型組織來完成，也可以由乙個自由開發人員來完成。應用程式開發定義了應用程式的製作過程，通常遵循一種標準方法。如何完成應用程式開發有很多因素。所以必須考慮專案的規模，需求的具體程度，客戶要更改多少東西，開發團隊的規模，開發團隊的經驗以及專案的截止日期等因素，本章我們聚焦的是應用開發本身的內容，後續章節我們將介紹構建部署、軟體測試、發布管理以及監控告警整個應用開發生命週期的整一套方**。
BREW 應用的開發流程
為了開發的方便，乙個基於brew的移動增值業務一般要先開發它的模擬器版本，在模擬器上調測之後，再通過交叉編譯器將 編譯成在目標手機上執行的目標 並完成在手機上的測試。下面以visual c 6.0的整合開發環境為例，基於visual studio 2003或者以上的ide版本的開發流程與之類似。1 ...
Web應用開發流程
市場分析 軟體設計 偏功能性 產品型或專案型 以下是產品型 軟體詳細設計 詳細到每個功能點.研發階段 研發階段性報告 週報 月報 季報 測試階段 測試分類 白盒 指的是邏輯性測試.修改階段 內測階段 市場反饋報告 正式上線 軟體運維文件 以下是專案型 需求討論階段 設計階段 軟體詳細設計 詳細到每個...
ios 應用 開發流程。。。
1,業務 介面 2,網路請求，model設計，介面設計，切圖 4,資料解析 5,前台顯示 業務介面 一般是 webservice,返回的資料型別 是json或者 xml,而網路請求 會用到afnetworking model設計，一般是肥點的model,model負責解析 資料，介面設計，這邊可能會...