推 rodion:想法和你一樣 先做出簡單好懂的版本 需要時再來改進效率 11/14 18:44
※ 引述《sniffer (again)》之銘言：
: ※ 引述《oaz (幸福治安：破案數/十萬人)》之銘言：
: : 基本上，台灣的規格書是比較接近需求搜集，然後下一步就要實作
: : 譬如：
: : 規格書定義：一個畫面有三個按鈕，按了第一個要做什麼，第二個要做什麼事，第三個要做什麼事
: : 但比較學院派的人作法，是比較接近物件導向分析與設計
: : 譬如，會從使用者案例開始玩起
: : 就使者案例來說，除此需求之外
: : 還要考慮，使用者按了第一個按鈕後，再按第二個按鈕，這時候會如何？
: : 或者，使用者連續第一個按鈕，會不會出什麼問題？
: : 或者，這時系統發生了什麼事件，譬如網路斷線、東下下載完了
: : 程式是否要通知使用者或更新書面
: : 每種用法都要清清楚楚的列出來。如果有些結果還不確定，就要再回去
: : 如果做得好，不會等到程式實作差不多後才發現
: : 如果使用者怎麼做，會有大問題，所以要改架構
: : 如果系統這時網路斷線，會有大問題，所以要改架構
: : 做完使用者案例，還要做系統架構分析、物件分析
: : 要達成每個案例，系統該包含哪些物件，有什麼責任
: : 再根據每個物件
: : 理論上，這都是 SA 、SD 的人要做的
: : 但是，台灣只有 PM 提出要做什麼（還很不明確），
: : 然後 RD 要身兼 SD、SD、PG
: : 基本上，每種因素都會引起各種架構變化
: : 因此：
: : 一、當設計的時侯要儘量有彈性，這也是 SA、SD 要有足夠能力
: 現實中的程式, 必須要顧慮效能, 也要顧慮時效性,
: 最好效能的架構不會有彈性, 最快寫好的程式(例如perl)也往往最難維護,
: 但是最好維護從來都不是大多數程式的第一優先, 也不應該是優先:
: 1. 效能好的程式節能減碳, 這對server, driver或embedded system這類程式非常重要,
: 因為這些程式擁有最多的執行時間, 少用一個clock就少砍很多樹, 電池多活很久
事實是：80-20 法則，程式有 80% 的時間花在 20% 的程式碼
甚至是 90-10 法則
要改善效率主要有兩個方法：
一、先寫出比較有彈性、可讀性較高的程式
再找出比較花時間的部分，對
二、不管三七二十一，就算沒有彈性、可讀性會變差
但撰碼時一律用最有效能的方式寫
事實上，第二種方式寫出來的程式並不一定會第一種有效能
第二種方式，很可能會了很多時間、人力，但都省在那種無關緊要的地方
甚至，可能會更慢
譬如，使用 cache 機制通常可以增加效能
但不適當的 cache ，在沒必要做 cache 的地方做 cache
程式反而要另花成本去維護 caceh ，反而是減少效能
不知道你有沒有遇過：在一開始寫得很美好，考慮了效能，使用了一些 cache 機制
在撰碼時就用最佳化的方式去寫程式，但比較沒有彈性，可讀性較差
但因為運作不錯，效能又跑不錯，就接受
等到期限前，忽然發現有 bug ，因為 cache 機制有問題，或者使用不當
或者使用雙重 cache ，又沒有把溝通流程搞清楚
但因為期限快到了，就另外硬加一套機制去修正
但新加的這套機制又無法顧及原先的 cache 機制
極端一點，甚至程式為了正確性，反而要資料都從新的機制拿
但舊的 cache 機制又不管拿掉
結果是，程式的效能最後是變差的
要聲明的是：
一、我不認為在任何情況下， "可讀性" 和 "可維護" 一定優先於效能
譬如寫嵌入系統底層（作業系統、驅動程式）的人，
除此以外，大部分的程式（應用程式），大部分的情況， "可讀性" 和 "可維護"
二、在真的需要效能的情況下，
一個架構良好，可讀性和可維護高的程式，通常可以很容易做最佳化又不會影響程式正確性
但一個可讀性可維護性低的程式，若出了一個正確性的錯誤需要修正時，
常常會去影響其原先設計的效能機制
: 2. 如果facebook慢慢做系統分析, 慢慢研究使用者行為, 慢慢推敲架構會不會DoS,
: 那他就不會成功, 先做出來才是重點
facebook 是規模一直在變大，也就是需求一直在變
我相信， facebook 在成長的階段，也是也過分析、設計
隨著規模一直在變大，一直有持續的分析、設計
: : 二、就風險管理的角度，儘管有一百種各式各樣的因素導致架構變化
: : SA、SD 還是要能儘管可能掌控各種因素，譬如其中的九十種
: : SA、SD 不能因為還有十種因素不能掌控，所以連那九十種因素都不掌控
: : 照比較正規的作法（學院派），可能規格書真的比較 code 多
: : 不過要考慮一個因素，是因為這種規格書比較因素比較多，所以才會比較厚
: : 至於所謂的 SA自己寫全部code還比較快
: : 基本上，這純粹是規模問題：
: : 譬如要蓋一間狗屋，應該不會有人大材小用還給出一個規格書
: : 當然是先動手做再說
: : 但如果要蓋一棟高樓大廈，
: : 總不會說規格書會太厚
: : 設計師自己去蓋房子說不定還比較快
: 蓋房子設計師無法自己搬一棟樓的磚, 但是規格書裡面的流程假如比code還多,
: SA直接用這個時間自己寫, 都已經做好了
規格書裡面的流程比code還多，是因為規格書考慮了很多例子
如果 SA 直接用這個時間自己寫，你那麼寫出來的程式真有有考慮到那麼多？
: 一個很"正規"的例子, 世界前三大某IC豬屎屋, 他們的SDK就是在印度寫,
: 採用"正規"作法, 裡面每個模組都帶有比code還多的規格書, 測試報告,
: 其實這個產品全部的code只有幾MB, 但是拆成一百多個模組,
: 於是當我要修改電路板某個clock, 問他們的人會影響哪裡,
: 這件事情沒有人能告訴我, 所有的programmer都沒有辦法知道整個架構,
請問，為什麼programmer "該" 知道整個架構,
在這套玩法中，SA、SD 是最重要的，PG 是最便宜的
為什麼你認為 "知道整個架構" 的責任在 PG 上？
我很好奇你的角色是什麼？ SA、SD、PG
還是標準台灣 RD = SA + SD + PG
: 一點小小地修改都要找一群人開會, 大約要等二周,
沒錯，一點小小地修改都要找一群人開會, 大約要等二周
但是，這也表示，因為一個人在一天內做出的一點小小地修改
但因為沒有想清楚，造成整個系統的災難
這就是公司的決策者要去衡量的
: 或者自己看海量的文件, 找出所有用到這個clock的模組
再者，我很好奇，為什麼你的一點小小地修改，可以影響到很多模組
你做的真的是一點小小地修改？
模組的用義在於：主要介面定出來，模組內部怎麼亂搞，都不會影響外面
如果因為一點小小地修改就影響到很多模組
該考慮的是：
一、設計上可能有問題
二、這可能真的不是小小的修改
: 文件比code還多的時候, 所謂的好維護根本只是為了以後可以告訴你,
: 他文件"有"寫到, 在編號E1046875r467文件的677頁120行....
: 找文件不會比找code方便, code至少是100%文字檔, C也比英文有結構
C 比英文有結構
但不代表你看了 C 程式碼，你就可以了解各種正確和失敗的例子
: : 所以說，是台灣不重視 SA 、 SD
: : 否則，為什麼只有幾個人負責設計？
: : 只有幾個 SA 、SD ，然後有幾百個 PG 嗎？
: : 那是因為，在台灣， RD 要身兼 SA、SD、PG
: : 如果是原作者說的那種玩法
: : 那就要有數十位以至數百位 SA、SD，是公司最重要的資產
: : 然後 PG 找工讀生或外包
: 這樣的架構, 一旦要改bug, 換規格, 反應非常慢, 大家時間都花在溝通,
: programmer本來就應該有能力自己規劃模組的實踐, 自己為自己的程式負責,
: 而不是中間分出一大堆所謂SA/SD來, 架構的人沒在寫程式, 也沒有run程式,
: 寫的人只知道自己的一堆超簡單code block, 卻要找出整個程式哪裡掛了
: : 改規格是一定的，但是 SA 、SD 要儘可能分析各種可能
: : 儘可能設計到有彈性，使得之後的改變最小化
: : SA、SD 不能因為還有十種因素不能掌控，所以連剩下的九十種因素都不掌控
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 140.112.30.46
※ 編輯: oaz 來自: 140.112.30.46 (11/14 14:28)