本節書摘來異步社區《挖掘管理價值：企業軟件項目管理實戰》一書中的第2章，第2.4節，作者： 徐勤 責編： 楊海玲, 更多章節內容可以訪問云棲社區“異步社區”公眾號查看。

2.4　軟件設計過程

挖掘管理價值：企業軟件項目管理實戰
軟件設計是根據需求的內容，運用計算機理論、技術和工具將其合理地、有機地、具體地轉化為功能，并演示其實現的方法、過程和結果。設計人員在理解了用戶的需求之后，首先在自己的腦海中會有一個大致的概念和思路，然后考慮如何去實現這些功能，當然這需要一定的專業知識和實踐經驗。這里就不闡述軟件或數據庫設計的理論知識了，而重點介紹如何將設計人員腦子里對軟件的設計和理解反映到文字、圖形和流程上，使得用戶可以了解計算機是如何實現他們的需求的。我們用圖 2-9 來說明軟件設計的過程。

如圖 2-9 所示，用戶的需求仿佛就是混亂的揉合在一起的愿望和想法，經過設計人員的處理、分析和設計，就變成了清晰的、系統的、有效的軟件功能或界面。

軟件設計是一項創造性的工作，就好比繪畫一樣，有一定的規律和章法。盡管一些教科書闡述了一些基本的理論和方法，但是這些遠遠不夠。在實踐中你會發現，軟件設計是一個大熔爐，不但會用到計算機的理論，甚至其他科學和藝術范疇也會融合進來，譬如美學、音樂、財務、機械工程、數學等。如果只局限于計算機的理論和方法，很難設計出一套靈活、有效、精致和滿足用戶體驗的軟件，因此軟件設計人員要善于綜合運用各種知識和經驗，跳出束縛，大膽創新。

2.4.1　軟件結構設計

軟件是個復雜的系統，是眾多功能、操作和數據的結合體，就好比一幢大廈，里面有電梯、房間、水管、電路、大門、空調等。在設計軟件的具體功能和界面之前，先要理順軟件的結構，否則就像盲人摸象一樣無從下手。

軟件的結構一般按照功能來進行分類組合，這里給出一個圍墻模型，如圖2-10所示。

在此圖中“數據處理”是核心模塊，所有的數據計算和處理都是它來完成，通常也是三層架構中的邏輯層。圍繞著“數據處理”模塊的有“用戶操作界面”、“數據輸出界面”、“數據接口”、“系統設置界面”和“系統管理界面”模塊。

一般而言，用戶分為三類：普通用戶、超級用戶和系統管理員。他們在系統內的分工和權限是不同的，因此他們的界面、操作方法也不同。“用戶操作界面”模塊是普通用戶使用的，在此模塊中，普通用戶只能進行訪問、查詢和輸入數據等一般的操作，此模塊也是軟件數據的主要來源窗口。“系統設置界面”模塊是超級用戶使用的，在此模塊中，超級用戶可以修改系統內的業務邏輯和普通用戶的權限。“系統管理界面”是系統管理員使用的，在此界面中，系統管理員可以修改系統的數據算法和結構、用戶的權限、以及系統流程等。

“數據輸出界面”模塊是各類報告、報表、數據導出和打印的界面。“數據接口”模塊和“數據輸出界面”模塊類似，但是它更多的是一種無界面的機器與機器之間進行數據交互的模塊，因此把它單列出來。在界面的外圍是“用戶登錄”和“用戶退出”模塊，主要是負責在用戶使用軟件的時候認證用戶信息和在用戶關閉軟件時保存相關信息。

2.4.2 軟件界面設計

界面的作用就是提供軟件和用戶交互的窗口，通過用戶在界面上的操作，軟件就知道用戶行為和需要什么，因此界面的設計目的就是要解決什么樣的控件布局和組合可以讓用戶獲得所需要的東西。很多設計人員在做界面設計時往往走入一個誤區，認為界面越華麗就越好，功能越多越好，其實不然，固然華麗無錯、功能強大是好，但是卻違背了設計的“夠用”和“適用”原則。盡管青菜蘿卜各有所愛，大部分的用戶更偏向于簡單好用。那么到底什么才是“夠用”和“適用”呢？

“夠用”是指除了用戶需要的功能，不要額外地增加多余無關的信息、圖片、內容和功能。

