Re: [閒聊] 你在開發程式時,是重視績效還是品質

看板Soft_Job作者 (沉默是金。)時間12年前 (2011/09/17 00:48), 編輯推噓8(8010)
留言18則, 7人參與, 最新討論串2/11 (看更多)
※ 引述《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 取代自己做的理由之一。 我覺得這個問題的問法如果換成這個形式, 要或不要應該是你可以很清楚判斷得出來的才是。 這個問題其實很簡單的,如果你用的方向跟我思考的方向一樣的話。 觀察他們影響到哪些地方,你有沒有能力測試他們, 還有你的環境允不允許這件事情帶來的不穩定性。 一般來講,如果是我個人自己的專案,我非常不介意大改, 只要我後續還有時間可以處理這些出來的問題。 對公司或者客戶的專案,我會採取相對保守的態度。 這是對風險管理的策略問題。 -- 我:一半的日子讓你說,我聽你說你的所有______________________________________ ______________________________________一半的日子我想說,對你說過去的所有:我 _______________________________________________________ 在討論中妥善扮演兼具聆聽與分享的角色,是我們一生的課題。 _______________________________________________________ -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 198.203.175.175 ※ 編輯: TonyQ 來自: 198.203.175.175 (09/17 00:58)

09/17 01:16, , 1F
推~雖然上工沒幾天 但我覺得這部份是跟學生時期最大的差距
09/17 01:16, 1F

09/17 03:42, , 2F
紅字那一段, 可能是負負得正帶來的效應. 當自己只看到一
09/17 03:42, 2F

09/17 03:43, , 3F
個負就覺得它是錯的而想改的話, 改下去錯的人就是自己.
09/17 03:43, 3F

09/17 03:44, , 4F
那麼要怎麼改呢? 思維要先從"正向"的邏輯改成"負向"邏輯
09/17 03:44, 4F

09/17 03:45, , 5F
, 確認會動到的相關地方(通常比想像來的大). 再去改.
09/17 03:45, 5F

09/17 03:49, , 6F
傳說中的 side-effect programming !?
09/17 03:49, 6F

09/17 06:25, , 7F
Side Effect Programmer很多啊,有沒有看過寫Java的
09/17 06:25, 7F

09/17 06:25, , 8F
開出來的Method argument都是Map,一個Call Hierarchy
09/17 06:25, 8F

09/17 06:26, , 9F
就是一開始一個Map一路往下丟,method回傳值是boolean
09/17 06:26, 9F

09/17 06:27, , 10F
所以那個Map會在途中加料好多次,最後還存在lifecycle
09/17 06:27, 10F

09/17 06:28, , 11F
Context 裡,同一個Lifecycle 裡的都用它。
09/17 06:28, 11F

09/17 06:29, , 12F
如果你把上面的敘述裡的Map換成噴,method換成pig。
09/17 06:29, 12F

09/17 06:30, , 13F
那就是這些開發者喜歡看見上一隻拉的等於下一隻吃得,
09/17 06:30, 13F

09/17 06:31, , 14F
最後剩下來的噴渣混合物還要保存下來等下一輪繼續吃。
09/17 06:31, 14F

09/17 06:36, , 15F
但是大家都有東西可以吃啊 (爆)
09/17 06:36, 15F

09/17 11:12, , 16F
大推~非常中肯~~尤其是改錯字那邊@@b~~
09/17 11:12, 16F

09/17 14:57, , 17F
推錯字T_T
09/17 14:57, 17F

09/19 12:28, , 18F
推好文
09/19 12:28, 18F
文章代碼(AID): #1ESttZCZ (Soft_Job)
討論串 (同標題文章)
完整討論串 (本文為第 2 之 11 篇):
文章代碼(AID): #1ESttZCZ (Soft_Job)