第四章 注釋
第五章 格式
第六章 對象和數(shù)據(jù)結(jié)構(gòu)
得墨忒耳定律 (最少知識原則)
1.每個單元對于其他的單元只能擁有有限的知識：只是與當(dāng)前單元緊密聯(lián)系的單元询枚；
2.每個單元只能和它的朋友交談：不能和陌生單元交談；
3.只和自己直接的朋友交談浙巫。
火車失事代碼
final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();
混雜
一半是對象金蜀，一半是數(shù)據(jù)結(jié)構(gòu)，這是一種糟糕的設(shè)計(jì)的畴。它增加了添加新函數(shù)的難度渊抄，也增加了添加新數(shù)據(jù)結(jié)構(gòu)的難度。
隱藏結(jié)構(gòu)
既然取得路徑的目的是為了創(chuàng)建文件苗傅，那么不妨讓 ctxt 對象來做這件事：
BufferedOutputStream bos = ctxt.createScratchFileStream(classFileName);
第七章 錯誤處理
1抒线、別返回null值。程序中不斷的看到檢測null值的代碼渣慕，一處漏掉檢測就可能會失控嘶炭。返回Null，作者認(rèn)為這種代碼很糟糕逊桦。建議拋出異常 或者返回特定對象（默認(rèn)值）眨猎。更早的發(fā)現(xiàn)問題。同理强经，也應(yīng)該避免傳遞Null值給其他的方法睡陪。
2、在大多數(shù)的編程語言中匿情，沒有良好的方法能對付由調(diào)用者意外傳入的null值兰迫。我們發(fā)布產(chǎn)品應(yīng)該有容錯的機(jī)制，程序不能輕易的就崩掉炬称，有異常應(yīng)該及時記錄下來或給出提示汁果。
第八章 邊界
1、通過接口管理第三方邊界玲躯，可以使用ADApter模式將我的接口轉(zhuǎn)換為第三方提供的接口据德。這個是要注意鳄乏，第三方的代碼和自己的代碼混合太多，這樣不便管理棘利。
第九張 單元測試
敏捷和TDD運(yùn)動鼓舞了許多程序員編寫自動化單元測試橱野，單元測試是確保代碼中的每個犄角旮旯都如我們所愿的工作。
TDD三定律
- 除非這能讓失敗的單元測試通過善玫，否則不允許去編寫任何的生產(chǎn)代碼水援。
- 只允許編寫剛好能夠?qū)е率〉膯卧獪y試。 （編譯失敗也屬于一種失斆├伞）
- 只允許編寫剛好能夠?qū)е乱粋€失敗的單元測試通過的產(chǎn)品代碼裹唆。
整潔的測試 具有 可讀性
構(gòu)造-操作-檢驗(yàn)（BUILD-OPERATE-CHECK）測試代碼三個步驟
每一個測試一個概念
F.I.R.S.T 整潔的測試遵循以下5條規(guī)則：
1.快速（Fast） 測試應(yīng)該能快速運(yùn)行，頻繁運(yùn)行測試只洒，就能今早發(fā)現(xiàn)問題
2.獨(dú)立（Independent）測試應(yīng)該相互獨(dú)立。某個測試不應(yīng)為下一個測試設(shè)定條件劳坑，可以單獨(dú)運(yùn)行每個測試毕谴，及以任務(wù)順序運(yùn)行測試。
3.可重復(fù)（Repeatable）測試應(yīng)該可在任務(wù)環(huán)境中重復(fù)通過距芬。
4.自足驗(yàn)證（Self-Validating）測試應(yīng)該有布爾值輸出涝开。不應(yīng)該手工對比量不同文件來確認(rèn)測試是否通過。
5.及時（Timely）測試應(yīng)該及時編寫框仔。單元測試應(yīng)該恰好在使其通過的生產(chǎn)代碼之前編寫舀武，如果在編寫生產(chǎn)代碼之后編寫測試，你會發(fā)現(xiàn)生產(chǎn)代碼難以測試离斩。