“適用”是指界面上提供的信息、圖片和控件等是適合和方便用戶使用的，不會讓用戶覺得不會用、不知道怎么用，或者難用，有的時候簡潔反而更有效。

當然“夠用”和“適用”原則也不是一蹴而就的，就像探尋迷宮一樣，經過多次嘗試才能找到最短的路徑，界面也是通過不斷的修正才逐漸趨向于“夠用”和“適用”的。同時也不是一成不變的，隨著用戶需求的變化，“夠用”和“適用”的標準也在變化著，可能以前的“夠用”和“適用”的界面變得不“夠用”和不“適用”了，也可能以前不“夠用”和不“適用”的變得“夠用”和“適用”了。總之，用戶的體驗才是衡量是否夠用和適用的標準。

案例8：適當的界面設計
案例情景
金輝機械加工公司希望機床操作工人使用系統來輸入工作單的信息。系統的設計要求是讓操作工盡可能地快速和準確操作，不會影響到正常的工作，另外工作單上有工單編號和型號條形碼。設計人員設計了兩種界面用于工作單登記，如圖2-11和圖2-12所示。

案例分析
我們對比一下這兩個界面，其基本的框架是一樣的，只是內容和頁面的元素不同。就功能而言，這兩個頁面都能滿足用戶的需求，即都能完成工作單的登記，也不存在哪個設計好與壞的問題，我們所要關注的是“是否夠用和適用”。這兩點的對比如表2-11所示。

因此經過綜合評估，界面一最符合當前軟件的需求，即滿足了快速、高效和簡單的要求。當然界面一并不是完滿無缺的，它還需要在今后的使用中不斷完善。界面二盡管也可以滿足功能，但在當前情況下，不是完全適用，或許在其他場合可以使用，譬如產線領班的管理界面或是公共區域使用平臺等。

案例啟迪
對于企業應用的軟件來說，實用是第一主義，而對于商業應用的軟件來說，吸引力是第一主義，因此在不同的應用場合，軟件的設計要符合實際應用場合的情境而不是設計者的意愿。

2.4.3 軟件數據設計

數據設計主要是定義數據的格式和結構。這里說的數據不光是關系數據庫里的數據，還包括廣義的任何軟件處理的數據，如字符、警告信息、文件或語音等。設計人員往往只關注數據庫結構的設計，認為數據庫設計好了，軟件的數據處理就成功了。要知道，不是所有的數據處理都是依賴數據庫完成的，也不是所有的數據都用數據庫來處理就一定又快又好。

那么我們在做數據設計的時候，應該注意什么呢？

• 精煉的類型。數據的類型有很多種，不同的開發語言和數據庫都有自己特有的數據格式。為了加強軟件的適用性和擴展性，在沒有特殊要求的情況下，最好使用通用的數據格式，而不是某些互不兼容的格式。如果一旦使用了特殊格式，會增加開發的成本，因為可能需要開發額外的代碼來解釋和轉換數據。特別是在軟件投入使用后，可能面臨著數據無法轉換的風險，有很多軟件就因為這個技術難題而銷聲匿跡了。
• 統一的格式。同樣類型的數據使用同樣的格式，如日期類型的數據格式為“yyyy-MM -dd hh:mm:ss”，那么所有的日期數據都應該保存為這種格式。這樣做的好處是，一組代碼就可以讀取、計算和保存所有同一類型的數據，在顯示不同格式的日期格式時，如dd/mm/yyyy，可以使用系統函數來轉換。統一的格式將促使代碼變得精煉高效，其運算速度也是最快的。相反，各種各樣的格式勢必需要多種代碼來支持其相互之間的轉換，如果僅是多一兩行代碼，倒也不會對軟件效率產生太多影響，可是如果有成千上百的格式轉換代碼，情況又會是怎樣的呢？ - 恰當的長度和精度。數據需要適當的長度和精度，如果太短，則以后難以擴展，如果太長又浪費存儲空間。例如，貨幣類型的數據，精度在2～4位為宜。 - 自定義類型。創建自定義的數據類型可以有效地提高數據處理的能力。 - 保護機制。為了避免數據運算時產生錯誤或溢出，對數據進行必要的校驗，如不能為空或NULL、滿足一定的長度、只能有數字或字符中不能有空等。 - 合理的索引功能。頻繁讀取的數據應該建立索引，但是過多的索引會降低數據的性能，因此選擇數據結構和類型的時候應該考慮索引的平衡。

