#純靠北工程師5bu
----------
我是#純靠北工程師5bn的發文者
為什麼有人認為是鬼故事呢
是SA們私底下喬定，把舊程式直接搬過來就好。上級長官根本就不知道這件事情。
當初我在面試的時候，有問面試官說「你們怎麼開發專案，有規格書，有共用模組，共同開發方式嗎?」
面試官回答說「有，PG就是看著規格書coding，拿SD開發好的共用模組，實作細節」
聽起來，這個專案的架構算正常，不是地雷。結果一進來，根本就不是。
規格書是舊的，是拿來給上級長官看的。沒有共用模組。
後端還能拿舊code抄，前端畫面架構就要自已寫了。拿Bootstrap寫好的照抄，Jquery是寫在html的
同時也有35部Youtube影片，追蹤數超過12萬的網紅くずゆう，也在其Youtube影片中提到，すみませんでしたぁ！！！！ 00:00 #1 09:56 #2 19:13 #3 25:27 #4 32:33 #5 41:02 #6 50:26 #7 01:00:00 #8 01:08:51 #9 01:17:57 #10 01:28:41 #11 01:40:39 #12 01:50:31 ...
「sa sd」的推薦目錄：
- 關於sa sd 在 純靠北工程師 Facebook 的最佳貼文
- 關於sa sd 在 純靠北工程師 Facebook 的精選貼文
- 關於sa sd 在 純靠北工程師 Facebook 的最佳貼文
- 關於sa sd 在 くずゆう Youtube 的最佳解答
- 關於sa sd 在 Jerry Yuen Youtube 的最佳解答
- 關於sa sd 在 Jerry Yuen Youtube 的最佳解答
- 關於sa sd 在 Re: [請益] 有公司用這種開發方式嗎? - 看板Soft_Job 的評價
- 關於sa sd 在 Sa Sd | Facebook 的評價
- 關於sa sd 在 SA SD-PTT/DCARD討論與高評價網拍商品-2021年10月|飛比價格 的評價
- 關於sa sd 在 SA SD-PTT/DCARD討論與高評價網拍商品-2021年10月|飛比價格 的評價
- 關於sa sd 在 SA、SD、PG | Limitless Ping 的評價
- 關於sa sd 在 [請益] RD轉SA/SD 疑問- soft_job | PTT職涯區 的評價
- 關於sa sd 在 請問一些資管的問題！ - Mobile01 的評價
- 關於sa sd 在 [請益] RD轉SA/SD 疑問 - PTT 問答 的評價
- 關於sa sd 在 豬屎屋designer(DD/DV)與FW(AE,SD,SA)薪資差距? - 科技業板 的評價
- 關於sa sd 在 [請益] SA/SD未來出路qqq04737084 PTT批踢踢實業坊 的評價
- 關於sa sd 在 Overview of SA/SD Methodology | Software Design | CSE 的評價
- 關於sa sd 在 オークランド電化で追放されたSA/SD編成とSX客車が保管 ... 的評價
- 關於sa sd 在 Laboratorios Arsal SA SD - YouTube 的評價
sa sd 在 Re: [請益] 有公司用這種開發方式嗎? - 看板Soft_Job 的推薦與評價
※ 引述《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
... <看更多>