注重實效的哲學
我的源碼讓貓給吃了
在所有的弱點中,最大的弱點就是害怕暴露弱點。
對於缺點、無知、錯誤,必須誠實。
負責
承諾的事情正確完成,無法完成,超出控制的事情不去承諾。
爲結果負責,出現問題時應提供其他解決方案,不是尋找藉口。
軟件的熵
低劣設計,糟糕代碼需要發現一個就修一個,否則會加速任何一個整潔,良好系統的腐爛。
破窗理論:一輛轎車放一星期無人理睬,一旦有一扇窗戶被打破,數小時之內車上設備就會被搶奪一空
石頭湯煮青蛙
當大家都不願意做一件事時,自己先做,讓其餘人看見未來,就能聚集在自己周圍。
足夠好的軟件
欲求更好,常把好事更糟糕。-The King Lear
系統的功能和質量可以讓用戶參與權衡,不一定要十全十美才進行交付。用戶儘早使用而給出的反饋,能讓系統引向更好的最終解決方案。
你的知識資產
知識會過期,價值會降低,自身價值也在降低
經營你的資產
- 定期投資:定期學習新知識,即使學的不多,因爲習慣本身和知識總量同樣重要
- 多元化:掌握的技術越多,就能更好的進行調整,擁抱變化
- 管理風險:技術也存在高風險高回報,低風險低迴報的情況,不要把技術雞蛋放一個籃子裏(個人理解:風險:學習需要花費的時間,回報:學習後產生的收益。高風險高回報的例如:操作系統,算法之類的計算機基礎。而低風險低迴報的例如某個框架的使用,API的使用等)
- 低買高賣:在新技術流行之前學習它,但是這和找到被低估的股票一樣困難
- 重新評估與平衡:上個月的熱門技術可能下個月就非常冷門,要時常關注業內的新動向。
學習的機會
當發現自己不會的問題不要擱置,應該上網搜索,去圖書館,去找出能找到答案的人。尋找答案的過程不僅可以建立人際網絡,也可以找到其他不相關問題的解決方案,都是很大的收穫。
批判的思考
對於學習到的知識要加上自己的思考,不一定每一個熱門技術都適合自己的項目。
交流
知道你想要說什麼
寫下想表達內容的大綱,並反覆問自己,這些是否講清了我要說的所有內容?並反覆修改
瞭解你的聽衆
- 你想讓他們學到什麼
- 他們對你講的什麼內容感興趣
- 他們有多少經驗
- 他們想要多少細節
- 你想讓誰知道這些信息
- 你如何讓他們聽你說話
注重實效的路徑
重複的危害
如果你改變其中一處,你必須記得改變其他各處。這不是你是否能記住的問題,而是你何時忘記的問題。
正交性
不相依賴以及解耦,良好的系統中,改變數據庫不會影響界面,改變界面不會影響數據庫。
通過消除無關事務之間的影響來做到正交,可以帶來兩個好處提高生產率與降低風險
提高生產率
- 改動得以局部化,增加新代碼不用改變已有代碼
- 更好的複用
- 對正交的組件進行組合,生產率會微妙的提高。A組件能做M件事,B組件能做N件事,AB組合在一起就能做M*N件事。(這裏有一點中臺的感覺)
降低風險
- 隔離:某個模塊出現問題不會擴散到其餘模塊,修復也更容易
- 更健壯:對某個模塊進行改動,出現的問題只會出現在該模塊
- 可替換性:不會和特定產品、平臺綁定在一起,第三方組件都被隔離在各自模塊
設計
如果顯著改變某個功能的需求,有多少模塊會受影響?正交系統中的答案是:一個。
編碼
每次編寫代碼都有破壞正交性的風險,需要時刻監視自己做的事。
- 代碼保持解耦
- 避免使用全局數據
- 避免編寫相似的函數
測試
每個模塊都應擁有自己的單元測試
可撤銷性
不存在最終決策,要把決策視爲寫在沙灘上而不是刻在石頭上,大浪隨時可能把它抹去。
注重實效的偏執
計算機簡短歷史中,沒人曾寫出一個完美的軟件,你也不大可能成爲第一個
接受,擁抱並慶祝它,
要崩潰,不要破壞
當錯誤發生時,應該儘快拋出異常終止程序,而不是把錯誤數據寫進數據庫裏。
斷言式編程
如果一個情況不可能發生,就用斷言確保它不會發生
彎曲,或折斷
解耦與德墨忒爾法則
好籬笆促成好鄰居
間諜常會組成一個小組,小組內互相認識,但不認識小組外的人,如果某個小組被發現了,再多的審問也無法使其他小組的人暴露。
德墨忒爾法則
函數的德墨忒爾法則規定,任何方法調用都應該只調用屬於以下情形的方法
public class Demeter {
private void func(){}
private Object selfObj;
public void example(Object paramObj){
Object methodObj = new Object();
func(); //1.類自身的方法
paramObj.toString(); //2.傳入該方法的任何參數
selfObj = new Object();
selfObj.toString(); //3.該方法創建的任何對象
methodObj.toString(); //4.任何直接持有組件的對象
}
}
當你編碼時
靠巧合編程
避免靠巧合編程,而要深思熟慮地編程。
怎樣深思熟慮地編程
- 總是意識自己在做什麼
- 不要盲目編程:不要構建不完全理解的系統,使用不熟悉的技術
- 按照計劃行事
- 依靠可靠事務:如果有無法特定的情形,就假定是最壞的情況
- 需要其他人知道的內容最好文檔化
- 爲工作劃分優先級
- 不做歷史的奴隸:不讓已有代碼支配未來代碼,不適用的代碼都可被替換,是否重構取決於重構的影響小於不重構的影響
重構
何時重構
- 重複
- 非正交設計
- 過時的知識
- 性能
重構就像外科手術取腫瘤,越早重構越安全
早重構,常重構
怎樣重構
- 不要在重構的同時增加功能
- 開始重試之前,確保擁有良好的測試
思考
- 首先承認自己永遠寫不出完美的軟件,也沒人能寫出
- 對於接手整潔的系統,要小心翼翼地維護,防止破窗效應
- 對於接手糟糕的系統,需要添加單測用例,然後排期逐漸重構
- 系統的設計與編碼實踐中,要注意正交性設計,盡最大可能地解耦
- 注意培養定期學習的習慣,哪怕學習的內容不多,習慣本身更加重要