Re: [請益] 有公司用這種開發方式嗎?
個人認為這樣做而且做得好的, 成本其實較高,
比較起來值得觀注的是它有沒有對應的品質,
想像一下, 例如單純的 CRUD 導頁面 這樣的東西,
後端程式
資料存取 - 已經訂好資料表, 各個欄位及它們的型態, 意義與關連
- 已經訂好 DAO 基本介面及該在哪個 package,
class 名稱的規則, 裡面變數名的規則, 能見度,
- 已經訂好撈出來的資料的表示方式及存取方式等的規則
頁面邏輯 - 已經訂好頁面及其對應的 java bean 的命名規則,
- 已經訂好一個頁面生成的基本流程及常用 API,
- 已經規劃好幾個主要 template, 並能簡單的套版並插入必要的內容
注意是要能插入必要內容, 這代表改版面較不易影響套用的頁面
- 已經實做了許多容易使用的 custom component,
例如回首頁 = <home />, 而不是 <div><a href=...
或許還再加上 img... onmouseover... onclick...
導頁面 - 已經訂好流程
- 規訂導頁面的資料要寫在固定的檔案
然後許多麻煩複雜的事, 可能是按右鍵跑某個檔案即可
諸如此類, 當已經有了極完整的分析與設計,
有了許許多多強大易用的 component, script,接力不會是困難的事情,
debug 也不會有問題, 因為一切都規格化, 制度化,
什麼東西會在哪裡做些什麼都很清楚
但是獨立一個專案來看, 這成本是非常高的,
可能 PM SA SD 加一加五六個人, 和 user 方的五六個人開兩小時的會,
只討論了一個功能, 兩三個頁面,
決定某個鈕按下是要更改某個區塊的內容, 換頁或彈出視窗,
或者某個 template 裡 table 的上框線的顏色, 樣式與粗細等等,
在用便宜人力接力快速完成案子前,
就已經多花了幾十人月貴桑桑的人力做前置工作了,
所以我覺得比起速度與成本, 更重要的是專案的品質有沒有提升,
以及有多少東西能夠留到以後的專案,
讓那些前置工作的成本能越來越少,
不然可能中等人力不必接力硬幹完成本還比做那些前置工作低
不過這種方式, 開發公司想做, 搞不好 user 還沒空奉陪,
要開發公司自己去改到飽簡單多了...
※ 引述《oaz (幸福治安：破案數/十萬人)》之銘言：
: ※ 引述《sniffer (again)》之銘言：
: : 永遠都會有沒考慮到的問題, 不然瀑布架構不會被檢討,
: 基本上，台灣的規格書是比較接近需求搜集，然後下一步就要實作
: 譬如：
: 規格書定義：一個畫面有三個按鈕，按了第一個要做什麼，第二個要做什麼事，第三個要做什麼事
: 但比較學院派的人作法，是比較接近物件導向分析與設計
: 譬如，會從使用者案例開始玩起
: 就使者案例來說，除此需求之外
: 還要考慮，使用者按了第一個按鈕後，再按第二個按鈕，這時候會如何？
: 或者，使用者連續第一個按鈕，會不會出什麼問題？
: 或者，這時系統發生了什麼事件，譬如網路斷線、東下下載完了
: 程式是否要通知使用者或更新書面
: 每種用法都要清清楚楚的列出來。如果有些結果還不確定，就要再回去
: 如果做得好，不會等到程式實作差不多後才發現
: 如果使用者怎麼做，會有大問題，所以要改架構
: 如果系統這時網路斷線，會有大問題，所以要改架構
: 做完使用者案例，還要做系統架構分析、物件分析
: 要達成每個案例，系統該包含哪些物件，有什麼責任
: 再根據每個物件
: 理論上，這都是 SA 、SD 的人要做的
: 但是，台灣只有 PM 提出要做什麼（還很不明確），
: 然後 RD 要身兼 SD、SD、PG
: : Boss, HW bug, OS bug 都會引起各種架構變化,
: 基本上，每種因素都會引起各種架構變化
: 因此：
: 一、當設計的時侯要儘量有彈性，這也是 SA、SD 要有足夠能力
: 二、就風險管理的角度，儘管有一百種各式各樣的因素導致架構變化
: SA、SD 還是要能儘管可能掌控各種因素，譬如其中的九十種
: SA、SD 不能因為還有十種因素不能掌控，所以連那九十種因素都不掌控
: : 而且這樣做, 規格書可能比程式還多, SA自己寫全部code還比較快
: 照比較正規的作法（學院派），可能規格書真的比較 code 多
: 不過要考慮一個因素，是因為這種規格書比較因素比較多，所以才會比較厚
: 至於所謂的 SA自己寫全部code還比較快
: 基本上，這純粹是規模問題：
: 譬如要蓋一間狗屋，應該不會有人大材小用還給出一個規格書
: 當然是先動手做再說
: 但如果要蓋一棟高樓大廈，
: 總不會說規格書會太厚
: 設計師自己去蓋房子說不定還比較快
: : 每個函式都要定出來, 是用在程式模組之間的介面,
: : 不是要SA把程式架構裡的每個函式都弄出來,
: : programmer越高段, 模組就可以越粗略, 自行發揮就好,
: : 無法自行發揮的, 回去賣雞排啦
: : 無法理解程式運作的人, 同時也等於無法debug的人,
: : 能分工寫出來卻不能debug, 這算什麼分工
: : 君不見園區各大公司裡面, 往往只有幾個人負責設計,
: : 只是他們職稱都很大, 一般人以為他們沒做事而已, 他們累死了,
: : 如果還要他們寫架構書, 再去讓英文很爛的咖啡工程師把英文轉成程式,
: : 只會更沒效率, 更多咖啡工程師抱怨賣肝
: 所以說，是台灣不重視 SA 、 SD
: 否則，為什麼只有幾個人負責設計？
: 只有幾個 SA 、SD ，然後有幾百個 PG 嗎？
: 那是因為，在台灣， RD 要身兼 SA、SD、PG
: 如果是原作者說的那種玩法
: 那就要有數十位以至數百位 SA、SD，是公司最重要的資產
: 然後 PG 找工讀生或外包
: : 改規格是一定的, 如果需求都不會改變, 什麼都作成ASIC就好,
: : 哪裡需要軟體業, 軟體業就是為了"改"而生的, 全世界都一樣
: 改規格是一定的，但是 SA 、SD 要儘可能分析各種可能
: 儘可能設計到有彈性，使得之後的改變最小化
: SA、SD 不能因為還有十種因素不能掌控，所以連剩下的九十種因素都不掌控
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 61.224.40.37
※ 編輯: lovdkkkk 來自: 61.224.40.37 (11/12 22:05)
推
11/13 11:31, , 1F
11/13 11:31, 1F
討論串 (同標題文章)