《移山之道》讀後感
老師布置的閱讀任務雖然是附加的作業，但是對我來說是個很好的學習機會。軟體工程主要是對工程的開發進行學習，畢竟在學校老師教了那麼多的知識，我們課下做了那麼多的練習並沒有提高我們做乙個工程的能力。乙個專案乙個工程不僅僅是編寫**，除錯，簡單的測試，通過閱讀《移山之道》這本書我對開發專案有了乙個全面的了解。
雖然平時接觸了一些程式設計類書籍，但是接觸軟體工程相關書籍還是第一次，讀了這本書以後有很多的收穫。也是通過這本書我才了解到開發乙個軟工專案的團隊中原來需要這麼多人員的協調，並不簡單的是有人寫**有人測試就行了。對於乙個產品，團隊需要有pm建立乙個使用者和開發者之間的橋梁進行溝通，使用者說出自己的需求，開發團隊才能根據需求完成相應的任務。團隊的每個人之間的聯絡也是pm或者說是leader建立起來的，沒有乙個好的管理者乙個團隊是無法完成任務的。而開發團隊中的程式設計能力強的人不少，但是他們之間的合作是能否高效完成任務的關鍵，遇到問題時是否能冷靜下來處理問題而不是堅持自己的意見不退讓，對於合作專案中的**，是否有share的思想，可以客觀的分析出自己**中的問題。
我產生的疑問：
1.pm不熟悉現階段專案用到的技術，無法準確控制開發的時間和進度，dev leader懂技術懂**但是隊員的水平參差不齊，有些事情只有leader能解決，這時候該怎麼辦？
答：我認為這時候解決問題的最好方法是leader在對專案工程進行一些問題修復的時候讓全隊旁觀，相當於每次的工作都是一次教學，畢竟大家的磨合才能使團隊進步。如果水平的不足是既定的事實了，那麼只好尋找方法去彌補。
2.如果團隊裡遇到了技術很牛但是合作精神逐漸才發現很糟糕的人該怎麼辦。如果此時找不到任何能接替他的技術人員了，是放棄他還是放棄專案？
3.複審的意義是什麼？對於一些牛人的**，是否還有必要進行複審？
答：人無完人，再牛的人在編寫**的時候都有可能會犯一些細小的錯誤，讓別人複審不是對於程式編寫人員的不信任，而是希望對方能夠完善自己的程式，從中發現自己在編寫**時的問題，避免今後錯誤再犯。
《學習之道》讀後感
組塊建立 拖延症小惡魔 增強記憶力 組塊就是根據意義將資訊碎片集合，就像乙個個知識點如一塊塊拼圖塊組成拼圖，就像是把相關的檔案打包成zip。只要把乙個相關部分打包成乙個組塊，就不要糾結於所有的細節枝末節，可以快速行動起來。比如你作為乙個程式設計師，你寫乙個排序，你如果沒有排序的組塊，你還要一步步去推...
產品經理修煉之道讀後感
在讀費傑的這本書之前，我也讀了很多關於網際網路產品經理方面的書籍，包括 啟示錄 結網 人人都是產品經理 等以及關於技能方面的 ucd火花集 don t make me think 使用者體驗要素 等等，之前讀完這些書後都有寫讀後感的衝動，但由於各種原因 好吧，我承認，其實最主要的是我懶惰，呵呵 都沒...
《程式設計師修煉之道》 讀後感
前些時間把 程式設計師修煉之道 讀了一遍。一本好書啊。且不說裡面的一些程式設計技巧 這個詞應該比較貼切 比如正交性 高內斂，最後達到兩個模組之間互補影響 曳光彈或是原型 輕量級引導程式，直達目標，方便調整 斷言式程式設計，異常使用 暴露程式的問題，不要隱藏他 解耦與墨忒爾法則 低耦合，減少依賴 演算...