作者：rick1126
email: rickzhang@sina.com
日期：2001-7-14 11:40:05

1.4 起草: 最小的方法

   【程序員和作家的比較】
     
     . 相同點
       思想使用文本形式表達, 表達的結構能確定產品的成功與否
     . 不同點
       作家開發一般是獨立行為, 涉及到時間限制需要非常經濟的使用時間, 拋棄不能帶來重要結果的方法
    
1.4.1 前提

     【劇本式設計方法的兩個重要前提或者說是某些歷史教訓和新的需求使然】

       . 防護: 和過程語言不同, C++具備很多防護, 程序員可以建立自己的防護以創建的程序破壞它的結構, 無論是在創建期間還是在維護期間
       . 辨證: 無論分析的如何透徹, 面對不斷發展的事務, 即便在開發后期有些事務的關系還可能沒有被發現. 快速分析過程和設計過程實現目標系統的測試是很重要的

     【表示方法】

       . 語言是表達事物的最佳方法, 鑒于人類自然語言的發展歷史, 絕對不要在當前階段試圖使用符號系統表達系統設計, 因為后者在重復性, 擴展性方面是遠不及前者的, 很可能增加誤導性, 因為它過于明確和限制了.
       . 好的描述工具應道建立代碼和文檔的聯系
       . 使用熟悉的工具和思維模式非常重要

1.4.2 高概念

     【描述和必要性】

       . 建立的系統無論如何復雜, 都有一個基本的目的, 它服務于哪個行業和應該滿足什么基本需要
       . 高概念對于項目定調,非常重要. 
       . 高概念的描述從一開始無需非常準確

1.4.3 論述( treatment )

      . 劇本( 系統描述 )的論述即故事概要, 即高概念的外層
      . 計算機系統發展高概念和論述的最好途徑就是組成一個小組, 該小組具備一個寫能力的輔助工具. 
      . 在集體討論中能夠提出建立, 輔助工具負責表達各自的思想, 不給出評價, 僅僅是力圖保持這些思想的清楚和通暢
      * 論述變成了出手對象發現的起點和設計的第一個雛形, 也能夠在擁有輔助工具的小組內完成

1.4.4 結構化

      對于系統, 結構是關鍵.

     【組織系統】
       
       . 第一層: "高概念", "論述", "對象", "設計"的起始點
       . 第二層: 為第一層發現的對象
       . 第三層: 增加的對象接口

       . 使用描述性語言, 不使用圖片, 會議討論過程不受創作該描述的速度限制


     【特征: 發現初始化對象】

       . 論述: 名次 + 動詞
         名詞 ==> 類
         動詞 ==> 類的方法或者系統設計的過程
       √這是一個不斷反復的過程, 不指望程序一下子完全理解問題

       . 如果一個類是從另一個類繼承過來, 則其第二層子段應當盡可能靠近地放在其基類的后面, 它的子段名稱應當顯示這個繼承關系
       . Occam's Razor方法: 選擇一個最簡單的進行類構造, 因為向一個類添加元素非常容易, 但是隨著時間的推移丟掉元素就困難了
            
     【情節: 初始化系統設計】

       . 情節: 系統活動
       . 根據小組成員提出的可能的系統活動進行分別記錄, 不要求將它們即可建立和系統的聯系
       . 參與人員面可以很廣, 設計人員, 市場人員, 管理人員都可以出席, 目的在于"通訊" -- 對于整個系統的共識, 也可以提高大家的積極性.
       . 可以為每一個子情節歸納出基本的條件過渡描述, 將來這些就成為了最初的代碼實現目標

1.4.5 開發

      從粗設計到編譯代碼的最初轉換, 編譯代碼可以證明或者反證設計. 這是一個不斷反復的過程. 通過對于代碼中的結構或者有關文字的改變重新產生文檔. 設計文檔成為項目進展的報告工具.

     【初始翻譯】

       . 文檔第一層, 對象描述
         - 根據"對象"產生文件頭, 即系統程序頭文件, 每一個對象都是通過一些類型實現功能的. 
         - 將文檔分割成為幾個部分, 在每一個部分上工作

       . 文檔第二層, 類型抽象
         - 自動產生類聲明
         - 相應的次層描述獲得成員函數和變量聲明

       . 文檔第四層, 情節
         - 每一個子情節產生一個獨立全局函數, 供入口函數main()使用, 或者是main的一段.

     【代碼產生】

       . 為"對象"段的每一個類產生獨立的類聲明頭文件
       . 為每一個子情節產生系統過程聲明頭文件
       . 使用概要標題標記每一個子情節, 類和方法, 諸如: //#[1]...
       . 接口和情節在此時應該是可以編譯但是不可連接的, 因為沒有代碼實現, 僅僅用于語法檢查
       . 適當補充文檔, 如果類或者子情節發現需要變化

1.4.6 重寫

     【目的】

       . 完善程序, 更新文檔

     【時機】

       . 因為軟件開發是預約服務, 不可避免地需要進行版本的控制發布


1.4.7 邏輯

     【責任】

       . 經常性的整理和維護設計文檔是項目領導者或管理者的責任
       . 項目組或者個人負責對于文檔的一小部分的維護( 代碼和注釋 )


〖個人理解〗

     這一小節可以主要提出了兩個觀點, 語言的作用和劇本方式. 
     
     其實自從開始從事編程以來我個人就有一種使用圖形或者圖片語言的方式表達的傾向, 看來我是錯了, 我當初就是因為語言的表意的不明確性而希望使用更加直觀和形式化的語言描述系統. 顯然我忽略了一點就是人的認識規律和對于事物認知的局限性, 語言的魅力其實就是閱讀的因人而異, 不斷地認知和修改才是集體認知系統的正確過程, 簡單的圖示, 往往容易給閱讀者一種先入為主和依賴性.

     系統設計就是編寫劇本, 我以往對于系統設計過于程式化, 其實這也是過程化設計的一個通病, 總是希望在完整了解系統需求以后閉門造車, 顯然犯了非辨證的毛病.

～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～