軟體開發與文檔

       在學校裡加入的那個項目差不多也進行了有半個月時間了。

       這半個月時間體會到最為深刻的，便是軟體文檔的重要性。

在項目開始前，我們就被要求用一個月時間熟悉自己負責的模組-----整個軟體分成了很多模組，當然我個人覺得我們這個項目很容易模組化---用戶端和伺服器端不可能在同一模組---熟悉過後，需要每個人寫一分概要設計的文檔。這分文檔需要描述模組大致的功能。

項目開始時，組內有個小子被叫去聽一個持續一星期的軟體工程課程。講課的是一個公司裡的。大致內容，就是用7天時間開發一個管理系統，那人把文檔分發下來時，-----一分詳細設計文檔，被分成N多分，每人一分，每人負責幾個表單，文檔裡把設計描述的太清晰了，幾乎清晰到一個表單上的一個按鈕應該執行什麼操作的程度。聽幾個老師說，在公司裡就是這樣，很多時候程式員也就是單純地敲代碼而已。

後來有一次又說到國內的對日軟體外包，據老師說，日本人給中國的軟體設計文檔，也足夠詳細，詳細到虛擬碼程度，基本上一句話就能對應一句代碼！真夠誇張！

項目進行了一周后，項目老大把我們的概要設計文檔全推翻了。--事實上我覺得也該推翻。然後他起草了另一分文檔，關於用戶端的，所有表單，每個表單大致的行為，雖然沒有上文說的那種文檔的詳細，但是也足夠做為編碼的指引了。----照著文檔編碼，確實很容易。而且很利於項目總體的和諧。

在我自己寫遊戲代碼的過程中，雖然早就在寫文檔，但始終沒達到上文那些文檔的詳細程度。以OOP方式編寫程式，我覺得我漸漸忽視了一個東西， 那就是程式真正的邏輯！以前用純碎的面向過程的方式寫程式時，思路全集中在程式的主要邏輯部分，寫代碼時就針對著解決這個邏輯寫。這樣寫出來的程式，可以算做一個DEMO，但是真正擴充起來，卻真的是很困難。相比而言，用OOP的方式寫，擴充性的優點就顯得很突出了。我想，這也算作物件導向的一點好處。但是慢慢地，在設計一個OO系統時，我把重點都放在了設計類，構件對象上，真正的邏輯部分，反而被忽視了。這正是在組裝所有對象時變得困難的原因所在。

也許，找一個系統點的方法來做這一切，會更容易一點。是時候系統地接觸軟體工程方面的知識了。