人月神話 - 讀書心得

1. 焦油坑

• 軟體系統產品 - 大部分軟體工程企圖要做出來的東西
• 調適自己習於追求完美是學習軟體工程最困難的部分
• 你得先把工作做成功，才會得到越多實質上的權力
• 我們所倚賴的技術基礎是不斷地在進步，當設計完成的那一剎那，從該設計所代表的概念來看，它就已經落伍了

2. 人月神話

• 時程預估技術還非常不成熟，這些不成熟的技術背後都反映出一個假設，"一切都會進行得很順利"
• 預估技術誤把工作量和專案進度混為一談，"以為人力和工時可以互換"
• 以為"每項工作都將只會耗費掉它「理應」耗費的時間
• 用人月來衡量工作規模的大小是危險的，也是一個容易遭到誤解的迷思
• 只有當工作可被切分，而且投入工作的人彼此不用溝通，人力和工時的互換才算成立
• 分配足夠的時間給系統測試是非常重要的
• 在一個時程已經落後的軟體專案中增加人手，只會讓它更加落後
• 軟體專案會耗費多少時間是看它有多少連續性的限制，該投入多少人力是看它可以切分成多少獨立的子工作

3. 外科手術團隊

• 生產力最好和最差的比率平均大約是10:1，經驗和表現好壞之間並沒有任何關聯
• 參與合作的人數會影響投入的成本，你最好盡可能用最少的人來完成專案
• 短小精悍團隊的問題出來了：開發真正大的系統就太慢了
• 要同時兼顧工作效率與概念整體性，這實在是兩難
• Harlan Mills建議大系統中的每個個小部分都分別交由一個團隊來負責，而各個團隊則被組織成外科手術團隊
• 外科醫生 - 首席程式設計師 (副手是出主意、參與討論、評估)
• 傳統團隊裡的成員而言，他們的地位都是對等的，所以因決策的衝突而必須進行溝通和妥協是不可避免的
• 外科手術團隊不切割問題、主從關係
• 就一個200人參與的專案而言，只要那20個外科醫生能一起合作的話就行
• 由一位系統架構設計師由上到下進行全部的設計

4. 專制、民主與系統設計在系統設計時，保有概念整體性是最重要的原則

• 只有當功能增強所節省下來的時間超過學習、記憶和查閱手冊所耗費的時間，電腦的使用便利性才會提升
• 功能概念複雜度比才是系統設計的最終測試標準，好的設計既不可單獨偏重功能性，也不可只偏重簡單性
• 設計人員總是以功能性來評判系統的優劣，而非簡單性
• 若只提供基本功能和組合這些功能的規則，還稱不上是簡單便利，你必須讓使用者養成固定的使用習慣，也就是為這些功能提供一整套同一系列的操作方式
• 架構旨在說明做什麼，實作則是說明如何做
• 使用便利性的好壞是基於系統的概念整體性
• 產品的成本效能比是非常仰賴實作人員才能夠提升的，這跟使用便利性得仰賴架構設計師的道理是一樣的
• 約束對藝術而言是件好事
• 要達成概念整體性，真的是有賴於讓系統反映出單一的理念

5. 第二系統效應

• 第二個系統是最危險的系統
• 一般來說，第二系統都傾向於過度設計

6. 意念的傳達

• 將修改的程予以量化(quantize)是很重要的
• 架構設計師都必須隨時準備好提出一種實作方式供人參考，但不應該企圖硬性規定採用特定的實作方式
• 開會絕對是必要的
• 將最後的決定權明確授權給首席系統架構設計師，使妥協和延宕得以避免
• 配合錯誤的實作來修改規格將會耗費更多的時間和成本，還不如乖乖按照規格來修正實作
• 如果有何任不清楚的地方，我們希望實作人員都應該打電話向負責的架構設計師詢問，而不要妄加猜測或自行解釋
• 解釋架構上的效力，所以應該公告讓所有人知曉