下例是因數據庫設計導致的數據遷移問題。

寶碩公司在2004年開發了一套生產管理系統，根據當時公司的策略使用了Oracle 9i作為數據庫。在2010年的時候，寶碩公司被實達公司收購，實達公司的策略是使用微軟的SQL作為數據庫。因此，需要將該系統的數據庫由Oracle 9i轉換為SQL數據庫，在進行轉換的時候，發現原有的一些數據格式無法轉換，具體如圖2-13所示。

如JOBS表中的ROUTINE_IDS字段的數據類型是NCLOB，是Oracle的一個特殊的對象存儲類型，并不能直接轉換到SQL數據庫中。為此需要開發專門的數據轉換軟件或腳本，這將大大增加數據庫轉換的成本和時間。如果在當初設計的時候，可以使用其他常用的類型或使用其他表格來保存一對多的關系，則不會有這些額外的工作。

數據庫的設計應該考慮到軟件的生命周期和數據庫技術發展方向，鑒于新版本總是兼容舊版本，沒有特殊需要，數據格式盡量使用通用格式，對于有特殊要求的數據，可以用代碼或自定義類型來轉換數據。

2.4.4 軟件功能設計

功能實現了信息的輸入、處理和輸出，同時它要求一定的交互操作來觸發或激活功能的運行。無數個小功能（或者說是小算法）匯集成全部的功能，實現軟件的作用。在設計功能的時候，我們應該注意以下幾個方面。

獨立性。一個功能只解決一個特定的問題，如加密和解密屬于同一問題的兩個方面，不要期望開發出一個全能的或者是萬能的功能，這既不可能也不現實。特定的代碼實現特定的功能，其好處在于代碼精煉、執行效率高、交互性好、開發成功率高以及維護成本低。
多態性。一個特定的功能可以解決一個問題的多個方面或形式，如加密解密功能既可以解決64位加密也可以解決128位加密，既可以明文加密也可以圖形加密。
自然性。功能的具體操作應該符合人使用的自然習慣，如按鈕點擊次序應該從左到右。

2.4.5 軟件接口設計

接口是軟件與軟件、機器與機器、數據庫與數據庫之間的數據交換窗口。不同軟件和設備之間是不能直接簡單地進行數據交換的，一定要進行特定的轉換和處理以后才能保證交換的成功和正確。開發人員一般認為只要拿到其他軟件或系統的API（Application Programming Interface）或者SDK（Software Development Kit）就可以進行數據交換了。其實不然，如果接口沒有設計好，就直接開發代碼交換數據，很可能無法交換數據，或是交換過程不穩定，或是可以交換但是效率低下。因此設計好高效率規范的接口非常重要。

在設計接口的時候，應該遵循以下原則。

• 可獲取。需要交換的數據必須是可獲取的，而且要知道哪些數據是可獲得的？是如何獲得的？需要什么樣的權限？
• 可轉換。因為交換的數據格式可能是不同的，甚至是迥異的，所以獲得的數據需要進行必要的轉換，而且這種轉換又要求是可行的和正確的。因此，在設計的時候就要定義好轉換映射表和轉換邏輯。
• 可驗證。如果數據交換是要寫入數據，則接口應該設計數據驗證的功能，或者是由對方系統的API來驗證。如果數據沒有經過有效的驗證，將導致嚴重的后果，甚至將原來好的數據篡改變成混亂的數據。
• 可調試。無論交換是讀取還是寫入數據，都要求其過程是可調試和可監控的，只有提供了可調試的接口，才有可能保障數據交換的質量。
• 回饋機制。如果交換是寫入數據，當數據交換以后，接收數據的系統需要提供反饋信息給發送數據的系統。回饋信息包括成功或失敗的狀態和理由。回饋信息有助于發送系統的用戶知道數據交換的情況和及時處理異常情況。
• 回滾機制。如果交換是寫入數據，一旦數據交換失敗，被修改的數據可以返回到修改之前的狀態。
• 負載平衡。數據交換不能以犧牲系統的使用性能為代價。在設計接口的時候要評估數據交換對系統的影響，如運行時間、運行頻率、網絡通信、數據吞吐量等。開發人員有的時候只考慮技術層面，為了實現接口而開發接口，卻忽視了關聯影響。設計人員應該明確提出負載平衡方面的要求，避免發生接口拖累系統性能的情況。
• 可追溯。凡是通過接口進行交換的數據處理，都應該有歷史記錄，以方便追溯數據和了解當時的情況。IT審計非常重視數據的可追溯性，設計人員應該對此給予充分的考慮并提出明確的要求，以滿足審計的要求。
  下例是因接口設計導致的數據交互問題。

