為什麼這篇SA 規格書鄉民發文收入到精華區:因為在SA 規格書這個討論話題中,有許多相關的文章在討論,這篇最有參考價值!作者sniffer (again)看板Soft_Job標題Re: [請益] 有公司用這種開發方式嗎?...
※ 引述《oaz (幸福治安:破案數/十萬人)》之銘言:
: ※ 引述《sniffer (again)》之銘言:
: : 永遠都會有沒考慮到的問題, 不然瀑布架構不會被檢討,
: 基本上,台灣的規格書是比較接近需求搜集,然後下一步就要實作
: 譬如:
: 規格書定義:一個畫面有三個按鈕,按了第一個要做什麼,第二個要做什麼事,第三個要做什麼事
: 但比較學院派的人作法,是比較接近物件導向分析與設計
: 譬如,會從使用者案例開始玩起
: 就使者案例來說,除此需求之外
: 還要考慮,使用者按了第一個按鈕後,再按第二個按鈕,這時候會如何?
: 或者,使用者連續第一個按鈕,會不會出什麼問題?
: 或者,這時系統發生了什麼事件,譬如網路斷線、東下下載完了
: 程式是否要通知使用者或更新書面
: 每種用法都要清清楚楚的列出來。如果有些結果還不確定,就要再回去
: 如果做得好,不會等到程式實作差不多後才發現
: 如果使用者怎麼做,會有大問題,所以要改架構
: 如果系統這時網路斷線,會有大問題,所以要改架構
: 做完使用者案例,還要做系統架構分析、物件分析
: 要達成每個案例,系統該包含哪些物件,有什麼責任
: 再根據每個物件
: 理論上,這都是 SA 、SD 的人要做的
: 但是,台灣只有 PM 提出要做什麼(還很不明確),
: 然後 RD 要身兼 SD、SD、PG
: : Boss, HW bug, OS bug 都會引起各種架構變化,
: 基本上,每種因素都會引起各種架構變化
: 因此:
: 一、當設計的時侯要儘量有彈性,這也是 SA、SD 要有足夠能力
現實中的程式, 必須要顧慮效能, 也要顧慮時效性,
最好效能的架構不會有彈性, 最快寫好的程式(例如perl)也往往最難維護,
但是最好維護從來都不是大多數程式的第一優先, 也不應該是優先:
1. 效能好的程式節能減碳, 這對server, driver或embedded system這類程式非常重要,
因為這些程式擁有最多的執行時間, 少用一個clock就少砍很多樹, 電池多活很久
2. 如果facebook慢慢做系統分析, 慢慢研究使用者行為, 慢慢推敲架構會不會DoS,
那他就不會成功, 先做出來才是重點
: 二、就風險管理的角度,儘管有一百種各式各樣的因素導致架構變化
: SA、SD 還是要能儘管可能掌控各種因素,譬如其中的九十種
: SA、SD 不能因為還有十種因素不能掌控,所以連那九十種因素都不掌控
: : 而且這樣做, 規格書可能比程式還多, SA自己寫全部code還比較快
: 照比較正規的作法(學院派),可能規格書真的比較 code 多
: 不過要考慮一個因素,是因為這種規格書比較因素比較多,所以才會比較厚
: 至於所謂的 SA自己寫全部code還比較快
: 基本上,這純粹是規模問題:
: 譬如要蓋一間狗屋,應該不會有人大材小用還給出一個規格書
: 當然是先動手做再說
: 但如果要蓋一棟高樓大廈,
: 總不會說規格書會太厚
: 設計師自己去蓋房子說不定還比較快
蓋房子設計師無法自己搬一棟樓的磚, 但是規格書裡面的流程假如比code還多,
SA直接用這個時間自己寫, 都已經做好了
一個很"正規"的例子, 世界前三大某IC豬屎屋, 他們的SDK就是在印度寫,
採用"正規"作法, 裡面每個模組都帶有比code還多的規格書, 測試報告,
其實這個產品全部的code只有幾MB, 但是拆成一百多個模組,
於是當我要修改電路板某個clock, 問他們的人會影響哪裡,
這件事情沒有人能告訴我, 所有的programmer都沒有辦法知道整個架構,
一點小小地修改都要找一群人開會, 大約要等二周,
或者自己看海量的文件, 找出所有用到這個clock的模組
文件比code還多的時候, 所謂的好維護根本只是為了以後可以告訴你,
他文件"有"寫到, 在編號E1046875r467文件的677頁120行....
找文件不會比找code方便, code至少是100%文字檔, C也比英文有結構
: : 每個函式都要定出來, 是用在程式模組之間的介面,
: : 不是要SA把程式架構裡的每個函式都弄出來,
: : programmer越高段, 模組就可以越粗略, 自行發揮就好,
: : 無法自行發揮的, 回去賣雞排啦
: : 無法理解程式運作的人, 同時也等於無法debug的人,
: : 能分工寫出來卻不能debug, 這算什麼分工
: : 君不見園區各大公司裡面, 往往只有幾個人負責設計,
: : 只是他們職稱都很大, 一般人以為他們沒做事而已, 他們累死了,
: : 如果還要他們寫架構書, 再去讓英文很爛的咖啡工程師把英文轉成程式,
: : 只會更沒效率, 更多咖啡工程師抱怨賣肝
: 所以說,是台灣不重視 SA 、 SD
: 否則,為什麼只有幾個人負責設計?
: 只有幾個 SA 、SD ,然後有幾百個 PG 嗎?
: 那是因為,在台灣, RD 要身兼 SA、SD、PG
: 如果是原作者說的那種玩法
: 那就要有數十位以至數百位 SA、SD,是公司最重要的資產
: 然後 PG 找工讀生或外包
這樣的架構, 一旦要改bug, 換規格, 反應非常慢, 大家時間都花在溝通,
programmer本來就應該有能力自己規劃模組的實踐, 自己為自己的程式負責,
而不是中間分出一大堆所謂SA/SD來, 架構的人沒在寫程式, 也沒有run程式,
寫的人只知道自己的一堆超簡單code block, 卻要找出整個程式哪裡掛了
: : 改規格是一定的, 如果需求都不會改變, 什麼都作成ASIC就好,
: : 哪裡需要軟體業, 軟體業就是為了"改"而生的, 全世界都一樣
: 改規格是一定的,但是 SA 、SD 要儘可能分析各種可能
: 儘可能設計到有彈性,使得之後的改變最小化
: SA、SD 不能因為還有十種因素不能掌控,所以連剩下的九十種因素都不掌控
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 112.105.197.233