7. 巴別塔為什麼失敗？

• 人與人不能彼此交談，就無法合作，當合作失敗，工作就陷入停頓
• 良好的電話聯繫制度並明確定義出團隊之間的從屬關係
• 例行的專案會議
• 專案工作手冊
• 組織的目的便在於減少溝通介面和協調的需要量，所以組織就是為了上述的溝通問題而存在的 - 透過人力配置和專案分工來減少溝通量
• 樹狀結構的組織是源自於權力和責任的結構，在任何人都不能同時聽命於兩個老闆的原則之下，造成了權力結構成為樹狀的樣子
• 溝通結構是網狀的
• 管理者 - 技術總監
• 組織必須視現有人力的特性來調配，而不是叫人去配合一個純屬理論的組織
  
• 管理者和技術總監必須給人感覺對主要技術的看法是一致的，重要的技術問題應該在私下場合進行溝通，在他們取得共識之前，管理者必須尊重技術總監在技術上的權威

8. 預估

• 如果採用了合適的高階語言，軟體開發的生產力也許可以提升到五倍
• 寫一個獨立的小程式所花的時間不能拿來做為預估整個軟體系統產品的開發時程之用
• 費力程度 = 常數 x 指令數量 ^ 1.5

9. 地盡其利，物盡其用

• 五磅麻袋裝十磅東西，其隱喻就是在資源不是無限取用的情況下，必須「地盡其利，物盡其用」
• 鼓吹系統的整體觀與使用者導向的態度，也許是軟體管理者最重要的職責
• 管理者可以做兩件事情，第一件就是確保大家的本事是真正透過程式設計的技術訓練而來，而不是憑個人的天賦或過去的經驗，第二件是認知到寫程式有它專業的技術，組件是要去創造才有的
• 每一個函式都應該至少包括兩套程式碼，一套是執行進度最快的，一套是使用空間最少的
• 資料的呈現方式是程式設計的本質

10. 文件假說

• 電腦的操作手冊與性能描述，這是開發任何一項新產品時所必須優先準備的文件之一，並且也是最後完成的文件
• 大部分的管理工作總是由成堆文件中的某一小部分具體呈現出來
• 只有把事情真正寫下來，遺漏和矛盾之處才會顯露出來，也唯有把「寫」這個動作確實做出來，才能導引出更多細節的決定(mini-decision)，那正是從模糊不清之中理出清晰而明確正策的具體方法
• 管理者的基本工作就是要保持組織裡每一個人都朝同一個方向前進，所以他每天的主要工作就是溝通，而非做決定，寫文件就大大減輕他的溝通負擔
• 傾聽、報告、引導、訓勉、商議、激勵

11. 失敗為成功之母

• 所有開發大型軟體系統的經驗都顯示，丟掉重做總有一天會做成功的
• 把必然的一次失敗納入正式計畫之中
• 定義一個底限是必要的，而且隨著專案進行，這項限制應該要越來越嚴格
• 唯一不變的就是變，認清到這個事實，將有助於你面對改變
• 不只是目標會改變，軟體開發的策略和技術也一樣會改變，丟掉重做的概念本身就是要讓你接受先學到竅門、然後改變設計
• 表格驅動技術 (table-driven)、高階語言、自我說明技術(self-documenting)
• 要形成一個利於改變 組織，比設計一個利於改變的系統還要難
• 為什麼無法將錯誤一次修正 1. 除非軟體結構非常單純，或是文件寫得非常好，否則往往只是治標而沒有真正治本。2. 負責修改錯誤的人通常不是程式原作者，而是菜鳥或新手
• 軟體維護必須搭配比一般發展時更多的系統測試
• 任何修改的動作都有破壞原有軟體結構的傾向，並且會增加系統的紊亂程度
• 任何事物總是在開始的時候最完美
• 若說軟體開發是一個簡單化而逐漸趨於穩定的過程，那麼軟體維護則是複雜化且逐漸趨於混亂的過程，即使有很好的技巧，頂多也只能減緩這種趨勢，軟體終究會走到落伍，再也無法修改的那一天

