很難有架構設計是可以在需求不明時就先設計都設計的

作者: TonyQ (自立而後立人。) 看板: Soft_Job
標題: Re: [請益] 有公司用這種開發方式嗎?
時間: Fri Nov 18 00:43:09 2011

※ 引述《oaz (幸福治安：破案數/十萬人)》之銘言：
: ※ 引述《sniffer (again)》之銘言：
: 因此，當 "規劃以維護性為優先" ，之後通常很容易可以改進效能
: 但是，當 "規劃以效能為優先" ，之後常常時維護成本升高


        直接回文講好了。


        所謂的規劃以「維護優先」隱含的意思是，

        代表你事先設想了一套需求，而針對這些需求去進行處理。


        很難有架構設計是可以在需求不明時就先設計都設計的，

        真的這麼做也很容易變成過度設計。


: 如果一家公司接的專案都是 "小，而且只有一次，程式交差後就可以掉"
: 我不否認你的作法的確可行，但通常不會是這種情形
: 一、從專案初期到後期，算不算一種維護？
: 你的作法，減少了程式 "執行時的成本" ，但增加了 "維護的成本"
: 二、當寫出一個運作正常的程式後，可以對它 "做最佳化"
: 於是 "執行時的成本" 這種現象只會出現在專案初期
: 一個 "可維護性" 高的程式，通常很容易做最佳化
: : 這條是說明, 很多程式時效性第一, 所以也不能以維護性為優先
: 一、你講的是市場的時效，這我不否認有時侯確實優先於 "維護性"
: 但是，前後提到的是 "效能" 跟 "維護性" 的比較
: 這裡卻變成 "市場時效性" 跟 "維護性" 的比較
: 二、很多時效，根本是老闆自以為的，市面上的商業網站那麼多
: 真的因為先推出的攻佔市場的有幾個？除了 Facebook 和 Amazon 外，還有誰
: 三、市場的時效很重要，然後呢？
: 搶到時效，早於市場推出，然後呢？我們就可以不用維護了嗎？
: 還是就可以不用考慮 "維護性" ？
: 之後出問題，就推說 "那是因為因應市場時效性而亂寫的程式所留下來的，請不要動它" ？