華天（上海）公司使用Oracle公司的EBS作為本公司的ERP系統。為了能夠節省大量的工作單打印紙，同時可以將紙張放入物料盤，計劃將A4的紙張改成A5的尺寸。因此需要開發一套簡單的打印工作單的軟件，有關工作單的基本信息，BOM和制程將從ERP的數據庫里定期同步過來。ERP的數據庫服務器位于其母公司的總部美國洛杉磯，總部和上海分公司之間用2MB的帶寬進行專線通信。

開發人員根據這個要求開發了多個數據庫腳本，如表2-12所示。

這個接口設計完成后，通過了測試，也能夠正常使用。但是在使用了1個月后，有人反應少數工作單的信息沒有及時更新，導致投產數量和原材料領用發生錯誤，增加了報廢。開發人員通過調試和檢查，再次確認代碼本身是正確的。測試環境和正式環境的差別在于，測試環境沒有那么多的數據量。因此懷疑問題出在接口的同步上，通過將腳本運行的間隔時間調整為每2小時，則不再發生此類問題。但是如果運行間隔時間為2小時，則工作單信息更新不夠及時，生產線要等待最少2小時后才能投產最新的工作單，會影響到產量。于是開發人員再三模擬，最后發現，只有當大量工作單出現的時候，才會發生這種情況。由于大量的工作單信息需要更新，加上網絡帶寬有限，結果前面一個腳本還沒有執行完畢，后面一個周期的腳本又要執行了。開發人員于是將接口的工作機制做了如下修改。

• 優化腳本，將單個工作單的執行時間提升20%。
• 限制每次腳本更新的工作單數量，最大為100個。
• 將腳本的運行間隔時間調整為每45分鐘一次。

通過上述改進，基本杜絕了工作單信息缺失和未更新的情況。由此可見，接口的質量和效率不僅僅取決于代碼和邏輯，還取決于環境的影響。

2.4.6 軟件設計評估

軟件設計完成以后，是否符合用戶的需求呢？這就需要和用戶一起來確定。由于設計人員和用戶出于不同的視角，因而他們對設計的意見不盡相同，有的時候還會爭執不下。那么如何評估軟件設計的成果呢？唯用戶意見為準則是不可取的，唯設計人員意見為規范也是不客觀的。最好的方法是采用打分制進行客觀的評估，令雙方心服口服。

軟件設計的評估的考察點由以下幾個方面組成。

• 可用性。可用性是指設計的功能都是可以實現的。
• 易用性。易用性是指設計的功能都是容易操作的。
• 完全性。完全性是指設計的功能所涉及的內容是完全的，該顯示的都顯示，無關的信息都不顯示。
• 完整性。完整性是指設計的功能是完整的，在一個整體內的，沒有缺失，沒有遺漏。
• 一致性。一致性是指設計的功能，界面和操作步驟在一定程度上是保持一致的。
• 延展性。延展性是指設計的功能具有再次開發和擴展的能力。

只要滿足了這6個基本要求，就可以認為軟件設計是合格的。當然光是合格還不夠，好的軟件設計應該是超出用戶預期的，因為這些設計可能是用戶潛在的需求，不是必須要完成的，這并不和前面說的“夠用”和“適用”原則矛盾。那么怎樣才能超出預期呢？這里給出一些建議以供參考。

• 交互性。交互性是指在現有的功能上提供更多的反饋信息，如錯誤提示或中間過程，這樣有助于用戶理解數據和結果是怎么來的。
• 智能化。智能化是指在現有的功能上分析用戶的常用操作和需求，將這些因素提煉出來，進行固化和總結。在用戶使用時，提供自動計算和統計，即智能化操作，這樣將有效地提高用戶的工作效率，避免重復操作。
• 個性化。個性化是指在現有的功能上提供可以讓用戶自由選擇的一些算法和操作方式，并把這些特點記錄下來，方便用戶快捷地使用。
  下面的例子說明了如何評估軟件設計的內容。

