這次主要讀了構建之法的第十一章：分析和設計方法
問題雖然簡單，其實裡面有乙個很淺顯的道理。只要思路找到了，便可以將複雜的問題簡化。列出公式和矩陣就是思路的構建方法之一。所以我們要學會去分析問題，在解決問題的時候分析問題和設計思路往往最為重要。但是，我認為，如果要有這樣的能力，首先，應該積累覺絕對的**量。其次，應該掌握一定的方法，方法和經驗往往是解決問題最快的出路。第三，理應有一顆熱衷於探索並且不屈不撓的心。以下是我從書裡找到的一些分析和設計的方法：
圖形建模表達實體和實體之間的關係：
1.思維導圖：「一圖勝千言」，人們經常用圖形來幫助他們了解概念，強化記憶。思維導圖是其中的乙個例子。思維導圖沒有嚴格的語法定義，一般來說是從圖形的正中開始寫下乙個概念，然後按照繪圖者所關心的屬性擴充套件，幾乎每個人都能馬上開始畫圖。這個看似簡單的工具其實很適合團隊一起討論和理解核心概念——例如，我們的主要使用者有什麼特點、什麼需求。
2.實體關係圖：如果我們著重於表達現實世界中的實體和它們之間的關係，那麼實體關係圖erd是最自然的表達方式。
書中所提到的一些設計方法：
1.形式化的方法
很多軟體需求（例如計算機語言的編譯器）可以抽象為對符號的運算和變換，很多軟體的某些核心功能需要嚴密地驗證，保證沒有問題。一些科學家一直在努力，希望用無歧義的、形式化的語言描述我們要解決的問題，然後用嚴密的數學推理和變換一步一步把軟體實現出來，或者證明我們的實現的確完整和正確地解決了問題。在這個領域乙個比較成熟和經過實踐考驗的方法是vienna developmentmethod（vdm）
2. 文學化程式設計
程式設計師在寫程式的時候，要理解在文件中的需求，同時還要在程式裡寫相關的注釋，這些不同目的的「寫作」各有價值，但是一旦需求或程式發生變化，這些不同的文件很難保持同步。更不用說程式設計師最常見的毛病「我以後會加上注釋的……」donald knuth在20世紀70年代末開始嘗試並提倡literate programming的思想並在自己的軟體專案中身體力行。這一方法和常見的「寫程式，時不時加上一些注釋」相反，它是「寫文件，時不時有些**」。它使用了巨集（macro）來進行抽象和資訊隱藏。通過工具的支援，它的源**可以提取出讓計算機編譯執行的部分以及文件。
對於構建之法這本書自然只是學了一些皮毛，不過在接下來的時間裡，必然細細研讀，這對於正走在程式設計師之路上的我來說，必定獲益匪淺。
《構建之法》閱讀筆記06
最近我們要開始進行團隊合作，所以重點閱讀了 構建之法 與團隊合作有關的部分。首先團隊合作有很多模式，我們應該確立我們的模式，這樣才能更好的分配任務，並且對團隊的每個成員利益最大化。我覺得我們的團隊更像是交響樂團模式，大家都有各自的有點，但是更要跟隨指揮的節奏，這樣才能把曲目演奏好，同樣的，我們的團隊...
構建之法閱讀筆記06
夢斷 06 程式設計師常依賴一種稱為 媽媽測試 的手段，以對計算機一無所知的父母為假象用例，有時甚至請這類使用者親自體驗。這是現在程式設計師的通病，做出來的軟體或許在計算機上是完美無誤的程式，甚至是最優化做快的演算法，但是使用者的體驗和反饋卻並不是很好，這就要考慮到軟體設計的問題了，良好的軟體設計像...
《構建之法》閱讀筆記06
最近我們要開始進行團隊合作，所以重點閱讀了 構建之法 與團隊合作有關的部分。首先團隊合作有很多模式，我們應該確立我們的模式，這樣才能更好的分配任務，並且對團隊的每個成員利益最大化。我覺得我們的團隊更像是交響樂團模式，大家都有各自的有點，但是更要跟隨指揮的節奏，這樣才能把曲目演奏好，同樣的，我們的團隊...