作卓有成效的程序員

最近閱讀了《卓有成效的程序員》(The Productive Programmer) 一書，此書雖是2009年出版，可是介紹內容的價值並不會隨着時間過去而下降，相信5－10年後對於大部分開發者仍然具備借鑑價值。

大部分章節是介紹具體的方法來如何提升程序員工做效率。記住具體的技巧未必有太大價值，不少人都認同一種觀點就是，讀一本書最終的目標是忘記其中全部的觀點，可是它會潛移默化影響了你之後的思惟和或觀點，包括你的行爲。所以我認爲此書直接的影響就是幫助思考開發過程的方法和問題，思考之前的慣例是否存在問題。好比最近在設計某個產品刪除功能的時候，一位同事忽然提到是否產品未來有須要查看行爲歷史，若是須要記錄歷史，刪除的流程就會變複雜，不但影響刪除功能的實現，還會影響後端數據的規模，從而進一步會影響架構的設計。於是個人直覺是這是一個過早優化，也就是書中第9章講的YAGNT(You Ain’t Gonna Need It 你不須要這個特性)。因爲第一時間的質疑，這個可能須要耗費大量開發時間的特性被暫停，對於項目自己或許是一件好事。

此外書中一些敏捷的思路也會帶來一些間接影響,我還意識到過去一些非敏捷方法可能會給項目帶來風險，一個過去的項目，開發完成以後逐漸變得臃腫，和大部分後端服務類似，須要依賴一些特定的數據庫及其餘依賴環境。因爲不但願開發環境與真實環境差距太大，開發環境也所有按真實環境最小單元的配置來進行，這就致使開發依賴的環境不少

內部依賴
MySQL master/slave
分表
Memcached(多個)

外部依賴
Message Queue(消息隊列)
用戶及鑑權服務
internal HTTP service

致使的問題
須要特定的環境才能開發，好比公司配好的環境中
沒法在家中或咖啡館幹活，由於系統跑不起來，沒法看到效果
一旦部分依賴環境有問題，則沒法開工，只能等着服務恢復
一旦幾天沒跟進代碼，可能就因爲環境設置的變化而沒法獨自啓動工程。

這些問題就致使代碼改進的工做使人生畏，要像Google那樣作到任何對代碼感興趣的人能夠patch代碼的意願都會變成」mission impossible」。所以對於這個項目來講，最急需的一個改進是分析依賴，讓項目可以隨時隨地能夠方便的跑起來，你們能夠很簡單的改進代碼，對改進的代碼進行測試驗證，測試以後新的代碼基本能夠無風險的運行到線上環境去。不然臃腫的項目只會下降你們的貢獻的熱情，最後變成一個死氣沉沉的工做任務。

你的項目中的慣例是否存在問題呢？好比Java中POJO中無用的get/set方法，好比一些使用c/c++來「優化」項目中的瓶頸而走向時間泥潭的經歷，好比貴公司是否又在雄心勃勃要作一個本身的框架，事實上這個框架對於項目自己毫無價值。諸如此類的狀況會很是多，這本書主要介紹的是程序員要如何提升自身的效率，但我以爲程序員更多的也應思考團隊的效率改進併發出聲音。