→ Lordaeron:halflife就是Quake3 的engine而已. 11/15 17:34
→ Lordaeron:而halflife 不是id software 公司的game, 請別game 及 11/15 17:35
→ Lordaeron:engine 混在一起談. 11/15 17:35
→ yoco315:sniffer 可能沒寫過大程式，有的東西要體驗過才知道 11/16 13:08
→ kit51:文件跟左手一樣只是輔助, 夠用就好了 11/18 01:50
※ 引述《oaz (幸福治安：破案數/十萬人)》之銘言：
: 一個 "可維護性" 高的程式，通常很容易做最佳化
最佳化是一個一開始就要規劃的東西, 事後最佳化, 效果都很差,
不然就是改得亂七八糟
舉個3d game例子:
DOOM原先是針對software rendering做的程式,
在3d顯卡時代很多人想改用opengl rendering, 結果因為地圖有"洞",
被迫在程式裡面加上一堆怪code補洞, 而且效能也很糟,
但是halflife就是3d顯卡時代的設計, 一開始就有考慮3d硬體,
所以兩種rendering畫面非常一致
所以像id software每次都會根據新的架構, 重寫他們的3d engine,
而不是企圖重複利用舊的程式
: 因此，當 "規劃以維護性為優先" ，之後通常很容易可以改進效能
: 但是，當 "規劃以效能為優先" ，之後常常時維護成本升高
: : 在我的理解, "大部分"程式都是訂做的, 為了特定的需求,
: : 這些程式並沒有需要維護多少次, 只有套裝軟體或MIS系統才需要長期維護,
: : 盲目套用M$一類套裝軟體公司的模式, 只會增加成本降低效能
: 如果一家公司接的專案都是 "小，而且只有一次，程式交差後就可以掉"
: 我不否認你的作法的確可行，但通常不會是這種情形
程式包括game, 動畫, 自控, script, driver, 統計分析等都是一次性的,
很通常好嗎
: 一、從專案初期到後期，算不算一種維護？
: 你的作法，減少了程式 "執行時的成本" ，但增加了 "維護的成本"
文件過多, 維護成本一樣很大, 一個區區幾十萬行的程式,
卻搭配了一輩子看不完的文件, 只為了"有紀錄", 我不認為有省到錢
: 二、當寫出一個運作正常的程式後，可以對它 "做最佳化"
: 於是 "執行時的成本" 這種現象只會出現在專案初期
: 一個 "可維護性" 高的程式，通常很容易做最佳化
: : 這條是說明, 很多程式時效性第一, 所以也不能以維護性為優先
: 一、你講的是市場的時效，這我不否認有時侯確實優先於 "維護性"
: 但是，前後提到的是 "效能" 跟 "維護性" 的比較
: 這裡卻變成 "市場時效性" 跟 "維護性" 的比較
: 二、很多時效，根本是老闆自以為的，市面上的商業網站那麼多
: 真的因為先推出的攻佔市場的有幾個？除了 Facebook 和 Amazon 外，還有誰
: 三、市場的時效很重要，然後呢？
: 搶到時效，早於市場推出，然後呢？我們就可以不用維護了嗎？
: 還是就可以不用考慮 "維護性" ？
: 之後出問題，就推說 "那是因為因應市場時效性而亂寫的程式所留下來的，請不要動它" ？
: Facebook 當初出來，難道是因為效能很好？
: 十有八九，為了搶市場，反而是不注重效能的
所以, 該效能就效能, 該省時就省時, 因地制宜,
而不是一堆文件, 天下無敵
: （一開始以學生為面向，估計以千、萬人為目標，而不是以億人為目標）
: 等到成長到一定地步，才逐漸改善效能
: 一個 "可維護性" 高的程式，通常很容易做最佳化
: : 考慮完=>操作word, 寫成英文, 圖表, 虛擬碼共1MB
: : 考慮完=>操作text editor寫成C 20KB
: : 哪個快?
: 請問，哪個出問題比較快？
: 哪個因為 "啊，沒考慮到某種例子" 因而出問題比較快
: 哪個因為 "撰寫某個模組時，因為沒考慮到另一個模組" 因而出問題比較快
: 再請問，哪個出問題後，解問題比較快？
: 你講的都只是 "先期看到樣品" 比較快
: 真的等到的整合、測試時，你的作法常常會出問題
你搞錯囉, 考慮的時間一樣久, 並沒有打折,
多做一個文件, 並不能避免問題, 也許問題出來後可以查文件,
但是文件太多, 查起來會比查source code快嗎?
: : 這個code規模很小, 如果同樣模式, 套在500MB source code的mozilla,
: : 那就是開會一年了
: 一、Mozilla 是另一種關發模式，根本不適合
: 二、Mozilla 這個例子跟你的例子根本不合
: 你的例子看起來比較接近嵌入式系統
mozilla 就是個很大的程式, 也經常修改, 他就沒有海量的文件,
請問誰的project有他大?
: : 理想上是這樣, 現實中這是不可能的
: : 1. 用到硬體的時候, 前一個模組的設定會影響後一個
: : 2. 用到UI的時候, 不同模組的畫面必須要連續
: : 3. 用到系統資源的時候, 不同模組會搶資源
: "不同模組的畫面必須要連續" ？
: 所以不同的模組都要有 "使用者介面的畫面"
: 我只能說，模組不是這樣切的，至少把使用者介面切出來
: 不要讓使用者介面影響到其它模組
: 至少先有 MVC 的架構。
: 用到系統資源的時候, 不同模組會搶資源？
: 所以，切模組時，要分兩種，有些功能會用到系統資源，有些不會
: 不要讓這些功能互相影響
: 此外，為什麼你會覺得這是一種小小的修改
: 一點小小的修改就會影響到整個系統
: 你都不怕隨便改了，會導致系統出災難？你難道認為要一天內解決？
: 我反倒這是設計上的問題，牽涉到設計的就不會是小問題
: 認為二星期內解決也算合理？
: 你覺得 "二星期內解決" 太久
: 你該做的是 "改進設計"，而不是 "不要規格書"
: 你舉的例子看起來就是設計上有問題
這不是我設計的, 是某個前三大豬屎屋的印度分公司,
另外一家也是世界前三大, 他們的程式在美國寫,
就不會像印度這邊的, 文件又多又長, 找個問題花二周,
並不是大公司程式就一定會一堆文件
: : 看到C, 可以確定程式怎麼實做的, 看到規格書, 只能知道曾經是這樣規劃的,
: : 規格書跟程式碼還不一定同步, 也許SA放假去, 也許PG亂寫...
: : 做一件事, 需要處理的手續越多, 就越沒效率:
: : 1. 一個大概的規格書, 只介紹20模組功能跟介面, 加上100K source code
: : 2. 20個模組詳細規格書pdf, 內含模組裡面的流程, 模組的模組,
: : 加上100K source code
: : 很明顯閱讀1比較快, 而且2只要一忙很容易就跟code失去同步, 比沒有糟糕
: "2只要一忙很容易就跟code失去同步" 這點真的是管理有問題了
: 想要玩規格，又不認真玩，又用 1 的方式去管理 2
: 以政府部門來舉例，若一件事，要經手的人多，要處理的手續多，的確沒效率
: 可是，若一件事，隨便一個人，都可以隨意更改流程，的確可以增進效能
: 但到時侯部門出問題的機率一定會變非常大
管理=成本
問題=成本
成本總額小才是對的, 而不是只怕出問題,
公家單位不營利, 當然不管這個
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 122.116.218.88