明志公司委托一家軟件公司開發了一個簡單的倉庫入庫和領料系統。軟件公司完成了設計，明志公司電腦部的軟件經理對供應商提供的設計方案進行了評估。評估表的部分內容如表2-13所示。

表2-13中的每項評分范圍從1到10，10為最符合，1為最不符合。如果某項沒有必要進行評估，則可以不計分。綜合分為計分項的平均分。

通過對設計頁面和功能的打分，可以有針對性地、客觀全面地評估設計結果，避免了人為的因素和主觀的喜好。

2.4.7 軟件設計文檔

軟件設計文檔是對軟件設計思路和方案的記錄，該文檔通常包括以下內容。

• 術語。術語包括兩方面的內容，一是特指業務中的專業術語，如折舊、四班三運轉等，因為不是每個開發人員都非常了解和精通業務，詳細地說明術語，有助于開發人員理解業務。此外，軟件的術語也需要做一定的解釋，如異步處理、多線程、組策略等，因為用戶對軟件的認知程度是不一樣的。
  軟件結構。說明軟件的整體結構，主要模塊的組成，各個模塊的作用和相互之間的聯系。
• 流程說明。流程對于軟件開發至關重要，如果把軟件比作是身體的話，流程就是血液，只有流程對了，軟件的功能才對。把流程用圖畫的形式表現出來，可以清晰地說明流程的來龍去脈，方便開發人員理解，這樣軟件的功能才能符合用戶的實際需要，同時也有利于和用戶確認設計的正確性。
• 界面。界面是用戶和軟件交互的介質，將基本的界面用圖畫的形式表現出來，可以讓用戶和開發人員更明確地知道軟件提供了什么內容和功能，是否和用戶的預期吻合。界面上需要填充一些必要的數據，當然可以是一些虛擬的數據。
• 操作步驟。說明界面操作的步驟，使用戶明白界面中元素、控件是如何使用的，例如如何查詢數據、如何保存、如何修改等。用戶通過了解操作步驟能夠判讀軟件設計的功能是否方便，是否符合習慣，同時讓開發人員明白如何實現界面的功能。
• 計算方法。說明數據計算的方法，如公式、條件、例外等，如果能夠附上推演的細節則更有助于用戶確認和開發人員理解。
• 數據結構。說明數據的關系，特別是關系型數據庫各實體之間的關系，以及數據的格式。
• 數據接口。說明接口的作用，鏈接的平臺或系統，以及數據輸入和輸出的方法。為了保證數據接口被準確地使用，應該提供規范的數據示例。
  技術要求。說明軟件開發使用的技術類型，如開發語言、腳本類型、數據接口、運行的技術要求，如服務器操作系統的版本、語言要求、字符集、磁盤空間大小和速度、內存大小、數據庫的版本、存儲路徑、數據備份要求、客戶端設備的型號、打印機的型號等。其中的一些參數將直接影響到軟件性能和質量，比如32位還是64位，單一語言還是多語言顯示。

案例9：從用戶的需求出發提升軟件設計
案例背景
斯特軟件公司專門為全國的廚具制造商提供電子商務銷售平臺，該平臺運行了一年多后，月度注冊用戶和銷量始終維持在1萬人和40萬左右，連續幾個月都沒有顯著增加。投資方對于平臺的業績非常不滿意，希望盡快改變這種現狀。斯特軟件委托京通咨詢公司通過多種渠道和方法收集用戶的使用體驗，經過大量細致的分析和比較，發現問題主要集中在以下三個方面：

（1）商品分類方式不適合。根據數據庫的追蹤數據顯示，只有2.1%的用戶在打開首頁后能夠在3次點擊內（含第3次）完成訂單。大部分客戶在打開首頁后就放棄了繼續瀏覽，原因之一就是首頁的商品分類菜單方式。客戶一般出于兩種目的瀏覽購物網站，一是無目的性地隨便逛逛；二是有目地性地購買某個商品。對于第一類客戶，商品的準確分類不能起到很大的吸引作用，因為客戶的關注度不是商品的規格，而是商品的特點。對于第二類客戶，因為他們有明確的購買目的，所以希望在第一次看到菜單時就能找到自己所需要的分類，如果經過第二次嘗試還是沒有找到所需要的分類，絕大部分的客戶會放棄購物。

