**內部質量指的是**的可讀性， 可修改性， 複雜度（圈複雜度，函式深度), 可移植性等軟性質量。 （像bug率指的是外部質量)
軟體的內部質量只對開發者有直接影響， 對公司來說間接影響就是開發的維護成本。
為什麼程式會有這麼多偶然複雜性呢？
基本都會有這個問題， 在傳統公司，每半年會有個大版本，質量改進可以放到乙個大版本中來完成（因為大版本有完全的回歸測試）。
網際網路公司採用的快速開發，但沒有完備的單元測試和自動化測試； 都是小版本發布， 很少大版本，也就很少有完全回歸測試的機會；這些原因就導致網際網路企業的**質量往往是最差的。
原因分析
：
影響分析1. 快速開發周期，最初都是簡單設計並實現功能。(設計欠賬，但這很好，很經濟)
小版本發布（這也很好), 因為多是手工測試，導致的問題是沒有完全回歸測試的機會。
2. 後期修改邏輯時，大家也是快速修改。沒有過多去考慮**質量，很多可以改進的地方沒有及時改進. (缺乏重構的意識)。
3. 很多人修改**的原則是盡量少改**，保持已有**，通過新增新**來實現目標。
這樣的做的原因是**沒有被測試覆蓋， 好處是減少了出錯率，並減少了bug數（對應的績效也更好）。
但這樣的缺點是，**不斷引入偶然複雜性，複雜度只增不減， 專案後期維護成本不斷增加。（編碼欠賬， 本次經濟，長期可能是虧本的)。
4. **所有者經常變換，最初a編寫，後來b維護，再後來c維護。 這樣**對後續者(b,c)來說是缺少所有感的，也會缺少質量的責任感。
後面的編寫者在對老**都是堅持謹慎原則，只改一定要改的部分，多次易手後，偶然複雜被累積。
5. **內部質量一般不會納入公司績效考核，所以關心的人也會相對較少
。（投資回報率低，對個體而言).
：
改進方法1. 對於新專案，**質量可能不是最重要，快速反饋才是；
2. 對於已經存在較長，並且以後好長時間都會存在的專案，**質量很重要，質量改進，可以帶來更低的修改成本，新成員也更容易理解業務；
3. 對於老專案，後續很少修改的，或存活不會很久的專案，質量提高可能是沒有必要的。
：
1. 防止惡化，最有效的方法是引入單元測試和自動化測試，這樣任何人的修改都可以被測試到， **也可以真正做到集體所有。 但在中國這個技術要求過高了。軟體內部質量，不能產生立桿見影的效果，質量提高也需要成本，故以上只是個人的簡單看法，投資回報未必是划算。可以先只
對公共**和核心**進行單元測試
。2. 寫**的時候，
堅持「低耦合,高內聚」
，做到乙個函式乙個功能。這樣可以在修改bug和新增特性的時候做重構，這樣就可以保證你修改的部分會在這次發布中被測試到。
3. 提交**前進行code-review
, 這樣可以相互檢查並相互提高。
4. 在小版本中安插大版本（比如半年乙個)，大版本的目的就是為重構，提高內部質量，並提供完全的回歸測試（成本較高）。
5. 使用**內部質量度量工具（sourcemonitor, simon)， 並整合的持續整合環境中。
6. 把**內部質量度量納入績效考核
(最本質的保證）。
軟體開發質量管理的一些思考
pmbok裡關於質量管理主要有3個過程 制定質量管理計畫 質量保證 qa 質量控制 qc 書看了5 6次，還是發現比較抽象，難以理解。實際專案中，怎樣才幹合理的考慮各種資源制約，更好的執行質量管理呢？一般的正規流程大致例如以下 需求分析 客戶評審與確認 概要設計 內部評審 具體設計 內部評審 編碼 ...
軟體質量的一些問題
如果要分析原因的話可能有一下幾點吧 第一點，之前我們開發進行開發不論前端後端都是上來就擼 完了也不會寫單元測試 公司整個專案沒有任何一段單元測試的 以後要是重構就頭痛了 頂多就是自己對介面跑一兩次，跟別說什麼測試覆蓋率這些了，壓根就沒有，團隊成員也都沒有概念。完了就直接丟給測試跟測試說這個功能好了測...
軟體設計的一些思考
軟體設計的一些思考 從事軟體開發工作已經五年了，仔細想想，雖然做了不少專案，但是在軟體技術上，感覺始終還是進步甚微，一方面和公司的情況有關，一方面，我想，也是自己個人總結和思考不夠吧。所以，慢慢的，還是有必要對自己的一些經驗做思考和總結。為什麼只談軟體設計，不談軟體開發呢，軟體開發涉及的不僅僅是設計...