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

[sniffer (again)]

※ 引述《oaz (幸福治安：破案數/十萬人)》之銘言：
: 事實是：80-20 法則，程式有 80% 的時間花在 20% 的程式碼
: 甚至是 90-10 法則
: 要改善效率主要有兩個方法：
: 一、先寫出比較有彈性、可讀性較高的程式
: 再找出比較花時間的部分，對
: 二、不管三七二十一，就算沒有彈性、可讀性會變差
: 但撰碼時一律用最有效能的方式寫
: 事實上，第二種方式寫出來的程式並不一定會第一種有效能
: 第二種方式，很可能會了很多時間、人力，但都省在那種無關緊要的地方
: 甚至，可能會更慢
: 譬如，使用 cache 機制通常可以增加效能
: 但不適當的 cache ，在沒必要做 cache 的地方做 cache
: 程式反而要另花成本去維護 caceh ，反而是減少效能
: 不知道你有沒有遇過：在一開始寫得很美好，考慮了效能，使用了一些 cache 機制
: 在撰碼時就用最佳化的方式去寫程式，但比較沒有彈性，可讀性較差
: 但因為運作不錯，效能又跑不錯，就接受
: 等到期限前，忽然發現有 bug ，因為 cache 機制有問題，或者使用不當
: 或者使用雙重 cache ，又沒有把溝通流程搞清楚
: 但因為期限快到了，就另外硬加一套機制去修正
: 但新加的這套機制又無法顧及原先的 cache 機制
: 極端一點，甚至程式為了正確性，反而要資料都從新的機制拿
: 但舊的 cache 機制又不管拿掉
: 結果是，程式的效能最後是變差的

這只是說明一開始沒有設計好, 沒有做複雜度分析,
規劃永遠是要的, 但是規劃不應該以維護性為優先

: 要聲明的是：
: 一、我不認為在任何情況下， "可讀性" 和 "可維護" 一定優先於效能
: 譬如寫嵌入系統底層（作業系統、驅動程式）的人，
: 除此以外，大部分的程式（應用程式），大部分的情況， "可讀性" 和 "可維護"

在我的理解, "大部分"程式都是訂做的, 為了特定的需求,
這些程式並沒有需要維護多少次, 只有套裝軟體或MIS系統才需要長期維護,
盲目套用M$一類套裝軟體公司的模式, 只會增加成本降低效能

: 二、在真的需要效能的情況下，
: 一個架構良好，可讀性和可維護高的程式，通常可以很容易做最佳化又不會影響程式正確性
: 但一個可讀性可維護性低的程式，若出了一個正確性的錯誤需要修正時，
: 常常會去影響其原先設計的效能機制
: : 2. 如果facebook慢慢做系統分析, 慢慢研究使用者行為, 慢慢推敲架構會不會DoS,
: : 那他就不會成功, 先做出來才是重點
: facebook 是規模一直在變大，也就是需求一直在變
: 我相信， facebook 在成長的階段，也是也過分析、設計
: 隨著規模一直在變大，一直有持續的分析、設計

這條是說明, 很多程式時效性第一, 所以也不能以維護性為優先

: : 蓋房子設計師無法自己搬一棟樓的磚, 但是規格書裡面的流程假如比code還多,
: : SA直接用這個時間自己寫, 都已經做好了
: 規格書裡面的流程比code還多，是因為規格書考慮了很多例子
: 如果 SA 直接用這個時間自己寫，你那麼寫出來的程式真有有考慮到那麼多？

考慮完=>操作word, 寫成英文, 圖表, 虛擬碼共1MB
考慮完=>操作text editor寫成C 20KB
哪個快?