12. 神兵利器

• 使用高階語言
• 交談式程式編寫
• 除錯是編寫程式過程中最難也最耗時的部分，而漫長的回覆時間又是除錯過程中最要命的部分

13. 化整為零

• 最致命也最棘手的錯誤莫過於系統錯誤，這肇因於各個組件的開發人員做出了彼此不協調的假設
• 把產品定義清楚是非常關鍵的工作，有太多太多的失敗都源自於自始至終都搞不清楚要做的是什麼東西
• 開發人員不適合規格審查
• 開發人員 - 他們就算是看不懂規格也不會告訴你的，他們會隨著個人的喜好自行解釋
• 系統除錯所耗費的時間將超乎你的預期

14. 釀成大災難

• 為什麼專案會落後一年？ 因為每次落後一天
• 老闆想要知道真相有兩個方法：第一個方法是降低角色的衝突以鼓勵據實回報；另一個方法是審查制度

15. 一體兩面

• 我們無法主宰我們不了解的東西
• 每個程式使用者都需要一份淺顯的程式說明
• 好的做法是先求淺顯但涵蓋面廣泛，再逐漸深入解釋細節
• 流程圖中的方框符號所代表的涵義跟高階語言的功能相同，可用來將低階的機器語言集合起來，成為較易理解的段落
• 一個有條理的高階語言本身就具備了良好的分段，如果每一行程式都要用一個方框來表示，將會使文件過於冗長，還會佔據大量的空間
• 嘗試同步維護不同的文件是件愚蠢的事，對於同一件事物的相關資訊，應該盡可能統一放在同一份文件中比較好
• 自我說明的做法是來自於使用高階語言的刺激

16. 沒有銀彈：軟體工程的本質性與附屬性工作

• 在制定軟體需求時，採用多次反覆的方式，並把快速原型製作納入所規劃的每個反覆之中
• 讓軟體像生物一樣地發育成長，在系統持續被執行、被使用、被測試的過程中，逐步擴充功能
• 持續尋覓並培養年輕一代偉大的概念設計人員
• 對於一個軟體實體所做的描述，若將其複雜性抽離，結果往往也連帶抽離了他的本質
• 因為複雜性，使開發團隊成員溝通困難，進而導致了產品的瑕疵、成本的超支、時程的落後
• 複雜性造成了學習與理解上的巨大負擔，使人員的異動形同是個災難
• 所謂抽象資料型別，其概念就是一個物件的型別應該由一個名稱、一組適當的值和一組適當的操作方式來定義，而不是以它儲存的結構來定義，這部分應該是要被隱藏

19. 人月神話二十年

• 設計時必須靠許多人的構想共同來完成，但成果又必須讓使用者感覺到其概念是前後連貫的一套心智模式
• 架構設計師也形同使用者的代理人，在功能、效能、程式大小、成本和時程之間總是衝突的情況之下，他得綜觀全局，站在維護使用者利益的角度上做出取捨
• 架構設計師就像是導演，而經理就像是製作人
• 切分的界線所在，必須是能讓子系統之間的介面最小且最容易精確定義之處
• 錯誤而明確，也遠比模糊不清要好
• 架構設計師所要面對的其中一個最困難的議題，就是如何恰如其分地在進階使用方式與便利性之間取得平衡，他們要為新手或偶爾才會用一下的使用者設計出簡單的操作方式，還是要為專業級的使用者設計出比較有效率的進階使用方式呢？最完美的答案就是兩者都提供，並仍然兼顧到概念的連貫與一致
• 不要建構出必然失敗的系統 --- 瀑布模型是錯的
• 為改變而設計
• 當規劃時間比最佳時間的3/4還少時，則幾乎沒有任何專案能夠成功，不論給多少人去做都一樣
• 專案如果要成功，人的品質，以及人的組織與管理，遠遠比他們所運用的工具或技術要來得重要
• 我們在工作中所面臨的，在本質上，主要都是社會性的問題，而非技術性的問題
• 管理者的工作並不是叫人去工作，而是去創造讓人想去工作的情境
• 輔助功能原則告訴我們，假如能夠小心地維持基層的自主與責任，領導中心將在威信與效能上獲益，其結果是整個組織「越快樂，越欣欣向榮」

