讀書筆記2

6.交流
交流又有技巧，與客戶的交流更是如此，書中介紹了幾個需要注重的方面：
1.知道自己要說什麼
首先要自己組織好語言。圍繞心中所想的框架展開闡述
2.瞭解聽眾想要什麼
交流時雙方的事，是雙方希望透過交流來達到共識，所以我們需要知道聽眾想要聽到什麼，比如，你可以用以下方法展開：
你想讓他們學到什麼
他們對你講的什麼內容感興趣
他們有多富有經驗
他們需要多少細節
你想要誰擁有這些資訊
你如何促使他們聽你說話
3.選擇一個風格
選擇你想要達到的目的最合適的風格
4.讓文件美觀
問到需要認真編寫，且需要進行排版
5.讓聽眾參與進來
及時提問，聽取聽眾的回覆，與聽眾進行互動
7.重複的危害
重複的產生通常有以下種類：強加的重複。開發者覺得他們無可選擇，其實是有一些方法讓我們避免重複的。無意的重複。開發者沒有意識到他們在重複資訊。這個需要透過提高程式碼意識或者 CR 進行減少。無耐性的重複。開發者偷懶，因為重複可以讓事情更容易。有時往往會遇速則不達，在這類重複面前我們應該更慎重。開發者之間的重複。同一個團隊或者不同團隊的幾個人重複了同樣的資訊。需要一個統籌的人引導大家交流，提供一箇中央區域，管理維護公共程式碼
8.正交性
1、正交性是一個從幾何學中借鑑而來的術語，如果兩條直線相交成直角，他們就是正交的。這在向量中的解釋是沿著一條直線移動，你投影到另一條直線上的位置不變。在計算機中，該術語用於表示某種不相依賴性或解耦性。2、正交的好處是它提高生產效率，各個元件不相互依賴，使得改變得以區域性化，促進複用，對於正交元件進行組合也可以提高生產效率，同時它還降低了程式碼的風險。3、延伸開來，專案團隊的配合也應該遵循正交性。如果成員之間任務重疊較多容易讓大家疑惑問題和責任的歸屬如何劃分，這會造成配合的效率低下。
9.可撤銷性
如果某個想法是你唯一的想法，再沒有什麼比這更危險的事情了。在設計軟體時，我們需要為可能出現的某種錯誤做準備，比如資料庫的更換，開發平臺的更換。這需要我們設計之初就考慮到構建一個相對靈活的架構。
10.曳光彈
1、在黑暗中使用機槍射擊有兩種方式。方式一：你需要知道目標準確的位置，然後考慮當時的溫度、溼度、氣壓、風力等一系列因素，計算完位置之後進行射擊。方式二：使用曳光彈，發射時，曳光彈中的磷點燃，會照亮它經過的地方和最終位置，我們用曳光彈確認位置之後，就不需要那些繁雜的計算，直接使用機槍進行射擊。2、在黑暗中發光的程式碼。通常一個專案的開發是非常複雜的，如果只是一個模組一個模組的開發，我們可能直到最後才能確認專案執行情況。更好的做法是，我們要讓系統儘早的跑起來，然後根據需要給它完善細節。這樣會有以下好處：使用者能夠及早看到能工作的東西。開發者構建了一個能在其中工作的結構。你有了可用於演示的東西。你能夠感覺到工作進展。
11.原型與便箋
1、原型是你可以在忽略細節的情況下，考慮專案走流程，主要使用場景，他們是否正確，是否可行。通常也可以用用於演示2、原型製作是一種學習經驗，其價值並不在於所產生的程式碼，而在於所學到的經驗教訓。那才是原型製作的要點所在。3、製作原型甚至不需要編碼，你可以用便箋，白板上製作原型。製作原型時你需要嘗試回答以下問題：主要元件的責任是否得到了良好定義？是否恰當？主要元件間的協作是否得到了良好的定義？耦合是否得以最小化？你能否克服確認重複的潛在來源？介面定義和各項約束是否可接受？
12.領域語言
1、計算機語言會影響你思考問題的方式，以及你看待交流的方式。2、領域語言通常是為了簡化流程，用於配置或者控制應用程式。3、DSL 可以理解為一個小型語言，它可以是擴充套件自已有語言。4、在設計一種 DSL 時，考慮可讀性還是簡單性時，主要權衡的應該是可擴充套件性和可維護性，因為通常大多數應用都會超出預期的使用期限