Re: [請益] 有公司用這種開發方式嗎?

看板Soft_Job作者oaz (幸福治安：破案數/十萬人)時間14年前 (2011/11/15 02:15)推噓7(7推 0噓 61→)

留言68則, 8人參與討論串16/19 (看更多)

※ 引述《sniffer (again)》之銘言： : ※ 引述《oaz (幸福治安：破案數/十萬人)》之銘言： : : 事實是：80-20 法則，程式有 80% 的時間花在 20% 的程式碼 : : 甚至是 90-10 法則 : : 要改善效率主要有兩個方法： : : 一、先寫出比較有彈性、可讀性較高的程式 : : 再找出比較花時間的部分，對 : : 二、不管三七二十一，就算沒有彈性、可讀性會變差 : : 但撰碼時一律用最有效能的方式寫 : : 事實上，第二種方式寫出來的程式並不一定會第一種有效能 : : 第二種方式，很可能會了很多時間、人力，但都省在那種無關緊要的地方 : : 甚至，可能會更慢 : : 譬如，使用 cache 機制通常可以增加效能 : : 但不適當的 cache ，在沒必要做 cache 的地方做 cache : : 程式反而要另花成本去維護 caceh ，反而是減少效能 : : 不知道你有沒有遇過：在一開始寫得很美好，考慮了效能，使用了一些 cache 機制 : : 在撰碼時就用最佳化的方式去寫程式，但比較沒有彈性，可讀性較差 : : 但因為運作不錯，效能又跑不錯，就接受 : : 等到期限前，忽然發現有 bug ，因為 cache 機制有問題，或者使用不當 : : 或者使用雙重 cache ，又沒有把溝通流程搞清楚 : : 但因為期限快到了，就另外硬加一套機制去修正 : : 但新加的這套機制又無法顧及原先的 cache 機制 : : 極端一點，甚至程式為了正確性，反而要資料都從新的機制拿 : : 但舊的 cache 機制又不管拿掉 : : 結果是，程式的效能最後是變差的 : 這只是說明一開始沒有設計好, 沒有做複雜度分析, : 規劃永遠是要的, 但是規劃不應該以維護性為優先一個 "可維護性" 高的程式，通常很容易做最佳化因此，當 "規劃以維護性為優先" ，之後通常很容易可以改進效能但是，當 "規劃以效能為優先" ，之後常常時維護成本升高 : : 要聲明的是： : : 一、我不認為在任何情況下， "可讀性" 和 "可維護" 一定優先於效能 : : 譬如寫嵌入系統底層（作業系統、驅動程式）的人， : : 除此以外，大部分的程式（應用程式），大部分的情況， "可讀性" 和 "可維護" : 在我的理解, "大部分"程式都是訂做的, 為了特定的需求, : 這些程式並沒有需要維護多少次, 只有套裝軟體或MIS系統才需要長期維護, : 盲目套用M$一類套裝軟體公司的模式, 只會增加成本降低效能如果一家公司接的專案都是 "小，而且只有一次，程式交差後就可以掉" 我不否認你的作法的確可行，但通常不會是這種情形一、從專案初期到後期，算不算一種維護？你的作法，減少了程式 "執行時的成本" ，但增加了 "維護的成本" 二、當寫出一個運作正常的程式後，可以對它 "做最佳化" 於是 "執行時的成本" 這種現象只會出現在專案初期一個 "可維護性" 高的程式，通常很容易做最佳化 : : 二、在真的需要效能的情況下， : : 一個架構良好，可讀性和可維護高的程式，通常可以很容易做最佳化又不會影響程式正確性 : : 但一個可讀性可維護性低的程式，若出了一個正確性的錯誤需要修正時， : : 常常會去影響其原先設計的效能機制 : : facebook 是規模一直在變大，也就是需求一直在變 : : 我相信， facebook 在成長的階段，也是也過分析、設計 : : 隨著規模一直在變大，一直有持續的分析、設計 : 這條是說明, 很多程式時效性第一, 所以也不能以維護性為優先一、你講的是市場的時效，這我不否認有時侯確實優先於 "維護性" 但是，前後提到的是 "效能" 跟 "維護性" 的比較這裡卻變成 "市場時效性" 跟 "維護性" 的比較二、很多時效，根本是老闆自以為的，市面上的商業網站那麼多真的因為先推出的攻佔市場的有幾個？除了 Facebook 和 Amazon 外，還有誰三、市場的時效很重要，然後呢？搶到時效，早於市場推出，然後呢？我們就可以不用維護了嗎？還是就可以不用考慮 "維護性" ？之後出問題，就推說 "那是因為因應市場時效性而亂寫的程式所留下來的，請不要動它" ？ Facebook 當初出來，難道是因為效能很好？十有八九，為了搶市場，反而是不注重效能的（一開始以學生為面向，估計以千、萬人為目標，而不是以億人為目標）等到成長到一定地步，才逐漸改善效能一個 "可維護性" 高的程式，通常很容易做最佳化 : : 規格書裡面的流程比code還多，是因為規格書考慮了很多例子 : : 如果 SA 直接用這個時間自己寫，你那麼寫出來的程式真有有考慮到那麼多？ : 考慮完=>操作word, 寫成英文, 圖表, 虛擬碼共1MB : 考慮完=>操作text editor寫成C 20KB : 哪個快? 請問，哪個出問題比較快？哪個因為 "啊，沒考慮到某種例子" 因而出問題比較快哪個因為 "撰寫某個模組時，因為沒考慮到另一個模組" 因而出問題比較快再請問，哪個出問題後，解問題比較快？你講的都只是 "先期看到樣品" 比較快真的等到的整合、測試時，你的作法常常會出問題 : : 請問，為什麼programmer "該" 知道整個架構, : : 在這套玩法中，SA、SD 是最重要的，PG 是最便宜的 : : 為什麼你認為 "知道整個架構" 的責任在 PG 上？ : : 我很好奇你的角色是什麼？ SA、SD、PG : : 還是標準台灣 RD = SA + SD + PG : : 沒錯，一點小小地修改都要找一群人開會, 大約要等二周 : : 但是，這也表示，因為一個人在一天內做出的一點小小地修改 : : 但因為沒有想清楚，造成整個系統的災難 : : 這就是公司的決策者要去衡量的 : 這個code規模很小, 如果同樣模式, 套在500MB source code的mozilla, : 那就是開會一年了一、Mozilla 是另一種關發模式，根本不適合二、Mozilla 這個例子跟你的例子根本不合你的例子看起來比較接近嵌入式系統 : : 再者，我很好奇，為什麼你的一點小小地修改，可以影響到很多模組 : : 你做的真的是一點小小地修改？ : : 模組的用義在於：主要介面定出來，模組內部怎麼亂搞，都不會影響外面 : : 如果因為一點小小地修改就影響到很多模組 : : 該考慮的是： : : 一、設計上可能有問題 : : 二、這可能真的不是小小的修改 : 理想上是這樣, 現實中這是不可能的 : 1. 用到硬體的時候, 前一個模組的設定會影響後一個 : 2. 用到UI的時候, 不同模組的畫面必須要連續 : 3. 用到系統資源的時候, 不同模組會搶資源 "不同模組的畫面必須要連續" ？所以不同的模組都要有 "使用者介面的畫面" 我只能說，模組不是這樣切的，至少把使用者介面切出來不要讓使用者介面影響到其它模組至少先有 MVC 的架構。用到系統資源的時候, 不同模組會搶資源？所以，切模組時，要分兩種，有些功能會用到系統資源，有些不會不要讓這些功能互相影響此外，為什麼你會覺得這是一種小小的修改一點小小的修改就會影響到整個系統你都不怕隨便改了，會導致系統出災難？你難道認為要一天內解決？我反倒這是設計上的問題，牽涉到設計的就不會是小問題認為二星期內解決也算合理？你覺得 "二星期內解決" 太久你該做的是 "改進設計"，而不是 "不要規格書" 你舉的例子看起來就是設計上有問題 : : C 比英文有結構 : : 但不代表你看了 C 程式碼，你就可以了解各種正確和失敗的例子 : 看到C, 可以確定程式怎麼實做的, 看到規格書, 只能知道曾經是這樣規劃的, : 規格書跟程式碼還不一定同步, 也許SA放假去, 也許PG亂寫... : 做一件事, 需要處理的手續越多, 就越沒效率: : 1. 一個大概的規格書, 只介紹20模組功能跟介面, 加上100K source code : 2. 20個模組詳細規格書pdf, 內含模組裡面的流程, 模組的模組, : 加上100K source code : 很明顯閱讀1比較快, 而且2只要一忙很容易就跟code失去同步, 比沒有糟糕 "2只要一忙很容易就跟code失去同步" 這點真的是管理有問題了想要玩規格，又不認真玩，又用 1 的方式去管理 2 以政府部門來舉例，若一件事，要經手的人多，要處理的手續多，的確沒效率可是，若一件事，隨便一個人，都可以隨意更改流程，的確可以增進效能但到時侯部門出問題的機率一定會變非常大 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.112.30.46

→