a class should do one thing and do it well! 這是物件導向分析設計裡的乙個基本原則，因為只有小而精的類才易於被重用，大而全的類只適用於乙個特定的系統，很難被重用。而在流程改進時，我建議的原則是每一次改動盡量只針對某乙個過程領域，取得效果後再逐步進行後續的改變，一下子改變太多的話就較難達到預定的目標。因為我們平時所說的流程改進，目的都是要改變人們現有的工作習慣，以獲得更高的工作效率和產品質量。正應為這是一種變化，通常會遭到受眾的阻力，因為採用原來的工作方式，儘管有這樣或那樣的問題，軟體最終也被開發出來了，為什麼要改變呢？而且專案的正常開發任務也是非常繁重的，專案團隊一方面既希望能夠採用一些更好的工作方式來提高工作效率，但是另一方面又擔心這方面的變動會占用他們太多的精力時間去學習和適應。正因為如此，如果每次變動的步伐小一些，學習掌握的難度就比較低，在盡量不影響開發團隊正常工作的情況下來進行流程改進；當大家都能夠感受到當前階段的改進效果的時候，他們對於新的改進建議的牴觸就會逐漸降低，而改革的信心卻在逐漸增加，從而更加有利於開展下一階段的改進工作。
實際工作中，我們可以從乙個簡單的工作環節入手來改進開發工作，如：做好單元測試、改用用例方式來描述需求、採用迭代化的方法來制定專案開發計畫等等。以基於cmmi模型的流程改進為例，cmmi模型有兩種表述形式：階段式和連續式。實際上連續式表述更加附合流程改進的實際規律，開發團隊可以選擇自己最為薄弱的環節（過程域）來進行改進，而不是同時在多個開發環節（階段式表述針對每乙個階段所推薦的一組過程域）中同時進行改進，這樣效果可能更好一些。
而且在實際工作中，我們要避免流程文件化的傾向，很多軟體企業制定了非常完善的流程規範，但是卻從來沒有考慮過這些規範在實際專案中的可操作性。我看到過好幾個軟體企業制定了很多的度量指標，但是這些指標在實際專案中卻從來沒有被認真執行過，專案經理被「要求」在專案過程中收集並監控這些指標，很多指標只是為了填寫專案匯報而進行估計，專案經理並不了解這些指針對專案的實際指導意義。如果是這樣的話，倒還不如僅統計一些專案經理能夠理解，並且對專案計畫有直接指導意義的指標更為有意義。因為流程不應該只是乙個規範性的文件，流程應該是在每乙個專案中被切實執行的工作方法。
還是 push 比較好
以前在 js 中往乙個陣列裡 放數 用的是 a i i 的形式，就像這樣 var testarray new array for var i 1 i m i 這樣寫可能會引起問題，看似 testarray 0 沒有被賦值，但是此時賦值完畢以後你會發現 testarray.length 的值為 m 1...
AsyncTask 比較好的解釋
package com.example.asynctask import android.os.asynctask import android.widget.progressbar import android.widget.textview 生成該類的物件，並呼叫execute方法之後 首先執行...
mysql 日誌比較好 MySQL日誌比較
1 mysql日誌比較 日誌檔案 檔案中的資訊 作用錯誤日誌 記錄啟動 執行或停止mysqld時出現的問題。系統故障時定位故障原因 查詢日誌 記錄建立的客戶端連線和執行的語句。記錄資料庫發生的所有操作 二進位制日誌 記錄所有更改資料的語句。資料庫資料備份和複製 慢日誌記錄所有執行時間超過long q...