: : 一個很"正規"的例子, 世界前三大某IC豬屎屋, 他們的SDK就是在印度寫,
: : 採用"正規"作法, 裡面每個模組都帶有比code還多的規格書, 測試報告,
: : 其實這個產品全部的code只有幾MB, 但是拆成一百多個模組,
: : 於是當我要修改電路板某個clock, 問他們的人會影響哪裡,
: : 這件事情沒有人能告訴我, 所有的programmer都沒有辦法知道整個架構,
: 請問，為什麼programmer "該" 知道整個架構,
: 在這套玩法中，SA、SD 是最重要的，PG 是最便宜的
: 為什麼你認為 "知道整個架構" 的責任在 PG 上？
: 我很好奇你的角色是什麼？ SA、SD、PG
: 還是標準台灣 RD = SA + SD + PG
: : 一點小小地修改都要找一群人開會, 大約要等二周,
: 沒錯，一點小小地修改都要找一群人開會, 大約要等二周
: 但是，這也表示，因為一個人在一天內做出的一點小小地修改
: 但因為沒有想清楚，造成整個系統的災難
: 這就是公司的決策者要去衡量的

這個code規模很小, 如果同樣模式, 套在500MB source code的mozilla,
那就是開會一年了

: : 或者自己看海量的文件, 找出所有用到這個clock的模組
: 再者，我很好奇，為什麼你的一點小小地修改，可以影響到很多模組
: 你做的真的是一點小小地修改？
: 模組的用義在於：主要介面定出來，模組內部怎麼亂搞，都不會影響外面
: 如果因為一點小小地修改就影響到很多模組
: 該考慮的是：
: 一、設計上可能有問題
: 二、這可能真的不是小小的修改

理想上是這樣, 現實中這是不可能的
1. 用到硬體的時候, 前一個模組的設定會影響後一個
2. 用到UI的時候, 不同模組的畫面必須要連續
3. 用到系統資源的時候, 不同模組會搶資源

: : 文件比code還多的時候, 所謂的好維護根本只是為了以後可以告訴你,
: : 他文件"有"寫到, 在編號E1046875r467文件的677頁120行....
: : 找文件不會比找code方便, code至少是100%文字檔, C也比英文有結構
: C 比英文有結構
: 但不代表你看了 C 程式碼，你就可以了解各種正確和失敗的例子

看到C, 可以確定程式怎麼實做的, 看到規格書, 只能知道曾經是這樣規劃的,
規格書跟程式碼還不一定同步, 也許SA放假去, 也許PG亂寫...

做一件事, 需要處理的手續越多, 就越沒效率:
1. 一個大概的規格書, 只介紹20模組功能跟介面, 加上100K source code
2. 20個模組詳細規格書pdf, 內含模組裡面的流程, 模組的模組,
加上100K source code

很明顯閱讀1比較快, 而且2只要一忙很容易就跟code失去同步, 比沒有糟糕

--
※ 發信站: 批踢踢實業坊(ptt.cc) 
◆ From: 122.116.218.88
推 codemonkey:我這幾個月下來，SA,SD規格書已經改了3~4個版本了
→ codemonkey:因為老闆、客戶『每次』想看、『看得懂』的東西都不同
→ codemonkey:看SA把他改成SD, 看SD改成SA, 兩份一起交說不要寫這麼
→ codemonkey:細大家會看不懂，寫簡單一點又說要定義清楚.........
→ codemonkey:當然和Facebook、Google的API Manual相比，我已經盡量
→ codemonkey:把文件弄得像是繪本了，反正PG到時候也是看循序圖來寫
→ yishin0517:其實我很想說~~這在台灣需求永遠跟規格是不一樣的
→ codemonkey:不會去讀文件的內容......因為客戶要的、文件寫的、
→ codemonkey:程式寫的 ... 大家都知道...很難同步
推 codemonkey:這個情況在小吃店很常見
→ codemonkey:『老闆，紅燒牛肉麵一碗、蔥多一點』
→ codemonkey:『啊等一下，煮好了嗎？在煮麵喔，那幫我改酸辣湯餃』
→ codemonkey:『麵喔...這個客人不是點大滷麵嗎，就拿去煮大滷麵吧』
→ andymai:有的小吃店老闆很火爆的~小心被趕出店門外...XD
推 aecho:能對規格做決策的人太多，很容易會失去一致性吧。
→ yoco315:規模、規模、規模，你規模小，隨便作作就好，沒文件沒差
→ yoco315:規模大，你就去衝吧，沒人攔你 -_-
→ yoco315:講不聽，老是在那邊「大公司寫文件有夠僵化」的論調..
→ yoco315:聽都聽煩了，殊不知人家之所以能變成大公司就是因為有文件