Re: [請益] 有公司用這種開發方式嗎?
※ 引述《sniffer (again)》之銘言：
: ※ 引述《oaz (幸福治安：破案數/十萬人)》之銘言：
: : 前在公司上過軟體外包管理的課程
: : 有提到類似的事，提到的例子好像是花旗
: : 我個人的心得是
: : 一、系統架構要很強（SA），設計出來的東西不能到實作才發問題
: : 二、規格要很明確，明確到每個函式都要定出來
: 永遠都會有沒考慮到的問題, 不然瀑布架構不會被檢討,
基本上，台灣的規格書是比較接近需求搜集，然後下一步就要實作
譬如：
規格書定義：一個畫面有三個按鈕，按了第一個要做什麼，第二個要做什麼事，第三個要做什麼事
但比較學院派的人作法，是比較接近物件導向分析與設計
譬如，會從使用者案例開始玩起
就使者案例來說，除此需求之外
還要考慮，使用者按了第一個按鈕後，再按第二個按鈕，這時候會如何？
或者，使用者連續第一個按鈕，會不會出什麼問題？
或者，這時系統發生了什麼事件，譬如網路斷線、東下下載完了
程式是否要通知使用者或更新書面
每種用法都要清清楚楚的列出來。如果有些結果還不確定，就要再回去
如果做得好，不會等到程式實作差不多後才發現
如果使用者怎麼做，會有大問題，所以要改架構
如果系統這時網路斷線，會有大問題，所以要改架構
做完使用者案例，還要做系統架構分析、物件分析
要達成每個案例，系統該包含哪些物件，有什麼責任
再根據每個物件
理論上，這都是 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, 這算什麼分工
: : 三、公司要有明確的程式設計風格，如
: : 基本上， coding 是沒什麼大不了的
: : 因為規格都詳細到函式，而且程式設計風格有明確規範
: : 不同的人寫出來的差不大
: : 但以台灣的現況：
: : 一、台灣的公司不怎麼注重系統架構
: : 真正的系統架構強者大概也不會受到重視，公司也不會想到要去培育
: 君不見園區各大公司裡面, 往往只有幾個人負責設計,
: 只是他們職稱都很大, 一般人以為他們沒做事而已, 他們累死了,
: 如果還要他們寫架構書, 再去讓英文很爛的咖啡工程師把英文轉成程式,
: 只會更沒效率, 更多咖啡工程師抱怨賣肝
所以說，是台灣不重視 SA 、 SD
否則，為什麼只有幾個人負責設計？
只有幾個 SA 、SD ，然後有幾百個 PG 嗎？
那是因為，在台灣， RD 要身兼 SA、SD、PG
如果是原作者說的那種玩法
那就要有數十位以至數百位 SA、SD，是公司最重要的資產
然後 PG 找工讀生或外包
: : 二、台灣的公司規格一改再改是理所當然，規格詳細到函式根本是自討苦吃
: : 而且，台灣的公司規格稱不上是規格
: : 頂多是需求的定義（譬如要做什麼，要有什麼功能），然後就開始實做
: : 之後的系統設計、實做，都是 RD 的責任
: 改規格是一定的, 如果需求都不會改變, 什麼都作成ASIC就好,
: 哪裡需要軟體業, 軟體業就是為了"改"而生的, 全世界都一樣
改規格是一定的，但是 SA 、SD 要儘可能分析各種可能
儘可能設計到有彈性，使得之後的改變最小化
SA、SD 不能因為還有十種因素不能掌控，所以連剩下的九十種因素都不掌控
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 140.112.30.46
→
11/12 15:16, , 1F
11/12 15:16, 1F
→
11/12 15:18, , 2F
11/12 15:18, 2F
→
11/12 15:21, , 3F
11/12 15:21, 3F
→
11/12 15:32, , 4F
11/12 15:32, 4F
→
11/12 17:44, , 5F
11/12 17:44, 5F
推
11/13 21:07, , 6F
11/13 21:07, 6F
討論串 (同標題文章)