※ 引述《EijiHoba (Feel)》之銘言： : 我不太會形容 : 像是 : 教你設計開發一套系統的書 : 像是人事系統、租片系統、進銷存之類的 : 我看完洪維恩 Java 2-JDK 5.0教學手冊（第三版） : 還是不知道要如何寫出一套小型的系統 : 現在網頁開發的書在後面章節都會教你要如何開發一些常見的系統 : 像是會員註冊、討論區等 : 有人有看過這樣的JAVA 書嗎？ 大略講一下設計一個系統的幾個門檻。 因為有人問系統的開發時間，基本上每個系統的狀況都不太一樣， 試著就共通得部份抽一點東西出來討論。 --------------------------------- 一個網站先不論介面什麼的， 光是報表這東西就好了，十個系統就可能有一百種不同的報表， Google analytics 寫得這麼密密麻麻，其中很多資訊還算是很精簡的。 功能清單是第一個門檻，也就是你到底有多少事情要做多少子系統要寫。 基本上這部份算是需求分析， 新手練習時可以挑一個現成的需求清單來 clone， 說穿了，也就是找一個活在線上的網站來仿造，這樣比較不用煩惱這塊。 但是真正工作上這塊會吃掉很多時間，而且決定你做的東西是不是做白工。 --------------------------------- 你現在有了功能清單了，假設是作個 blogger 好了， 你可能會覺得， 會員登入寫完，網誌寫完，回應寫完，分類寫完，相簿寫完， 這幾個分開寫完，事情就結束了。 錯！ 下一個問題是資料彼此之間的邏輯性， 以 blog 而言，會員可以發網誌、發留言、回應留言。 所以你會有所謂的 relation ，這種 relation 牽扯相當的廣， 這不只是資料庫的範疇，還有資料邏輯、程式設計的部份。 舉個例子，就拿回應這件事情好了， 會員回應理所當然的給會員 id 。 （真的這麼理所當然嗎？ 我也看過把很多會員資料在回應裡也寫一份的怪系統，請不要這樣做。） 今天 user 沒登入怎麼辦，要使用者登入，就又牽扯到登入流程， 可能會做訪客留言，訪客留言的會員 id 該怎麼給，該怎麼訂遊戲規則。 做了訪客留言後，今天你後端報表要統計各會員留言數量的時候， 是不是就要針對某個特定 id 或者某個特定規則去作處理。 做系統多得是這種需要通盤考量的東西。 新手跟老手的差別就在於能夠預先看出這東西的影響範圍， 並且給予這些東西預先適當的處理。 OO/軟體工程什麼鬼的，基本上都是用來解決這個問題。 拿重構來說好了，一開始東西重複的程式碼可能會散落在各地， 所以做集中化、抽象化的處理，這是一種很常見的重構行為。 於是我們原本修改一個邏輯需要修改十個地方的， 重構完之後只需要修改一個。 在一些一開始就知道比較有可能頻繁異動的元素上，就會得到很大的回饋。 軟體工程最後學習他的目的都是為了解決實務， 而不只是為了「用一個看起來很標準的作法」。 個人認為要在專案談軟體工程引入之前，那個人必須非常掌握專案的需求， 瞭解專案中的一些細節邏輯，他才有辦法掌握到真正的核心。 如果過於拘泥於某些固定作法，碰到一些特化的程式邏輯時很有可能死很慘。 --------------------------------- 即使是一個最最簡單的留言板系統， 也會分成有沒有會員系統，有沒有驗證碼， 能不能訪客留言， 如果可以，訪客能不能編輯文章（給一個code讓他們可以輸入 code修改）， 發文之後要不要先讓管理者做留言審核， 或者能不能讓管理者選擇其中幾篇不需要顯示。 而這些不同的功能其中又有不同的狀態，這些狀態值怎麼去設計， 會隨著不同專案不同需求而有不同的考量。 --------------------------------- 即使是資深的專案開發者，如果沒有先講清楚， 突然從只允許會員留言變到可以允許訪客留言， 這麼看似簡單的需求異動，都有可能因此造成一堆問題。 因為一開始的需求是只允許會員留言，所以一定有做權限控管， 能不能找到對應的權限區塊，並且正確設定允許訪客， 而且沒有設定到不該設定的地方，這都是可能很繁瑣的事情。 當然有的資深設計者可能一開始就會設計角色權限， 但是也有其他資深設計者會覺得簡單的留言板功能幹麼做這麼複雜而沒做。 這沒有對錯，純粹是一開始對目標設定的差異。 --------------------------------- 那你可能會問，既然這樣，如果給定固定需求，那總是能寫出一本書來吧， 事實上即使是同樣的需求也可能有十種作法，而且沒有對錯， 寫這種書被 challenge 的空間太大了。XD 而且要考慮到每個細節來講，以ERP或進銷存而言， 這本書大概少說三千頁起跳，不寫細節就又失去寫書的目的。 就跟上面某人說得一樣，簡單帶過，重點打馬賽克。XD 重點是，看完這本書， 如果你還是只會寫他所教你的系統，那一點意義也沒有。 現實世界需要得是實作的方針與能自主設計的思考模式， 資深的人能帶給新手的，一個有狀態的留言板實作已經很夠了。 前面有人說後端用 ORM ，用 hibernate 就夠了，只要專心刻 UI， 那是已經把資料邏輯的那段成本當成理所當然的前提了。 即使用 ORM 、 hibernate ， 一樣要注意資料安全 （ex. SQL Injection）， 組 HQL 如果還是很白目的把字串扔進去組 Query ， 而不是透過 setParameter 操作，一樣也是照死。 一樣要處理各種資料的狀態、邏輯設定。 一樣要處理權限控管，資料檢查等細節。 這些東西這樣看起來好像很嚇人，其實也未必， 就是每個環節每個環節要一步一步去檢視，更重要得是經驗與耐心。 新手寫得系統是不堪一擊的，但這沒有關係，被打爆了就會知道哪裡有問題。 每個人都是這樣走過來的。 最重要的事情是，系統設計是沒有標準答案的， 領域太廣，東西太多，狀態太多，導致每個人都是見招拆招。 所以這條路上你也不會有太多機會碰到什麼老師。 -- 網頁上拉近距離的幫手 實現 GMail豐富應用的功臣 數也數不清的友善使用者體驗 這就是ｊａｖａｓｃｒｉｐｔ 歡迎同好到 AJAX 板一同討論。 --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 1.34.116.11 ※ 編輯: TonyQ 來自: 1.34.116.11 (07/16 03:54) ※ 編輯: TonyQ 來自: 1.34.116.11 (07/16 03:54)