工程師必讀聖經之一，但若這本書是我在剛開始工作的時候閱讀的話，不會心有戚戚焉。一開始想參加社群的讀書會來跟著進度閱讀，並且也可以跟其他領域的工程師做交流，可是第一次的讀書會超出我的想像，所以決定自立自強讀這本書。
書中提到了許多的例子跟內容，但會著重在開發上的經驗以及一些想法。做一個記錄，之後再回來看這一篇，或是重讀這本書之後會有不一樣的見解。
對於工程師來說什麼是最重要的？一開始的章節有介紹不同的看法，及見解。對我來說就是高閱讀性，且不需他人手把手的教導，可以透過程式碼，讓人覺得就是在通讀一篇故事，而工程師就是寫故事的人。
分成三個大方向，闡述閱讀性重要性，依重要性高低為命名、編排以及註解。
命名
包含各種檔名、函式、變數等等。原則上需要一致性以及表達本意，不要用漠糊或意義不明的方式進行命名。
一致性原則
使用駝蜂或是蛇型命名，無論使用哪一種，至少在同一個專案都是使用同一種，除了讓程式碼看起來簡潔之外，也是工程師在轉換的時候不需要還要花一點點的時間去做轉換，也許會有人覺得這些並不是很重要，但其實那一點點的時間累積下來，就會成為可觀的數值。每一個類別裡的各函式跟變數都有不同的原則，假使一個類別裡面有十個需要工程師做轉變，一個需要0.05秒，一個類別就要0.5秒。如果一天看了這個十個這樣的類別，就要5秒。以現在工作一天要看的類別至少有20個以上，以這樣方式計算花10秒看這個，沒有很大的效率，不如統一這個原則，減少轉換的成本。
另外同一單字，不要在專案裡面用不同的英文單字去敘述。舉例來說，在Adapter裡面所使用的資料存放的變數，在不同的adapter分別出現以下dataList, list, mData, mValue這些，擇定一個，在讀adapter都知道這個變數所代表的函意。要不然還要去猜測這些變數是不是工程師認知的那一個意思。
表達本意
- 不要使用看不懂/不常用/易混淆的命名
曾經看到檔名叫做xxxHandler的時候，第一個想到的Android裡面Handler元件，實際這個類別卻是在處理某個頁面的錯誤處理。其實要重新命名成頁面為主命名+功類別用途，讓下一個工程師看到這個不會再產生誤會。
另一個則是遇過比較大問題的，函式的名稱是奇妙的代碼，看功能是在呼叫API沒錯。對熟悉該專案的人沒有問題，對其他開發成員來說，要先了解該內容之後，才知道這支API的用途，才能進行下一步。在這個狀況下，不如把該函式重新命名成功能性導向，讓工程師(人)可以一目了然。
- 不要用否定判斷式
這一點很難進行，很多的時候在寫condition的時候，就會直接寫否定判斷式，覺得大家都看得懂，但有時候發現問題是發現在這些負向的判斷式上 舉例來說!TextUtils.isEmpty()，這句很輕易了解，但實際上在工程師的腦袋裡面，會先進行這個是不是為空(TextUtils.isEmpty())→不是空之後(否定前述的結果)再做什麼事，做了兩次轉換。有經驗的人也知道，有時候複雜的轉換，或是一念之差，有可能出來的結果就完全不一樣。不如建立一個函式，專門處理這種否定判斷式：
如何減少一開始直接寫否定判斷式，自己還在調整這種習慣Orz
編排
程式碼上下左右關係，是否強關聯
最常見的是Android Life Cycle以及函式執行的順序，onCreate之後，可能會是onStart、onResume、onStop及onDestroy()。但有些時候有些程式碼需要擺在這些狀態裡面，但這些activity的狀態，可能會隨著開發時間而散落在類別的四處。
舉例來說，onResume()需要做一些檢查，但在類別裡面，卻是被擺到最後的區塊。對於第一次看這個類別的工程師，想要了解該類別的用途，onResume()的狀態就會被最後讀到，不如把onResume()函式拉到跟onCreate()較近的距離，除了了解整個Android Life Cycle在這個類別是有什麼函式在執行，也能通盤了解架構。
另一個也常見的是，新加的功能擺在onCreate()之後，可是被執行的順序卻是在最後，在經驗來說擺在類別最後比較合適，在使用IDE看哪些函式已經被執行，但這個功能卻一直沒被呼叫到，會讓人有滿滿地疑惑，這個函式到底何時何地被呼叫到？與其留給工程師問號，不如主動把它放到最後的區塊或是讓他去應該要被安插的順序中。
在這本書有提到火車事故例子，是指一個函式去呼叫太多的相依性的變數或函式，中間呼叫了什麼沒有那麼明確，若中間取得值的途中有什麼問題，很難一眼看出
註解
清楚及有意義闡述說明功能，或是提供訊息給其他的參與專案的工程師
當時在看很多的類別裡面有一些不知何時的留下的程式碼註解，雖然知道應該是無用的，但是沒有勇氣要去刪掉。直到這個章節有提到一件事，完全豁然開朗。現在的Git功能很強大，可以去比較不同的commit發生了什麼事，就算真的發生了問題，可以再檢查版本，把這段救回來。接著，我就把那些無用到的程式碼刪掉，下commit，了結我中心一種擔憂。
另外比較讓人困惑的是寫了FIXME或TODO，但不清楚這個東西已經被修正或被加入等等，也不知道這個問題的時效性如何。關於這個，可以先問對專案資深的工程師，或者是像上述，先移除，留下註解，接著下commit。
最後關於註解，還有一個問題是時效性，若原先其實在註解當中加入日期，其實也不用再意說到底這段是否刪了會不會發生什麼事。這點專案其他人提出來的解法，自己在看別人的註解跟自己的更加的清楚。
