關于敏捷開發(fā)的26個心得docxdocx-資料下載頁
2025-07-17 17:38本頁面
【正文】 以使程序變的可配置。通過配置文件來改變軟件行為所產生的后果是不過控的。XML的誕生促使了一系列的特別的自定義的‘腳本語言‘的出現，人們試圖通過文件的配置以讓最終用戶‘編程’來控制軟件的功能、避免重新編譯。這種設計上的缺陷是：軟件里的各種操作的準確定義在脫離了具體上下文的特定實現的情況下不可能被準確的定義。這些各式各樣的腳本型語言只是對那些對軟件代碼的內部工作機理有著相關的知識背景的人才會價值。所以，真正的最終用戶是不可能知道軟件的內部工作機理的，不可能推理出這些復雜的指令組合會產生什么樣的預期結果。腳本有它的用途，也不應該被抵制，但設計人員必須以非常非常安全的方式使用它們，盡可能使用現有的語言，必免使用新發(fā)明的語言?！鲋挥挟敎蕚浜昧藢崿F和測試才去確定設計。我應該有一個總體的認識我們要做什么，應該有個總體架構目標，而不是詳細設計、詳細的具體方法的實現，只有當開發(fā)迭代到一定程度后、足以讓我們定下設計細節(jié)后才去把它表現成文檔。詳細設計只應該包括當前需求用例中需要覆蓋的部分。軟件開發(fā)中最大的浪費就是你花時間設計出來東西后被告知不需要了，或者是你的設計一開始就建立在錯誤的假設上。■軟件是可塑的。軟件不像蓋房子，我們可以輕易的改的面目全非。無數事實表明軟件比它的規(guī)格說明書善變的多。而且，軟件產品和設計之間的互動明顯比規(guī)格說明書有效率。所以，你應該直接實現你的設計，這樣客戶就能很容易明白你的設計細節(jié)。當發(fā)現有問題、要改變設計時，修改軟件要比修改文檔容易的多。更重要的是，當客戶看到了能運行的程序后，你也就更能搞清客戶的需求是什么了。■對被檢測到的和被報告的異常情況請多花一點時間對其進行詳細描述。程序員一般都非常的懶，拋出異常時只描述錯誤的表面現象。設想如果只是作者自己會遇到這種錯誤，他會記得這種一直使用的錯誤描述信息是什么意思。但站在客服技術支持的處境，他們因為這種不準確的、不完整的錯誤描述浪費了大量時間。這些信息應該達到讓一個剛走進屋里沒有任何經驗的人能看明白的程度。客戶和客服基本都是對編程不懂的人。
公司管理相關推薦
鄂ICP備17016276號-1