今天給3個月前的專案拓展功能，儘管自認為自己在組織程式碼上進步了不少，
但改起3個月前的東西來，還是讓我想起梁靜茹的歌： 會呼吸的痛

這塊程式碼動不了，那塊程式碼也動不了，wtf，這個是幹嘛用的？？
最後還是要靠全域性搜尋

1.承擔太多邏輯的欄位

item.link='/xxx/xxx'

我有一個欄位link，
對於不同的item，link裡存的東西是不一樣的，
所以每次都要判斷item的型別，才能知道link是用來幹什麼的
而且對應規則還很複雜，令人抓狂

從命名的角度來說
link這個名字並不能描述這個屬性所代表的含義，
link沒有意義，
這個欄位叫做 aa，bb，dog，cat 都可以，反正跟含義沒關係

從邏輯設計來說
這個屬性承載的資訊太多，用了太多if判斷，
一個欄位只能走一個專一用途，

極端一點來說，你可以把所有資訊寫在一個欄位裡，
那就跟寫祕密報文一樣了，保證你自己都看不懂

2.遙遠的呼應、隱藏的規則、晦澀的表達

無法，或者暫時無法在程式碼中表現的，
要寫在元件的readme裡面，

比如 和服務端達成的一些協議和規則，
某些因為權宜之計形成的、難以理解的晦澀的潛規則，比如那個link

另，
程式碼自己就會說話，
行內註釋、readme一定要惜墨如金，
能不寫的儘量別寫，能用程式碼表達的就別寫註釋，
不然都是冗餘資訊，自己都懶得看

資料結構與邏輯

資料結構(這裡指邏輯結構)和程式碼，是表達資訊的關鍵，
資訊的解碼過程要相對簡單，

1.檢查資料結構
欄位的命名
難以命名的時候，判斷是否是因為這個欄位承擔的功能太過複雜

2.檢查邏輯
確保每一個if、每一次賦值、每一次迴圈
都有一個對應的屬性名、變數名或者函式名來說明為什麼要這麼做