讀書筆記 - 與熊共舞

第1章 擁抱風險

• Charette的風險電扶梯
• 假如對某個風險拿不出辦法，他就會把它忽略掉。 (錯誤)

第2章 風險管理是成年人的專案管理

• 暫時性定義: 可能會造成意外結果的事物就是風險
• 風險管理的事務，著重的就是成因風險(causal risk)的管理，亦即你能管理的部分。
• 所謂風險，就是還沒發生的問題；所謂問題，則是已經成形的風險。
• 風險探索 - 承擔分析 - 應變規劃 - 紓緩 - 蛻變的持續監視

第6章 不確定性的臭名

• 事情做錯沒關係，就是不可以不確定 (錯誤)
  (不正視的風險帶來的不確定性)
• 在事後為延誤請求原諒，但是不可以在事前要求認可 (錯誤)
• 選擇性短視症 (大家都很小心不讓自己被枕木絆倒，卻沒人發現越來越近的火車)

第7章 運氣

• 一般的通病就是全部的風險都在賭運氣
• 風險管理是要你在規劃專案時，把焦點放在一旦某些機會沒有抓住的話該怎麼辦。
• 做軟體的案子，把失敗的可能性限制在一定範圍內，一般來說，是比追求勝利更重要的事。

第8章 將不確定性量化

• 「把最早講出來的日期訂為最後期限」，基本上就保證到時一定跳票。
• 把不確定性明確標示出來，你便敢放膽冒險。
• 不確定範圍要多大才算合理，取決於組織開發程序中干擾(noise)或變異的多寡，而非某個人的感覺。
• 不確定範圍大多是介於N的150%~200%之間

第9章 風險管理的技巧

• 從專案經理的角度，他所認知的計畫就是一群一定要完成的工作
• 專案偏離時程，很少是因為工作比預期的更花時間
• 「昨日的問題就是今日的風險」 (認知到問題會一再重複出現的本質)
• 把事後檢討的輸出結果當作風險管理的輸入資料
• 迴避風險 - 放棄報酬
• 抑制風險 - 額外準備足夠的時間和金錢
• 紓緩風險 - 降低抑制成本，在風險成形之前採取措施
• 逃避風險 - 祈求老天保佑
• 沒有任何合約可以把全部的責任統統轉嫁給某個單位，不論是客戶，還是承包商，都必須做好某些風險管理
• 風險承擔=成本x機率
• 致命風險 - 確保致命風險不會發生
• 蛻變指標 - 每個滾動的球後面都跟著一位追逐的孩童 (卡車司機座右銘)

第10章 風險管理的處方

• 在專案進行時，持續風險探索程序
• 沒有人會為一個完成可能性保證有75%的目標全力以赴，也沒人會為一個完成可能性大概是零的目標全力以赴
• 規劃專案時程時，把承諾日期和挑戰性目標分開來訂
• 時程 > 目標 > N
• 如果交貨日期完全不能改，改用版本漸近的方式
• 專案在表面上是不變的期限，但骨子裡卻完全不是
• 想平安地公開風險調查報告，除非大家都一起公開

第11章 回到根本

• 把這些「我不知道」的問題弄清楚，因為那通常就是風險的所在
• 「對於我不知道的東西，我知道什麼 (或我能知道什麼) ？
• 不確定性圖 n: 一種平面圖，以橫軸列舉一組可能發生的結果，以縱軸表示每一種結果的相對可能性
• 每個成因風險都是用一張風險圖來描述
• 把一組成因風險轉化為加總風險
• 透過生產模型來預估 N值 (軟體規模參數和技術因素)，再利用風險模型標出不確定性，得到加總風險圖

