rup的過程改進，倡導針對不同型別專案進行適當的裁剪，實際上這也是一種靈活適應的方式、隨需而變的思想。我對此是理解並贊同的，但是我對rup卻一直保持一種相對謹慎的態度。
對於rup來說，首先，我認為它過於理想化和理論化，rup 是過程元件、方法以及技術的框架，你可以將其應用於任何特定的軟體專案，由使用者自己限定 rup 的使用範圍。對於各種型別的軟體專案，rup並未給出具體的自身裁減及實施策略，總有些無依據可循的感覺。你既可以說它能解決任何問題，也可以說它什麼都不是；其次，rup從本質來說還是乙個強調設計和規範的軟體方法，從這個角度來講，與傳統的瀑布模型沒有太大差別，它的靈活性較之敏捷方法還是相對較弱的。在一些小型軟體專案、特別是不可**的軟體專案開發中，面臨著各種緊急需求、面臨著時間壓力，沿用rup是很難應付自如的。但是在另一方面，rup強調對知識的收集、整理和加工定義，強調在軟體開發的時候要有好的體系結構。所以它還是很有利於知識的積累和共享的。
相比rup ，敏捷方法如xp則更為靈活，倡導盡早的、持續的交付有價值的軟體滿足使用者需要。用交流溝通取代詳盡的文件，強調團隊的主動、自律、自我組織和自發管理。而xp也是以**為核心的一種方法，這裡有很多的東西是未知的，知識只存在於兩個地方：開發者的頭腦和最後的**。對於專案管理者來說，他們會認為敏捷開發方法弱化了知識管理的概念，而實際上敏捷開發注重的是最有價值的知識的積累和沉澱。
如何靈活應對各種專案風險、如何最大化優先滿足使用者價值、又如何能夠有效的控制專案開發過程、如果做好專案過程中的知識管理，是每乙個軟體專案管理者都需要深入思考的問題。rup的倡導者一直強調rup裁剪，實際上我認為rup不僅僅是需要自身的裁剪，還需要學會融合。在rup裁剪的同時，適宜的融合敏捷開發的各種實踐。不要認為rup與xp是矛盾的，其實不然，它們具有不同的原理、具有不同的應用領域。在 rup 中融合了 xp 技術時，才會得到過程的正確量，既滿足了專案所有成員的需要，又解決了所有主要的專案風險問題。對於乙個工作於高信任環境中的小型專案團隊，其中使用者是團隊的一部分，那麼 xp 完全可以勝任。對於團隊越來越分散，**量越來越大，或者構架沒有很好定義的情況，您需要做一些其他工作。在使用者互動具有"契約"風格的專案中，僅有 xp 是不夠的。rup 是乙個框架，可以從 rup 出發，在必要時以一組更健壯的技術來擴充套件 xp。
rup最佳實踐包括：
1． 迭代開發: rup的開發過程建立在一系列迭代之上，每次迭代都有乙個固定的時間限制（例如四個星期），稱為"時間盒"，每次迭代結束的時候都發布乙個穩定的小版本，該版本是最終系統的子集。"時間盒"是迭代開發中的關鍵概念：它意味著迭代週期的期限是固定的，如果目標沒有完成，則放棄本次迭代的需求，而不是延長迭代的時間。
2． 管理需求
3． 使用基於元件的構架
4． 可視建模
5． 持續的質量驗證
6． 控制變更
關於rup階段的乙個簡潔和準確的描述：
1.初始－開發系統的業務用例；要求探索少量但是重要的需求（大約10%），以便獲得範圍、關鍵風險的尺度，並且決定是否進入細化階段。
2.細化－迭代地構建核心體系結構和解決技術風險。構建體系結構意味著真正的程式設計、整合及測試-這不是紙上談兵或者丟棄原型。細化階段，我們需要迭代地詳細地探索大部分需求（大約80%），同時實現系統的核心風險部分。在整個細化階段需求都可能是變化的，通過不斷的"反饋－適應"迴圈，評估已實現的部分。
可以看到，這與傳統的瀑布風格的需求定義不同，其大部分需求是在開發核心體系結構的同時細化得到的，並且其從實際的開發中得到反饋。我們也能夠以此為據來決定是否繼續此專案。
3.構造－迭代地構建細化階段沒有做的元素；迭代地整合和進行質量保證；準備部署。由於大部分需求的不穩定性已經在細化階段澄清，所以在構造階段需求的變化較少。
4. 發布－完成&beta測試，確定版本，部署系統。rup規則推薦"迭代週期的長度是2－6周"。 迭代開發和rup的本質是採取小步驟，對於可能不完美的實現，迅速整合，質量保證，測試，及時獲得反饋，然後根據反饋，調整需求、設計和實現。小步驟、反饋和調整是核心概念。
迭代方法允許我們邊學邊走；隨著迭代的進行，我們得到越來越多的真實的需求，更加客觀的風險，以及完成該項目的更加準確的能力估計。簡言之，經驗使我們成為更好的計畫者。
12 個 xp 實踐包括：
小版本：以小的增量版本經常向客戶發布軟體
隱喻：隱喻是乙個簡單、共享的"故事"或描述，說明系統如何工作
簡單設計：通過保持**簡單從而保證設計簡單。不斷的在**中尋找複雜點並且立刻進行移除
測試驅動開發：使用者編寫測試內容以對"故事"進行測試。程式設計師編寫測試內容來發現**中的任何問題。在編寫**前先編寫測試內容
重構：這是一項簡化技術，用來移除**中的重複內容和複雜之處
結對程式設計：團隊中的兩個成員使用同一臺計算機開發所有的**。乙個人編寫**或者驅動，另乙個人同時審查**的正確性和可理解性
集體**所有權：任何人都擁有所有的**。這就意味這每個人都可以在任何時候變更任何**
持續整合：每天多次建立和整合系統，只要任何實現任務完成就要進行
每週 40 個小時：程式設計師在疲勞時無法保證最高效率。連續兩周加班是絕對不允許的
現場客戶：一名真實的客戶全時工作於開發環境中，幫助定義系統、編寫測試內容並回答問題
編碼標準：程式設計師採用一致的編碼標準證
rup與xp的融合，是各自特點的相互補充，也是軟體開發方法的平衡之道。而對軟體技術平衡的思考也可以說是技術成熟的開始吧。
最後，再闡明我對軟體專案開發的理解。在軟體專案開發過程中，應該能夠識別、分析不同軟體專案的特點，採用相對適合的開發實踐來適應軟體開發過程，保證對軟體開發的有效支援，以便能夠創造出&ldquo足夠好的&rdquo軟體。而這個足夠就是對進度、成本、質量之間的平衡，最大化滿足客戶需要的實現。
vector list 和deque的優缺點
vector表示一段連續的記憶體區域，隨機訪問效率很高，因為每次訪問離起始處的位移都是固定的，但是在隨意位置插入刪除元素效率很低，因為它需要將後面的元素複製一遍。list表示非連續的記憶體區域，並通過一對指向首尾元素的指標雙向鏈結起來，從而允許向前和向後兩個方向進行遍歷。在list的任意位置插入和刪...
Apache和Nginx的優缺點
nginx相對於apache的優點 1 輕量級，同樣起web 服務，比apache占用更少的記憶體及資源 2 抗併發，nginx 處理請求是非同步非阻塞的，而apache 則是阻塞型的，在高併發下nginx 3 能保持低資源低消耗高效能 4 高度模組化的設計，編寫模組相對簡單 5 社群活躍，各種高效...
SVN和Git的優缺點
svn的優點 1 採用集中式，易於管理，保證安全性 2 管理方便，邏輯明確，理念符合常規思維 3 的一致性高 4 適合人數不多的專案開發 5 允許乙個檔案有任意多的可命名屬性，會關注所有的檔案型別 6 支援二進位制檔案，更容易處理大檔案 7 支援空目錄。svn的缺點 1 伺服器壓力太大，資料庫容量暴...