（2）“加入購物車”按鈕位置不合適。最初的設計思想是，為了多給商品的照片和規格留出顯示的位置，“加入購物車”按鈕被放置在右下角。但是根據Complete公司對全球多數電子商務平臺的調研的資料顯示，“加入購物車”按鈕的位置會直接影響到用戶下單的第一意愿，以Wal-Mart和Target網站為例，其不同的“加入購物車”按鈕的位置，導致“點擊成交率”差異為9%左右。這就意味著如果客戶喜歡該產品，但是因為沒有注意到“加入購物車”的按鈕而沒有能夠在第一時間下單。

（3）相同頁面過多。即使是不同品牌、不同類型和不同包裝的廚具，不僅其頁面布局相同，絕大部分的文字內容也是相同的。明顯不同的地方只有品名和規格，商品描述部分由于使用了嵌入框架技術（Iframe），其代碼部分是通過另外一個頁面（不同的URL）傳遞的。Google 對超過25%以上不同內容的網頁才會認為是獨特的網頁，才行收錄。因此在網站搜索方面，很多商品被引擎算法過濾掉，大大地降低了無目的性用戶搜索到商品的機會。這是當初為了節省開發成本而始料未及的。

案件分析
斯特軟件公司組成專門的業務改善小組，進一步完善平臺結構和功能。改善小組針對京通公司提出的三點問題，逐項給出了改進的方案。

（1）首頁分類菜單重新設計，不再以品牌為一級分類，改成按商品功能來分類。由于品牌認知度的不同，客戶的第一動作就會去點擊自己熟知的或者是排位靠前的品牌。但是從品牌代理的角度而言，一兩種知名品牌對于銷量的貢獻并不是很大，相反有些小品牌的利潤率卻是很好。另外如果知名品牌的商品不能經常性地推陳出新的話，客戶很快就會對平臺失去興趣。如果去除品牌的分類，在同一類商品中顯示所有品牌的商品，將豐富頁面的內容，同時多個品牌商品的不斷更新也將滿足客戶嘗鮮的心理。按照商品類別分類的另一個好處是滿足了有目的性購物客戶的快速定位要求。

（2）將“加入購物車”按鈕放置在商品標價的下方，網頁中部突出位置。無論客戶是否對商品滿意或者最終是否下單，都給以客戶下單的意識驅動，增加客戶購物成交的可能性。

（3）改變商品描述頁面的代碼，在保持總體風格一致的前提下，區別性地顯示商品內容，對于不同類型的商品，使用不同的描述模板和主題顏色。依據商品的特點，增加精煉的廣告性描述語。去除Iframe的結構，將所有HTML代碼通過一個URL傳遞到客戶端的瀏覽器。

平臺開發組根據改善小組的意見，加上其他改進措施，很快推出了新版本。新版本上線后，給人以全新的感覺和體驗，用戶注冊數量成倍增長，用戶訪問變得越來越頻繁，銷售量有了明顯提升。

案例啟迪
軟件的設計不是一成不變的，一旦它不能滿足業務的要求，就必須重新評估和做出調整。調整的原則依然是面向用戶的“適用”和“夠用”的原則。

案例10：從業務的角度出發提升軟件設計
案例情景
寶碩公司被收購以后，其企業的文化也逐漸受到新公司的影響。新公司的一個顯著特點就是業務管理完全依賴于系統數據，系統提供了強大的數據分析和處理功能。因此，寶碩公司的新管理層團隊希望現有的系統可以提供更多智能化的和人性化的功能。開發人員經過收集和分析需求，結合過去用戶反饋的一些問題，覺得現有的系統在以下幾個方面可以增加一些更方便的功能，如表2-14所示。

案例分析
多從用戶的角度考慮，就能發現很多有價值的改進空間。就好比房子，已經裝修好了，只要添置家具和家電就可以住人了，軟件本身就提供了堅實的使用基礎，只要不斷地在細節方面改進，軟件設計就能做到出類拔萃。

總結

以上是生活随笔為你收集整理的《挖掘管理价值：企业软件项目管理实战》一2.4　软件设计过程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。