第12章 工具和程序

• RISKOLOGY http://www.systemsguild.com/riskology/
• Monte Carlo sampling

第13章 軟體專案的核心風險

• 五個軟體專案常見風險(先天的時程錯誤、需求膨脹、人力流失、規格崩潰、低生產力)
• 時程錯誤: 專案規模高估的部分，通常都不足以抵銷低估的部分
• 大部分的核心風險都跟團隊績效低落無關，時程錯誤也一樣
• 真正表現不佳的，可能是提出或承諾錯誤時程的管理者
• 開發軟體多半是為了滿足某些人的事業領域
• 被掩飾的問題暫時消失不見了，但不會永遠消失不見。

第14章 風險探索的明確過程

• 閉口不談風險，也不會讓風險消失不見
• 組織不準大家談論風險 甚至變成一種不成文規定，而成為組織文化的一環
• 需要一個開放、固定、能被諒解的程序，好讓負面言論有說出來的可能
• 風險探索儀式必須讓人很放心地分享恐懼
• 災難腦力激盪 -> 情境建立 -> 根源分析

第15章 風險管理的動態追蹤

• 持續監控蛻變指標
• 持續進行風險探索
• 蒐集資料，充實風險庫
• 每天持續追蹤完工量測指標
• 完工量測指標(邊界元素敲定、實獲率)

第16章 漸進式風險紓緩

• 最佳投資收益比的風險紓緩策略就是漸進式交付
• 大部分專案的做法通常都是被動的，這種被動做法完全得不到漸進式的好處
• 假設產品的每個部分都一樣重要，這種謊言充斥於許多專案
• 如果系統有個部分必須仰賴技術上的突破才能完成，就該把它納入早期版本
• 漸進交付計畫(設計藍圖、工作分解結構、一組版本驗收測試)
• 一個版本就是設計藍圖的一個子集
• 能被版本驗收測試證實完成與否的工作才歸屬到同一個版本

第17章 終極的風險紓緩策略

• 組織裡的傳統觀念 - 認為建立專案時不預留任何緩衝餘地就是真正勇敢的管理
• 起步太晚是喪失遠見與勇氣的象徵

第18章 價值的量化

• 精確成本和糢糊報酬造就出不倫不類的成本報酬分析，便無法判定風險值是多少，結果，看來只有規避風險最適合
• 成本和報酬都必須律定得同樣精確才行
• 開發經理接下專案，便有義務提出明確的時程和成本預算
• 利害關係人也必須1
• 為預估報酬和實際報酬負責，報酬量化和成本量化的精確程度必須相當
• 若報酬一點量化數據都沒有，就假設是零
• 矯正的時刻：我們無法精確指定報酬的45,328個理由
• 雖然軟體最大的風險要不就在技術(產品方面)，要不就在人為(專案方面)，但是，公司最大的風險卻是在價值方法：把功夫浪費在低價值專案而錯失高價值專案，所 耗費的機會成本
• 冒險的積極程度必須由報酬來驅動

第19章 價值也一樣不確定

• 畫不確定圖
• 只要大一點的風險，都是以價值為核心
• 沒有價值評估，結果就只會是個意氣用事的決策

第20章 敏感性分析

• 想個巧妙的辦法來增加利害關係人負的責
• 價值是非常不平均地分佈在系統中
• 軟體開發人員應該學著相信「少開發一點軟體」
• 系統專案呈現規模不經濟的特徵 (系統規模增加為2倍，則預料系統開發耗費的心力會超過2倍)

第21章 值不值得冒險