: Facebook 當初出來，難道是因為效能很好？
: 十有八九，為了搶市場，反而是不注重效能的
: （一開始以學生為面向，估計以千、萬人為目標，而不是以億人為目標）
: 等到成長到一定地步，才逐漸改善效能
: 一個 "可維護性" 高的程式，通常很容易做最佳化


        我以為facebook 就是一個搶時效，
        並且需求大幅改變導致原本的維護性不夠用的例子耶？

        他們之後打掉重練也好幾次，不是嗎？


        而且事實上，對一萬人跟對十萬人的applicaiton ，
        通常基本只靠這種程度的架構上的最佳化是不夠的。

        更多的時候是從資料結構或者是處理結構上就特化了。

        （ex. plurk 在 nodejs  跟j2ee 架構上的過渡時期）


        一個有彈性、有架構、可讀性高的程式碼，會比較好切分架構。

        一個「可維護性高」的程式碼基本，
        應該要包含有彈性、有清楚架構、可讀性高的程式碼，


        但是你怎麼驗證有沒有可維護性？



        專案中一定會有許多假設。


        我舉個我曾經碰過得例子，我曾經幫書商寫過程式，

        當時他們提到有三種角色，業務、業助、工讀生，有不同表格。


        當時確認需求時提到一次只會有一種角色登入。


        結果正式上線時，突然冒出需求說有人既是業助、也是業務。

        哦哦，這下慘了。:P



        因為有一些資料是只有業助能看，有些資料是只有業務能看，

        當時都假設一個人只有一個角色，所以要重新設計業務邏輯。


        這種狀況，即使你有完美的彈性、架構、可讀性，

        如果你事先不知道需求會這樣轉彎，你還是很難留這個迴旋的空間。


        我不是說做不到，而是在專案架構上你難免會有所犧牲，
        有時候你會為了修正一些枝葉砍倒一顆大樹，有時則否。



        問題是我怎麼知道需求會這樣轉彎，這就是經驗加上需求管理。


        我認知的維護的定義不只bug fixing ，也包含 optimze ，
        更也包含需求的調整跟細節微調。

        抱歉，只要你需求無法管理好，這個系統你怎麼維護？


        就算不是在專案結束之後的維護，
        光是這種需求在開發期間大轉彎個幾次，你怎麼維護？



        你跟我說這種需求很少發生？


        某 single page 網站資料都從 service 來，上線過三個月之後，

        突然要將網站兩成左右的資料改從另一個 service 來，

        UI 也都全部要更著更新。

        Single page 就是類似 gmail 那樣的系統，是比較偏向ap等級的東西，

        是個擁有數百個不同表單跟 UI 的龐大 AP，

        即使當初專案架構上就保有這個彈性，還是很多實做上的細節需要被犧牲掉。



        改變無所不在，每一個改變都會折磨你的系統，

        除非你當初設計時就能夠預料到所有改變，

        除非你運氣夠好都沒踢到會違反你「核心假設」的需求，

        或者已經有人盡了他們的責任做好需求管理，否則這麼說實在是有點天真。

        這才是容易讓程式碼髒掉的理由，我不是在幫那些不負責任的RD找藉口。


        我也不是在說因為這樣，所以我們不用寫有可讀性、有彈性、架構清楚的code，

        我在說的是，即使你這麼做了，「可維護性」還是大幅度的掌握在別人手上。


        我不是在跟你說書上的言論，我在跟你說的是現實。



        也不用跟我說什麼只有台灣會這樣的瘋話，

        我現在在美國，半年來我們也參與同一組織的三個專案，

        看見的這些專案也都是有這樣的情形，這不是特例。


        SA/SD 在這種總額幾千萬美金的B2B專案，他們都有專門的人在進行，

        每個需求都可以拿到清楚的 use case ，

        還能有專門的QA流程 ，但是有做不代表一定有分。


        一樣會因為爛client的鳥需求而鳥掉，所以我不是在開玩笑，我很認真的說，

        需求管理也是我們RD雖然不能直接面對，但不能忽視的敵人。




        他們頂多是願意用很多的時間跟精力去重新（調整或重寫）架構，

        這點上他們比台灣願意出錢，但是具體上會不會反應在程式碼上，

        取決於實做的RD跟當時的預算、架構師。


        ---------------

        我強調，我完全同意使用者，
        應該寫高可讀性、具有彈性、有組織架構清楚的程式碼，

        這是程式人的本分，我完全沒意見。


        基本上 oaz 只要把維護性的字眼拿掉，
        換成可讀性、有彈性、架構清楚，我就沒什麼意見。


        我只是不認同「在不談論需求的狀況下談論維護性」，

        這不是個工程師本位的世界，維護性是一個專案術語，
        它是一個很容易引起誤會跟爭議的詞。


        「容易維護」這件事情在沒有良善的需求管理前題下，
        只會是一句非常好笑的笑話。


        事實上大多數提到維護性的論述中都會提到需求管理，
        但我們RD討論維護性時，卻往往只獨漏需求管理而討論程式碼層次。

        這不是拼積木，不是五塊裡面我們拿到四塊，
        就可以說我們完成80%所以很高，這少哪一塊就都有機會變成0%的。:P


        這也是我個人會希望分享給開發者的意見，

      別從規格思考實做，要從需求思考實做。

--
當然，這是個人意見的論述啦；
個人見解並不能代表什麼，只能代表有人這麼想而已。:)
--
我：一半的日子讓你說，我聽你說你的所有 [1;37;42m______________________________________
[1;37;42m______________________________________一半的日子我想說，對你說過去的所有：我
        [1;32m_______________________________________________________

        在討論中妥善扮演兼具聆聽與分享的角色，是我們一生的課題。
        [1;32m_______________________________________________________

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 198.203.175.175
※ 編輯: TonyQ           來自: 198.203.175.175      (11/18 01:00)
※ 編輯: TonyQ           來自: 198.203.175.175      (11/18 01:01)
※ 編輯: TonyQ           來自: 198.203.175.175      (11/18 01:02)
推 mgtsai:真槍實彈的言論，比起只看幾本軟工的書來得真切             11/18 01:47
→ mgtsai:需求大轉彎的例子實在到處可見，可惜很多人輕忽它的存在     11/18 01:48
→ mgtsai:即使保守如銀行業的案子，也會碰到需求大轉彎的例子         11/18 01:48
→ mgtsai:董事會的決議，政府法令的調整，會計準則的變更             11/18 01:49
→ mgtsai:我曾經在一個案子的進行過程中，前後碰到上述三個事件       11/18 01:50
→ mgtsai:你寫軟體的，架子再怎麼大，大得過董事會？大得過法律？     11/18 01:51
→ mgtsai:談程式的維護性，若忽略需求變更的影響，那只是淪為空談     11/18 01:53
推 andymai:推!只有真的寫過、體會過才更能知道問題在哪~沒有那種可以  11/18 08:51
→ andymai:考慮到"全部需求"的程式~因為那叫AI~它也不需要維護XD      11/18 08:53