對於文件的總結，本該在軟工之後，文件書寫完後進行的。可之前，對於文件的書寫沒有多少感覺。師傅檢查了一遍我的文件，並對文件存在的問題及我的情況進行了分析，讓我重新改一改。這一遍，讓我對文件有了很多新的認識。

      為什麼要寫文件？

      這可能是很多人都想要問的一個問題。為什麼要寫文件呢？前前後後，那麼瑣碎，那麼麻煩，要是想研究個什麼方案，大家開個會，當面研究、解答不是更好？看似想法不錯，其實不然。或許，我們的前輩也看得到，也知道寫文件很麻煩，可為什麼還是要寫呢？第一，文件不只是給開發人員看的。可能開發人員對於軟體自身瞭解的非常多，可對於從未接觸過軟體的呢？有時候，你不覺得文件就像藥品或者手機等電子產品的說明書嗎？買藥時，不瞭解藥性，不知道吃藥需不需要忌口，不知道藥品有沒有副作用，孕婦、兒童是不是不能吃，藥量是多少，等等諸如此類的問題，有個說明書，那一切不就迎刃而解了？第二，文件可以指出一個既定的目標，讓設計團隊朝著那個方向走，不至於跑偏，這對於整個設計團隊來說，具有指導作用。第三，要知道，有很多專案是需要合作開發的，一個人是獨立完成不了的。一大堆人聚集在一起，要各司其職的把自身任務完成好，再將各自所屬的任務“組裝”在一起，形成一款優秀的軟體，這個過程是何其的艱難。當很多人聚集在一起，力量是很大，但是思想也開放，如果每個人都按照各自的想法去進行，那麼到最後，開發出來的軟體與最初的設想，很可能就大相徑庭了。

      文件要達到什麼要求？

      可能之前對文件從未接觸過，也不熟知它的作用及含義。文件要達到什麼要求呢？什麼樣的文件才是合格的呢？簡單來說，就是你拿到文件，照著文件，你能敲出與文件描述相匹配的軟體。那樣的文件才是合格的。仔細比對你下，你寫的文件合格嗎？

      我的收穫、經驗總結

      這一遍對文件的更改，讓我收穫很多。之前，就是把文件的模板拿來，不分主次，不分重點，“一視同仁”地“照葫蘆畫瓢”。結果，文件中，該重點寫的地方沒寫好，不該重點寫的也那麼糊里糊塗的寫過去。寫文件時，一定要抓住重點，要分清要具體的文件哪部分是不能忽視並且應該重點對待的，這才是寫文件的關鍵。

      寫文件重點要注意的地方：在這裡挑幾個主要的說一下。比如說寫概要設計說明書時，什麼地方要重點對待呢？一聽是概要設計，當然要在文件中，能描述出整個系統的大致輪廓，這才是最重要。因此，系統概述、軟硬體平臺和系統的網路體系結構是至關重要的。詳細設計說明書中，要在概要設計說明書的基礎上，重點將功能細化描述。例如在機房收費系統中，是如何實現上機操作的？要進行刷卡上機或輸入卡號按上機按鈕進行上機，輸入卡號時要求的數字長度、字元規範、卡號如何獲取等等，細化到一個小功能如何實現都不放過。詳細設計文件，是給程式設計師看的。要讓從未接觸過系統的程式設計師，根據詳細設計文件就能寫出程式碼，那麼你寫的詳細設計文件才算是合格的。在資料庫設計中，重點在於要詳細的寫出表的屬性，其中包括各個表名、每個表下面對應的列名，中文註釋、數字型別、長度、是否為空，是否主鍵、是否外來鍵等等。在需求分析文件中，要重點分析產品面向的最終客戶人群的需要及此人群對軟體效能、品質的需要等。總之，要從使用者的自身出發，開發適用於最廣大使用者需求的軟體，才是最成功的軟體。使用者手冊中，要重點描述如何使用系統即具體的操作步驟。因為使用者手冊是給使用者看的，它就像一個說明書，是給使用者使用時的一個指導。要讓使用者知道輸入什麼，點選什麼，能完成哪些功能等。只有使用者看得明白，才能保證操作。

      以上，對於文件的分析就寫到這裡。對於文件的學習，隨著學習的深入，以後有發現新的、好的想法，會及時更新到部落格中，歡迎大家多提寶貴意見，我們共同進步！