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

[oaz (幸福治安：破案數/十萬人)]

※ 引述《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
→ TonyQ:沒有任何作法可以產出「可維護性高」的ap 維護性跟需求
→ TonyQ:有高度相關，你今天專案再有彈性，需求跟你一百八十度轉彎
→ TonyQ:你一樣沒有可維護性。
如果你今天原本被要求寫關於醫療軟體，做到一半需求改為公司人員薪資管理之類的
的確不會有可維護性

不過，通常這種情形不會發生
→ TonyQ:有彈性 可擴充的 架構清楚的 ap 跟可維護性是兩回子事
是兩回事，但通常是正相關
→ TonyQ:至於可維護性高=最佳化剛好是逆命題，最佳化本身就是是一種
→ TonyQ:增加複雜度的作法，而通常增加複雜度也等於增加維護的困難。
最佳化的確在很多情況下是 "增加複雜度的作法" （或者說減少可讀性）
但我並沒有說可維護性高=最佳化

我說的是 "可維護性高通常可以很容易最佳化"

舉例來說，模組化通常是可維護性高
假設你有一百個模組，其中有二十個是最常執行的
而二十個中的四個，是隨時都在被執行的

於是，你可以採組類似這樣的策略
對二十個模組中的十六做最佳化，稍微犧牲一點可維護性

對剩下的那四個，做最極端的最佳化，
甚至完全不考慮未來的維護、可讀性，就算完全不可讀也無所謂
甚至，換更低階的語言也無所謂
（譬如原本是 Java 、Python，改用 C/C++ ，原本是 C/C++ ，改用組語）

總體來說，整個程式中無法維護的部分，也不過就是四個模組
就算有天需求改了，要動到這四個模組，但也不過就是四個而已（相較於原本的一百個模組）

