1、可靠的開發軟體，並讓我們的開發更易於理解和維護的唯一途徑，是遵循我們稱之為 dry 的原則：系統中的每一項都必須具有單
一、無歧義、權威的表示。
dry 是 dont』t repeat yourself 的縮寫。
2、重複的產生通常有以下種類：
強加的重複。開發者覺得他們無可選擇，其實是有一些方法讓我們避免重複的。
無意的重複。開發者沒有意識到他們在重複資訊。這個需要通過提高**意識或者 cr 進行減少。
無耐性的重複。開發者偷懶，因為重複可以讓事情更容易。有時往往會遇速則不達，在這類重複面前我們應該更慎重。
開發者之間的重複。同乙個團隊或者不同團隊的幾個人重複了同樣的資訊。需要乙個統籌的人引導大家交流，提供乙個**區域，管理維護公共**。
1、正交性是乙個從幾何學中借鑑而來的術語，如果兩條直線相交成直角，他們就是正交的。這在向量中的解釋是沿著一條直線移動，你投影到另一條直線上的位置不變。
在計算機中，該術語用於表示某種不相依賴性或解耦性。
2、正交的好處是它提高生產效率，各個元件不相互依賴，使得改變得以區域性化，促進復用，對於正交元件進行組合也可以提高生產效率，同時它還降低了**的風險。
3、延伸開來，專案團隊的配合也應該遵循正交性。如果成員之間任務重疊較多容易讓大家疑惑問題和責任的歸屬如何劃分，這會造成配合的效率低下。
**設計的時候也應該盡可能考慮正交性，這需要結合一些特定的設計模式以達成目的。
如果某個想法是你唯一的想法，再沒有什麼比這更危險的事情了。在設計軟體時，我們需要為可能出現的某種錯誤做準備，比如資料庫的更換，開發平台的更換。這需要我們設計之初就考慮到構建乙個相對靈活的架構。
1、在黑暗中使用機槍射擊有兩種方式。
方式一：你需要知道目標準確的位置，然後考慮當時的溫度、濕度、氣壓、風力等一系列因素，計算完位置之後進行射擊。
方式二：使用曳光彈，發射時，曳光彈中的磷點燃，會照亮它經過的地方和最終位置，我們用曳光彈確認位置之後，就不需要那些繁雜的計算，直接使用機槍進行射擊。
2、在黑暗中發光的**。通常乙個專案的開發是非常複雜的，如果只是乙個模組乙個模組的開發，我們可能直到最後才能確認專案運**況。更好的做法是，我們要讓系統盡早的跑起來，然後根據需要給它完善細節。這樣會有以下好處：
1、原型是你可以在忽略細節的情況下，考慮專案走流程，主要使用場景，他們是否正確，是否可行。通常也可以用用於演示
2、原型製作是一種學習經驗，其價值並不在於所產生的**，而在於所學到的經驗教訓。那才是原型製作的要點所在。
3、製作原型甚至不需要編碼，你可以用便箋，白板上製作原型。製作原型時你需要嘗試回答以下問題：
1、計算機語言會影響你思考問題的方式，以及你看待交流的方式。
2、領域語言通常是為了簡化流程，用於配置或者控制應用程式。
3、dsl 可以理解為乙個小型語言，它可以是擴充套件自已有語言。
4、在設計一種 dsl 時，考慮可讀性還是簡單性時，主要權衡的應該是可擴充套件性和可維護性，因為通常大多數應用都會超出預期的使用期限。
1、通過學習估算，並將此技能發展到事物的數量級有直覺的程度，你就能展現出一種魔法般的能力，確定他們的可行性。
2、多準確才足夠準確？130 個工作日和大概 6 個月，是不同的，顯然，前者表示的精度更高。我們在做估算的時候也需要選好描述估算時間的單位值。
3、估算結果怎麼來呢。
首先需要確認你是否理解了需求所涉及的各個方面，這個是前置條件。
然後你需要建立系統模型，在這個系統中，把模型分拆成各個元件，然後給每個引數設定定乙個值，最後根據模型計算乙個時間。
4、模型應該是乙個動態的，它像乙個人工智慧模型，你需要持續不斷的訓練它，才能使它真正準確起來。每次的估算都需要記錄，反思估算效果，找出影響因素，加入新的影響項或者調整對應引數。
5、被要求進行估算時間時，我們可以這樣回答：我等會兒回答你。然後花點時間仔細檢查我們在這一節描述的步驟，你總能得到更好的結果。
本節是第三章：基本工具，首節內容，章節介紹裡有一句話：
許多新程式設計師都會犯下錯誤，採用單一的強力工具，比如特定的整合開發環境（ide），而且再也不離開其舒適的介面。這實在是乙個錯誤。我們要樂於超越ide所施加的各種限制。要做到這一點，唯一的途徑是保持基本工具集的「鋒利」與就緒。這裡強調可列印含義是字元時經過編碼的可閱讀字元，而不是二進位制。這在現在看來幾乎是不用爭辯的，誰還會用二進位制儲存資訊，但當時計算機算力和儲存都有限，純文字會佔據更多空間，解碼會耗費算力。但源於技術的發展，這些都是可以忽略不計了。
2、純文字的優點之一：保證不過時。這一點需要我們擴充套件純文字能夠自描述。自描述的含義是它自己能告訴我們它的含義。
123-45-6789
123-45-6789
上面的例子中下面一條就是自描述的，我們能通過 ssno 推斷出這裡存的就是社會保障號，另外根據這一標記我們可以很輕鬆的將對應內容提取出來。
3、另外兩個優點是槓桿作用和更易於測試。這裡說的是我們可以利用各種工具 diff、fc、git，或一些語言例如 python 等對純文字進行各種調整和檢視工作。
1、對於操縱文字的檔案的程式設計師，命令 shell 就是工作台。我們可以利用 shell 啟動各種應用、搜尋檔案、查詢系統狀態，甚至還可以構建複雜的巨集命令，完成各種常見活動。
2、對於習慣 gui 的開發者來說一直使用 shell 有些極端。gui 的好處是所見即所得，但他的缺點卻是，所見即全部所得。gui 環境通常受限於它們的設計者想要提供的能力。
3、比如我們想要做一件事：在乙個**倉庫裡，查詢上週沒有修改過的，使用了 awt 庫的 j**a 檔案。
如果使用shell，可以執行：
find . -name 『*.j**a』 -mtime +7 -print | xargs grep 'j**a.awt'如果使用 gui，你可以設想一下，這個過程會很麻煩，也很容易出錯。
4、shell 可能比較晦澀，但是掌握之後它能很大程度提高你的效率。shell 可以做各種組合搭配，然後構建乙個命令序列，讓常做的事情自動化。
從小工到專家1
1.如果我確實同意要為某個結果負責，就應切實負起責任，當出現失誤時，誠實地承認它，並給出選擇。2.預先制定應急計畫，原始碼必須備份。3.出現問題不要向老闆說藉口，而是挽回的方式。4.不僅要留心大圖景，還要持續不斷地觀察周圍發生的事情。5.讓使用者參與決定所製作的東西何時是足夠好。6.不要許諾不可能兌...
06從小工到專家6
1 編寫規範是一項重要的職責，但問題是很多人可能會陷在這裡，不斷地增加規範項。我們可以做這樣乙個嘗試，寫乙份簡單的描述，告訴別人怎樣繫鞋帶。這可能是乙份並不能幫助他人的描述，因為對有些事情 做 勝於 描述 因為無意識的行為更快，考慮規範反而會拖慢進度。2 對待開發文件也一樣，不要編寫過於詳細的規範。...
《從小工到專家》閱讀筆記一
今天閱讀了從小工到專家的第一章 注重實效性的哲學，可能由於自己從來沒有進行過真正的專案開發，所以對於書中講解的內容並沒有理解的那麼深刻，所以在這簡單陳述下自己閱讀完的感悟。我的原始碼讓貓給吃了 是流傳在程式設計師之間的經典語句。作為一名合格的程式設計師，我們要具有程式設計師該有的素質。負責便是其中重...