• IT產業：報酬小，就要冒更多險，不然我們怎麼可能把成本壓低到讓專案不賠本？
• 死亡行軍專案：這次的任務實在太重要了，重要到全體專案人員最後一滴血也要搾乾。
  (既然這個專案有那麼重要，為什麼公司不願分配合理的時間和金錢來做呢？
• 死亡行軍專案特徵：預期價值很低、員工成了冤大頭、專後最後幾乎都出盡洋相
• 真正的專案評量需要在風險和價值之間取得平衡

從Visual Studio 2008升級到2010的記錄 (1)

最近實在是很想用用C++ 0x的功能在我的專案上，所以就跟我老闆申請，好加在老闆也同意了，從VS2008更新到VS2010時大部分是沒問題的，只在編譯時碰到一個warning..

因為之前我在建立自己的library時，會在debug版後面加個d或是在debug + unicode版本時後面加個ud，方便我自己偵錯也避免連結上的錯誤。

只是在Visual Studio 2008時，是直接修改$OutDir的檔名，現在Visual Studio 2010則改變做法，增加TargetName, TargetExt的屬性，所以只要把.dll名稱的結尾改為修改TargetName就好了，OutDir則按照Visual Studio 2010的推薦做法設定為$(OutDir)$(TargetName)$(TargetExt)即可。

boost 1.38更新到1.45 記錄

今天更新了工作用的boost 1.38，之前也是一直想更新，可是都沒空閒，或是怎麼一更新complier就一堆錯誤。
所以剛好今天有空，而且也快年底了，就趕快更新一下，底下列出我更新時遇到的問題。

1. exception header file改變

由

#include <boost/exception.hpp>

改為

#include <boost/exception/all.hpp>

心得: 不知道這樣改的原因是為什麼，原本不是好好的嗎

2. boost::exception的 get_error_info介面改變

我自己做的logger library會手動去讀取boost::exception的error info

原本是像底下這樣

boost::shared_ptr<char const * const> f = boost::get_error_info<boost::throw_file>(ex)

改成

const boost::throw_file::value_type* f = boost::get_error_info<boost::throw_file>(ex)

3. binary archive bug

之前的boost 1.38版本的binary_iarchive是version 5的，現在到boost 1.45該class也更新到version 8

更新是沒什麼關係，只要有相容舊版的就好，悲劇的就是他不相容... T____T

想一想，這種大型又多人使用的library，在檔案處理上不相容舊版，怎麼想都沒道理啊

於是我就去trace底層的程式碼，並且和boost 1.38版的程式對照，終於讓我發現bug了

開啟boost/archive/basic_binary_iarchive.hpp並找到

void load_override(version_type & t, int version){
library_version_type lvt = this->get_library_version();
if(boost::archive::library_version_type(7) < lvt){
this->detail_common_iarchive::load_override(t, version);
}
else
if(boost::archive::library_version_type(6) < lvt){
uint_least16_t x=0;
* this->This() >> x;
t = boost::archive::version_type(x);
}
else{
unsigned int x=0;
* this->This() >> x;
t = boost::archive::version_type(x);
}
}

可以發現到，若目前lvt是5的話會執行else那段程序，x 的宣告是unsigned int

我們再看一下boost 1.38的該段程式碼

void load_override(version_type & t, int){
// upto 255 versions
unsigned char x=0;
* this->This() >> x;
t = version_type(x);
}

Oops!!! 同樣是x，可是size不一樣...

有問題的還包括 void load_override(class_id_type & t, int version) 這個function

不知道boost 的issue tracking有沒有登錄這個bug了

4. boost::thread + MFC DLL 問題

基本上這個問題在boost 1.38就有了，但是原因有點年代久遠我也忘光光了... 囧

只是沒想到更新成boost 1.45後問題還是沒有解決...

如果你是使用MFC開發程式 ，又剛好你建立的MFC DLL檔有使用boost::thread，就會發生compile正常但是一執行程式出現ASSERT。

解決方法就是到boost/libs/thread/src/win32/tss_pe.cpp裡

把底下的程式碼註解掉

extern BOOL (WINAPI * const _pRawDllMain)(HANDLE, DWORD, LPVOID)=&dll_callback;

再重新compile boost問題就解決了

boost::archive::xml_oarchive 遇上unicode的assert


#include <boost/xml_oarchive.hpp>
#include <sstream>
#include <string>

int _tmain(int argc, _TCHAR* argv[])
{
std::stringstream ss;

boost::archive::xml_oarchive ar(ss);
const std::wstring str = L"測試";
ar & boost::serialization::make_nvp("str", str);

return 0;
}


上面這一段程式碼，在debug模式下會出現assert。
這時候將str稍微改一下就正常了。


#include <boost/xml_oarchive.hpp>
#include <sstream>
#include <string>

int _tmain(int argc, _TCHAR* argv[])
{
std::stringstream ss;

boost::archive::xml_oarchive ar(ss);
const std::wstring str = L"ABC";
ar & boost::serialization::make_nvp("str", str);

return 0;
}


主要原因是因為locale的關係，在xml_oarchive寫入資料時會透過wctomb將unicode轉成multibyte，此時因為locale不對造成轉換錯誤，而產生assert。
所以只要在使用xml archive前先setlocale就ok了。


#include <boost/xml_oarchive.hpp>
#include <boost/xml_iarchive.hpp>
#include <sstream>
#include <string>
#include <assert>

int _tmain(int argc, _TCHAR* argv[])
{
std::stringstream ss;

{
boost::archive::xml_oarchive ar(ss);
const std::wstring str = L"測試";
ar & boost::serialization::make_nvp("str", str);
}

{
boost::archive::xml_iarchive ar(ss);
std::wstring str;
ar & boost::serialization::make_nvp("str", str);
assert(str == L"測試");
}

return 0;
}


不過，比較好的做法是存檔時先將wchar_t轉成utf-8再交給xml archive，讀檔時再把utf-8轉成wchar_t

namespace 的分類設計

最近習慣為每個模組加上namespace，享受namespace帶來的設計概念，但是也遇到了namespace的分類問題，常常namespace分得不夠好且使用起來也不方便，主要是我對於我的code的模組有時候分得不夠清楚，都是是在錯誤中學習，將1個模組拆成2個又將2個合併為1個，花了很多時間在這方面... 囧

後來大概上網看了一下，一直在想boost::tuple的命名概念，我想我以後再設計namespace時就按照這個一般的原則執行就好了。

The common principle is that domain libraries (like graph, python) should be on a separate subnamespace, while utility like libraries directly in the boost namespace.

文章中也有提到tuple設計的結果

The final (I truly hope so) solution is now to have all definitions in namespace ::boost::tuples, and the most common names in the ::boost namespace as well. This is accomplished with using declarations (suggested by Dave Abrahams):

namespace boost {
namespace tuples {
    ...    
  // All library code
    ...
}
using tuples::tuple;
using tuples::make_tuple;
using tuples::tie;
using tuples::get;
}

今天你不操死他們，有一天你就會被他們操死！ 囧

我在管理工作上，一直都做得不是很好，想了一想大概是底下幾個問題

1. 時間管理不好，因為自己還是要寫code，專心的時候就不想要去處理別人的問題，導致即使自己的code有準時完成，但是多數人卻因為問題delay了，整個部分的績效及產品的研發速度很差。
2. 好好先生，我可能想要去當每個人的好朋友，或是不想要給每個人太大壓力，導致最後累的是自己，也許有一天自己也不想給自己壓力了吧。今天你不操死他們，有一天你就會被他們操死！
   

好吧，加油吧，別人的問題優先處理，寧願當個壞人也不要當個讓部門擺爛的好人。
基本上我只是很小很小咖的角色，我是非常希望我頭頭也有這種體會，讓整個研發團隊更厲害。

------

囧，上一篇blog文章是去年的這個時候了，我實在有夠懶...