溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務條款》

web設計開發(fā)過程中的問題有哪些

發(fā)布時間:2022-03-31 10:04:14 來源:億速云 閱讀:268 作者:iii 欄目:開發(fā)技術

這篇文章主要介紹了web設計開發(fā)過程中的問題有哪些的相關知識,內容詳細易懂,操作簡單快捷,具有一定借鑒價值,相信大家閱讀完這篇web設計開發(fā)過程中的問題有哪些文章都會有所收獲,下面我們一起來看看吧。

(1)詳細設計和代碼的吻合程度有多高?

假設在項目中,代碼在測試后修改完畢提交后,并不修改詳細設計,則詳細設計和代碼之間并不吻合,并且很大程度上,吻合度會非常低。

如果詳細設計和最終的代碼并不吻合,那么這樣的詳細設計并不能給將來的維護帶來任何幫助。

如果詳細設計并不能給后續(xù)帶來幫助,為什么要書寫它呢?

因為——詳細設計是用來指導代碼書寫的。

(2)詳細設計對代碼的指導意義有多大?

詳細設計的類圖是用來定義類框架之間的關系的;其中的時序圖(有時也用流程圖)是用來定義方法之間的調用關系的。

如果說詳細設計是這么定義的,那么為什么不直接用IDE寫成代碼形式?

因為——詳細設計的過程是需要記錄文檔以備后查的。

(3)詳細設計是怎么復查和修改的?

詳細設計的復查是通過對書寫完成的詳細設計文檔進行閱讀和審查,并指出其中可能出現(xiàn)的錯誤和遺漏。

然后針對提出的問題進行修改,直到修改完成為止。

為什么要這樣復查和修改呢?因為詳細設計的質量提高有助于早期發(fā)現(xiàn)問題。

(4)既然詳細設計是用來指導代碼書寫的,為什么還需要后續(xù)的測試?

換句話說,為什么詳細設計不能夠100%正確。

這么問并不是要求把詳細設計100%書寫正確——因為這是個不可能的任務。

詳細設計是一個猜想的過程,其復查和修改也都是在猜測中完成的。

詳細設計到底做成什么樣才能夠更有效地指導代碼書寫呢?

(5)詳細設計的完成是怎么定義的?

詳細設計的完成指標是:詳細設計的頁數(shù)達到若干頁,每頁復查發(fā)現(xiàn)的問題達到多少個。

詳細設計是用來指導代碼書寫的。為什么不從指導代碼書寫的方面進行指標定義?

詳細設計還有問題殘留的時候怎么就開始代碼書寫了?

現(xiàn)實情況是:詳細設計的完成是以項目經(jīng)理的喜好決定的——往往是時間壓力決定的,還有時間就繼續(xù)寫;沒有時間就算完成了。

(6)為什么覺得詳細設計是必要的過程?

因為是規(guī)定的。因為別人都這么做。這應該不是答案吧?

那么到底應該怎么書寫詳細設計呢?答案是:不寫!理由如下:

(1) 詳細設計的職責不明確

詳細設計名將概要設計細化,并指導代碼書寫。但是反觀其階段結束時間不明確,并且階段結束的判定標準也沒有對如何指導代碼書寫進行定義,很難說詳細設計真的是用來指導代碼書寫還是將概要設計細化的。

(2) 詳細設計沒有生產(chǎn)有價值的產(chǎn)物。

據(jù)統(tǒng)計,詳細設計在項目開發(fā)過程中所消耗的工時基本上占編碼和單元測試的一半。但是它的產(chǎn)物——UML圖可以通過直接書寫代碼,然后從IDE導出生成,這個過程只需要幾秒鐘。

但是詳細設計還是要做的。這不是和前面矛盾嗎?不!

上面說的是寫,這里說的是做。

有些處理的條件很多,不是三言兩語能夠說清楚的,這時候就需要詳細設計。

比如:一個由兩組條件決定的處理。從需求角度山來說,通過畫成二維表可以描述清楚其各個條件組合下的行為
                 a        b      c
         1      a1     b1     c1
         2      a2     b2     c2
         3      a3     b3     c3

針對這種情況,如果寫流程圖,那么代碼也將會按照流程圖那么書寫,代碼會變得很冗長。所以流程圖并不適合做詳細設計。這種情況可以通過類的書寫來完成。

假設行條件是時間范圍(TimeScope),分別代表過去(Past),現(xiàn)在(Present)和將來(Future)而列條件是狀態(tài)(State),分別代表申請(Apply),批準(Approval)和拒絕(Decline)

在類的設計時,以時間范圍為主軸,狀態(tài)為輔軸,那么類定義為:

interface TimeScope {       public void apply();       public void approval();       public voi decline(); }

則Past,Present和Future分別實現(xiàn)相應的方法就可以實現(xiàn)上面需求定義的矩陣。

這種方法叫做橋接模式(Bridge Pattern)

而這個過程并不需要留下文檔。

同樣大多數(shù)情況來說,根據(jù)需求可以直接生成代碼。而詳細設計是一個可以簡化到只要幾分鐘就可以完成的過程。并且,從質量的角度來說,并沒有損失。

設想一下,如果一個項目可以略掉詳細設計過程,其可以帶來的節(jié)省有多大。

如果客戶非要要求詳細設計怎么辦?

雇傭比軟件工程師便宜的文檔人員來根據(jù)代碼反寫詳細設計——因為類圖都可以通過工具生成——所以,所需要的文檔人員也很少,工時也很少。

關于“web設計開發(fā)過程中的問題有哪些”這篇文章的內容就介紹到這里,感謝各位的閱讀!相信大家對“web設計開發(fā)過程中的問題有哪些”知識都有一定的了解,大家如果還想學習更多知識,歡迎關注億速云行業(yè)資訊頻道。

向AI問一下細節(jié)

免責聲明:本站發(fā)布的內容(圖片、視頻和文字)以原創(chuàng)、轉載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權內容。

AI