——手邊無書，卻欲成此讀書筆記，僅憑記憶與經歷談談自己的感想
時隔數月，我仍清晰地記得《最後期限》裡面的一句話：人是經理所要解決的唯一重要的事情。（只可惜我很難想起《構建之法》中有很經典的語句，大概是乾貨太多就難以有所注重吧）
這是兩本相輔相成的書——《最後期限》闡述如何解決人的問題，避而不談構建方法，而《構建之法》則是一本厚厚的方法手冊，對人事問題又談及甚少。這兩本書引領著我走入團隊合作的世界，而想起過往在電子設計實踐中的小打小鬧，才發現要讓乙個大的團隊緊密合作，任重而道遠。
在最初的兩個月裡，我就像是瘋了一般，每天加班加點地閱讀有關團隊專案的各種書籍，因為我一想到就要在三個多月後交付自己的作品，而自己對這個領域一無所知，就感到深深地恐慌。我以為隊友們都是抱著這樣的心態，時不時還能看見他們在群裡討論幾句，就沒有過問每乙個人的投入與進度。實際上，這是很錯誤的，直到真正開始開發的時候，我才發現自己已經翻閱了接近十本書，而大部分組員閱讀量還不到半本書。如果從開發的一開始就使用《構建之法》中提到的燃盡圖，那麼我想情況將會好很多，當然另外就是我沒有用心去督促團隊裡面的成員，事實上這也是一門藝術，《最》也著重強調過。
敏捷開發流程中燃盡圖是必不可少的，雖然《最》中的主人公看不起這些工具，認為解決好僱傭人的問題就足夠了，然而至少對於我這類新手，這種工具用起來真是得心應手。每一天都要求組員匯報進度、耗時，每半周公告未完成任務、completed hours、 projected remaining hours， 這樣團隊的進度一目了然，再加上目前我對專案開發所需要的技術、所要走的流程都有了較深的認識（得益於之前的學習），這樣就能很及時地發現沒有完成任務的同學，雖然無法開除組員，但能及時將人物分配給其他組員，規避風險。我認為乙個優秀的專案經理，掌握大致的底層知識也是必須的，在目前我也擔任類似技術總監的工作，安排每個人的學習任務、程式設計任務並且指導他們查錯，雖然這與初衷相背離，但我能感受到掌握所有知識的好處——組員無法再用你不懂的藉口糊弄你。
在《構》敏捷開發一章接近最後的部分，提出了如何管理專案**的問題，我也有過切身體會：
1）源**控制系統——如何控制簽入、簽出？ 為了避免衝突，需要統計每個人每週有空的時間（因為課程有所不同），盡量按照分組安排修改的時間以避免衝突、每次安排相關性盡量小的任務，實在有衝突需要及時向有關聯的小組聯絡。因為沒有用團隊專案管理工具，所以我們主要通過交流的形式進行管理。
2）如何看到修改與之前版本的差異？ 這是讓我仍然很困惑的地方，github貌似只能回溯版本，而要一覽差異卻不像是個簡單的工作。所以我讓組員們將每一次的修改都匯報給我，而我進行管理、追蹤。
3）如何合併不同的修改？ 這就需要參與者的面對面溝通，所以在敏捷開發中，頻繁地溝通是很有必要的，《最》一書中談到了交流所帶來的效率損耗也是很明顯的，因為每乙個人就像是圖上的每乙個節點，隨著人數的增長，交流幾乎是平 方增長的，這也是為什麼小團隊容易創造奇蹟的乙個原因。
APUE讀書筆記 第10章 訊號
第10章 訊號 10.1 引言 訊號是軟體中斷。訊號提供了一種處理非同步事件的方法 10.2 訊號概念 每個訊號都有乙個名字。這些名字都以三個字元sig開頭 在標頭檔案中，這些訊號被定義為正整數 訊號編號 不存在編號為0的訊號。kill函式對訊號編號0有特殊的應用。此種訊號編號值被稱為空訊號 10....
《C Primer》讀書筆記（10）
1.關於繼承 派生類雖然可以訪問基類的公有和保護成員，但是不建議在建構函式裡直接初始化這些值，而是呼叫基類的建構函式來初始化。2.c 11新標準，在類的後面加乙個final關鍵字，即可防止類被繼承。在函式後面加乙個final關鍵字，可以防止函式被覆寫。3.c 11新標準，在派生類中，如果是想覆寫乙個...
Effective cpp 讀書筆記10
set new handler允許客戶指定乙個函式，在記憶體分配無法獲得滿足時被呼叫 nothrow new是乙個頗為侷限的工具，因為它只適用於記憶體分配 後續的構造函式呼叫還是可能丟擲異常 namespace std為了檢測執行錯誤 可能存在記憶體洩漏 資料overruns 寫入點在分配區塊尾端之...