此外，最佳化應該在專案後期，真的有必要才做
也就是，就算專案中間有需求改了
但因為程式可維護性高（尚未做最佳化），因此很容易做出相對應的改變
也不會因為太早最佳化，導致可維護性降低，但又因需求改變，先前的最佳化反而變白工
→ TonyQ:再用可維護性作為標的之前，有本事的就先為可維護性下定義吧
→ TonyQ:最佳化在任何情況下都不是一種禮物，而是一種負債。
這不用我定義，很多書都有
大部分的情況下，架構良好、可讀性高，通常可維護性就高
→ TonyQ:要考慮最佳化，正是為了需求考量而不得不借下複雜度債務。
→ TonyQ:有彈性可擴充是好事，但是我對「可維護」這個詞有意見。
→ TonyQ:事實上我看過得專案，大多是被不當的需求分析跟需求管理把
→ TonyQ:維護性毀掉的，而不是系統架構沒有維護性。
我只能說，SA、SD 很重要
※ 編輯: oaz             來自: 140.112.30.46        (11/15 04:06)
→ TonyQ:我們現在面對的問題就是，通常這種情形一直發生。
→ TonyQ:我同意SA、SD很重要，不過這方面只要沒有明確的方法論，就
→ TonyQ:還是只能倚賴主導者的能力。SA也好、SD也好，甚至是PG也好
→ TonyQ:甚至在我觀摩的team 也有專責寫doc的技術人員，但一樣的制度
→ TonyQ:兩個不一樣的team執行出來的可以天差地遠，而且我在的還是一
→ TonyQ:個投入大量預算的專案。已經不是台灣那種小鼻子小眼睛的專案
→ TonyQ:你說的東西看似方法論，但其實這是取決於SA/SD的經驗和能力
→ TonyQ:有能力者你不用說他也會這麼做，沒能力者，他也想這麼做，
→ TonyQ:但做起來就是亂七八糟...
→ TonyQ:再者，很多專案根本就是亂來，他們一開始就只打算炒短線
→ TonyQ:不管後續維護的，所以他們根本就不想認真丟出所有成本，像
→ TonyQ:詐騙集團稿預售屋一樣 弄出骨架就跑路了。XD
→ TonyQ:這種專案你去跟他們談SA SD 也沒意思，我是覺得這也是非戰之
→ TonyQ:罪啦，台灣也很有些重視這些東西的地方。
→ TonyQ:但不走這一套也不見得不能成事就是了，方法很多的。
→ TonyQ:然後我不認同你的立論「大部分情況下，架構良好、可讀性高
推 TonyQ:可維護性就高」。因為大部分會因為最佳化把可讀性犧牲掉。
→ TonyQ:並且除非你需求管理作得非常好，不然架構髒掉是時間問題。
→ TonyQ:通常只有老人家會覺得架構良好 可讀性高，但新人接手就死定
推 thinkniht:大推TonyQ的最後一句 本人真是深有同感
→ thinkniht:看過一些資深或被認為技術很強的人
→ thinkniht:東西沒遵守OO的原則 註解沒怎麼寫 很難用一.一
→ atst2:OOD/A,XP,都是方法論的一環,不是不存在,而是沒人鳥他...- -a
→ TonyQ:OOD/XP 作為方法論還是很需要時間磨練吧。:P
→ atst2:問題不在於時間,當用到"方法"時,就代表這種做法更有效率
→ atst2:從整體的效益來看,一定能加速開發與經驗的傳承.
→ atst2:通常真正的問題,在於心理上的層面.
→ atst2:舉例來說,版上各位一定有遇過公司上層想要推某種開發方式
→ atst2:基層也認為該改變，但最後全部一事無成的情況...
→ atst2:這種情形下,去問上層的一定是說下面人反彈超大,問下面的亦然
→ atst2:明明所有人都知道該怎麼做,然而"積習難返",以致於失敗
→ atst2:此時已然跟"方法"的好壞,適合與否,全然無關,而是人心的問題
→ atst2:版上很多對於工程方法的討論,都很有見地,不過工程方法的實行
→ atst2:成敗並不是光工程師便可決定...大部分公司都忽略了PM,Sales
→ atst2:以及其他相關的合作部門,也必需要有一定的工程方法上的認知
→ atst2:甚至在跟客戶合作時,也必需要引導客戶進入開發的流程中...
→ atst2:有時會覺得需要去讀工程方法的,並不是RD,而是PM與Sales T.T
推 codemonkey:開發方法要真正成為團隊的文化、語言才有用處的，
→ codemonkey:如果只是拿來當SOP、文件格式...意義不大
→ Lordaeron:oaz 這麼有架構能力,想必工作很久,做過很多案子的.
→ Lordaeron:可以show 一兩個來看看嗎?
→ Lordaeron:否則這種必定的空話, 就不要在這高談了.
→ Lordaeron:因為教科書早十年前就這樣子講了.
→ Lordaeron:但偏偏在這個地球上沒發生過像教科書講得哪麼順利的.
推 thinkniht:同意codemonkey大 有些SA文件只是文件
→ thinkniht:不具甚麼SA的功用
推 pingsky:我推這篇... 這和我自己的工作多年的經驗相符
→ pingsky:然後請別要我 show 在那裡工作, 做過什麼案子, 謝謝
推 yoco315:我推這篇,可維護的程式比較容易作最佳化
→ yoco315:我還蠻訝異以 Tony 的程度會沒有這個認知 ＠＠
推 LetDogDay:推這篇...也不要問我在那裏工作...做過啥案子...謝謝
→ TonyQ:yoco 我對維護性的推文寫在下一篇
→ TonyQ:我認為彈性高、可讀性高、架構清楚的程式碼會比較容易做最
→ TonyQ:佳化。不過我不喜歡「維護性高」是因為維護性跟著需求來。
→ TonyQ:你說自己專案維護性高，就容易吸引挑戰你維護性的需求來。:P
→ TonyQ:直接回文了。