舊有的錯誤是多大的錯誤

作者: TonyQ (沉默是金。) 看板: Soft_Job
標題: Re: [閒聊] 你在開發程式時，是重視績效還是品質
時間: Sat Sep 17 00:48:33 2011

※ 引述《thinkniht (不下棋=.=)》之銘言：
: 在改別人寫的舊程式時
: 有的人會只改有變的地方
: 舊有的錯誤就不管他
: 有的人會寧願多花點時間做比較大的翻新
: 連原本舊程式沒有被人發現的問題都會想一起清掉
: (當然...這是在要翻修的範圍沒有過大的情況下)
: 各位...你們的話會傾向於哪種類型呢?


        碰到這種問題我通常是這樣想：

        1.It's a must have or nice to have ?

          舊有的錯誤是多大的錯誤

          錯誤對我來講就是顯著有邏輯上謬誤的地方，或者跑了會噴Exception的，
          如果只是架構的不一致，那不算是一種錯誤，那是複雜度成本。


          一般來講 nice to have 只有在我很有餘裕時才會去做，
          然後身為一個工程師我們要很謹慎看待 must have，

          對我們來講很多其實可以是 nice to have 的東西，
          都會被我們當成 must have。


          這個判斷是經驗跟 domain 累積下來的，沒有公式，沒有法則，
          做久了你就是會知道什麼架構之後會一直噴 exception ，

          而且你還會知道等他出事時你一定沒辦法好好處理，
          所以你要在這個當下把它處理掉。

          (ex. OR-Mapping 的 relation 設計，如果弄錯了基本上很難回頭。）


          你也會知道什麼事情是即使他隨時會炸掉，但是他炸掉影響不大，
          你也可以從容的把它修掉，所以可以歸類到 nice to have 。

         （ex. 你知道 system 有某情境下的 cache issue ，但當他發生的時候，
               你頂多要使用者重新整理來清 cache ，且使用者還是可以接受。）


        2.Eat your own bug.

        蝴蝶效應是這樣用的，即使是更正一個你底下的 typo ，
        都有可能在遙遠的彼方別人寫得部份造成更大的 bug，

        你能夠負責多大範圍的改動？

        但假如你今天跟我一樣，在一個 framework 商工作，
        已經累積了幾千幾萬個 user 在用同一份的 api 工作，

        不要說修改 public method 啦，光是要新增一個 public method ，
        加了你就不用想要移掉了，這時候你敢不敢改？




        假設你會改動的地方都是 private method ，ok 我完全舉雙手同意你改，
        只要你能每個 private method 都仔細測過。


        我個人過去的經驗讓我自己非常情緒化的痛恨程式設計師講一句話，
        「這只是改個錯字而已，絕對不會出錯的。」

        對，我自己講過幾十次，然後我也被這句話打臉打了不下十次，
        改個錯字真的還是會改出 bug ，還是過 production 之後。


        即使是我看過最強的設計師都會瞎眼的打出 typo ，
        良心建議大家對自己的 code 信心降一點比較好，這絕對是血淚談。XD


        Everything your change , everything you need to test it.



        已經存在的程式碼如果存在很久，那表示它已經跟環境磨合過了，

        除非你有辦法從蛛絲馬跡看出這東西根本沒人用，
        或者這東西是剛寫出來沒多久還不是很穩定的東西。



        不然我覺得這個問題真正的問法是，
        你有時間好好的把所有你改到的code 用到的地方都測過一次嗎？


        如果答案是 yes 你有時間，你也願意作。那就去吧。我不會阻止你。

        即使我知道大部分的狀況下，即使你真的做了還是會有不預期的 bug ，
        但是至少你已經比 80% 問這個問題的工程師來得有誠意太多了。


        永遠記得，沒有任何的 test 能比得上 production ，
        上了 production 還沒出事情的 code 他們都是閃爍著金色光環的程式碼。


        即使他是錯得東西，只要他真的上線的夠久，
        自然有其他的地方會將錯就錯...這就是這件事情恐怖的地方。


        而新寫得東西，還只是 Lv1 還沒被磨過的粗糙程式碼，
        需要時間把他們磨成像樣的東西，
        這也是其中一個總是優先考慮用 lib 取代自己做的理由之一。


        我覺得這個問題的問法如果換成這個形式，
        要或不要應該是你可以很清楚判斷得出來的才是。

        這個問題其實很簡單的，如果你用的方向跟我思考的方向一樣的話。


        觀察他們影響到哪些地方，你有沒有能力測試他們，
        還有你的環境允不允許這件事情帶來的不穩定性。


        一般來講，如果是我個人自己的專案，我非常不介意大改，
        只要我後續還有時間可以處理這些出來的問題。

        對公司或者客戶的專案，我會採取相對保守的態度。


        這是對風險管理的策略問題。

--
我：一半的日子讓你說，我聽你說你的所有 [1;37;42m______________________________________
[1;37;42m______________________________________一半的日子我想說，對你說過去的所有：我
        [1;32m_______________________________________________________

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

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 198.203.175.175
※ 編輯: TonyQ           來自: 198.203.175.175      (09/17 00:58)
推 bndan:推~雖然上工沒幾天 但我覺得這部份是跟學生時期最大的差距    09/17 01:16
推 ericinttu:紅字那一段, 可能是負負得正帶來的效應. 當自己只看到一  09/17 03:42
→ ericinttu:個負就覺得它是錯的而想改的話, 改下去錯的人就是自己.   09/17 03:43
→ ericinttu:那麼要怎麼改呢? 思維要先從"正向"的邏輯改成"負向"邏輯  09/17 03:44
→ ericinttu:, 確認會動到的相關地方(通常比想像來的大). 再去改.     09/17 03:45
推 lovdkkkk:傳說中的 side-effect programming !?                    09/17 03:49
推 zanyking:Side Effect Programmer很多啊，有沒有看過寫Java的       09/17 06:25
→ zanyking:開出來的Method argument都是Map，一個Call Hierarchy     09/17 06:25
→ zanyking:就是一開始一個Map一路往下丟，method回傳值是boolean     09/17 06:26
→ zanyking:所以那個Map會在途中加料好多次，最後還存在lifecycle     09/17 06:27
→ zanyking:Context 裡，同一個Lifecycle 裡的都用它。               09/17 06:28
→ zanyking:如果你把上面的敘述裡的Map換成噴，method換成pig。       09/17 06:29
→ zanyking:那就是這些開發者喜歡看見上一隻拉的等於下一隻吃得，     09/17 06:30
→ zanyking:最後剩下來的噴渣混合物還要保存下來等下一輪繼續吃。     09/17 06:31
推 ericinttu:但是大家都有東西可以吃啊 (爆)                         09/17 06:36