我成為了一名職業程序員，但是我發現所有的算法別人都已經實現了，我只要調用就可以。似乎我們公司的軟件與數據結構、算法的關系都不大。那我當初辛辛苦苦學習的數據結構和算法有用么？如何區分一個好的程序員和不好的程序員呢？ (Page 1)
體會：書中舉的四則運算的例子做深了以后可能還涉及一些相對比較復雜的算法，可是在現實中接觸到的系統很多是業務驅動的系統，用戶量可能不會超過2000，CRUD，業務復雜流程交給成熟的工作流系統去做了，CRUD是很簡單的數據庫表操作，數據庫操作有現成的框架，前端有現成的框架，后端有現成的框架，程序員要做的事情就是熟悉現有的框架，完成相應的業務模塊的開發。典型的開發過程是：拿到一個業務需求，建模->轉換成實體類->對這個實體類的CRUD->拖出一個工作流流程圖->把流程涉及的表單用前端框架做好->調用封裝好的工作流的方法實現業務流程操作。在整個過程中，似乎用不到任何復雜一些的算法和數據結構（最多可能會考慮一下實體類之間一對多之間的關系），但是仍舊有些程序員做的很好，bug非常少，功能也很穩定，有些bug很多，這樣可以區分去好的程序員和不好的程序員么？
有人說一個人就可以快速成長為一名全棧工程師，這讓我想起街頭賣藝的單人樂隊(One-man-band), 他們什么都會一些，可以很快地演奏一些曲子。 (Page 57)
體會：我大概聽過兩類企業，有一類是每個工程師就是一個螺絲釘，在自己的某個技術上發揮極致的能力，有一類是每個工程師類似一個"大雜燴"（這個比喻不知道恰當與否，就是表示工程師需要處理項目中各類技術方面的問題），前一類公司培養出來的工程師可能是強化自己現有的技術能力，而另外一類公司的工程師，就是在拓寬自己的技術能力，第二類公司培養的人員，似乎就有點像作者所說的"演奏家滿場奔跑，操作各種樂器"，可是我認為這種方式並非不好，因為現在很多開發模式是前后端工程師分開開發，但是前后端工程師開發的速度可能有差別，所以，最大化時間利用率是前端開發完畢以后，可以支援后端開發，反之亦然，這樣就可以讓項目進度整體加快，而這就需要"演奏家滿場奔跑，操作各種樂器"。其次，作者在第17章17.3.4節中介紹 團隊的 創造階段（Performing）的時候說到一點：團隊成員相互支持，相互依賴，角色和職責能夠根據項目的要求自然轉換，沒有人為此擔心或發牢騷。這里說的自然轉換，是不是就是 "演奏家滿場奔跑，操作各種樂器"？最后，是不是精通某個技術就是要放棄其他技術的學習，這兩者要怎么平衡呢？比如一個工程師，前后端都可以上手做項目，他到底應該怎么去精通某個方面呢，完全放棄前端專心做后端？還是完全放棄后端做前端？
技術產品的發展周期（萌芽->成長->成熟->衰退->結束） (Page 367)
體會：這里的技術產品包括編程語言么？很多語言雖然語法不一樣，但是都能實現同樣的功能，可是還是會有火/不火的區別，這樣的話，如何准確判斷一門編程語言的發展階段，從而在學習的過程中不會浪費時間到最后學了一門被淘汰的語言？此外，我在學習過程中，總會存在一種不安全感，總覺得學這個可能會淘汰，然后去追逐一些新出的技術，或者熱門的技術，如何克服這樣的不安全感？
如何給一個系統的所有源文件都打上標簽，這樣別人可以同步所有有這個標簽的文件版本？(Page 254)
我最早接觸的打基線（針對項目源碼）的方式，是將每次發布的版本源碼放到一個文件夾下面，比如這次發布的是1.1版本，就在版本管理庫（用的是SVN）里面的tag目錄下，建立一個名字V1.1的文件夾，然后把V1.1版本的源碼都放進去。這樣做的方式維護起來比較麻煩，V1.1發布以后，要改一些臨時修復的緊急bug，還要在tag下的V1.1文件夾中建立一個patch文件夾來放修改bug涉及的源碼文件，非常麻煩。
后續想了一個比較好的方式，就是在發布的時候，在版本管理庫的根目錄下做一次空提交，提交的備注就是@release+版本號，如：@releaseV1.1，表示這是V1.1版本發布的時候的版本，這樣的話，看提交歷史就可以很清楚的找到LKG版本，而且也容易回滾。
看到這里想到一個場景，就是很多系統在開發的時候，配置文件里面會記錄數據庫連接，在開發的時候，用的是測試庫的數據庫連接，在發布的時候，要修改成正式數據庫的連接，最早的時候，我們會區分兩套源碼，一套源碼是連測試庫的，用於日常開發，發布以后，把連接生產數據庫的源碼打到基線區，后續想到一種更優化的方式（針對Maven項目），會存兩個配置文件：
prod.properties --> 生產配置
dev.properties --> 測試配置
然后在打包的過程中，通過命令行參數來控制采用那個配置文件，比如默認的打包命令是：
mvn clean package
這樣打包就讀取的是dev.properties中的內容
加上一個參數 -Pprod
mvn clean package -Pprod
這樣打包讀取的就是prod.properties的配置文件
運行/編譯的時候類似，都是通過命令行參數來控制，這樣的話，就只需要維護一套源碼即可。
在看到初始效果和了解實現細節后，小飛開始寫設計文檔，寫好之后，他可以請同事一起來復審設計文檔。(Page 240)
我了解的很多用敏捷開發的公司的做法是：在看到初始效果和了解實現細節后，小飛開始寫......代碼，
因為情況只有如下幾種：
1. 需求很簡單，不需要設計文檔，一次性就可以搞定的。如：實現抓取某個新聞列表和詳情的數據接口。這種情況，寫設計文檔似乎有點耽誤時間。或者。。。先開發，后面可能公司這邊需要再補充設計文檔。
2. 需求看上去好像很簡單，但是實際寫代碼並測試以后，發現當初的技術方案無法達到要求，比如：在抓取某個人待辦數據詳情的時候，我們開始是用抓取頁面元素的方法，后來發現渲染頁面速度太慢，導致顯示數據詳情常常會超時，后來就優化成直接發送ajax請求而不渲染頁面的方式。像這樣需要不斷嘗試並優化的開發方式，寫設計文檔這件事更加有點馬后炮的意味，因為畢竟實實在在的Coding和效能測試才能發現和找到問題所在並修正。