作者stu87616 (文組工程師)
看板Soft_Job
標題[討論] 效能與易維護性的取捨?
時間Sat Jan 20 22:24:29 2018
各位先進好，
小弟現在手上的專案迎來了一次架構優化的機會，正好由我負責
為了達成某個特定的小需求，我發現下到底層去客製一些接口就可以完美做到，
由於本來份內的工作就完成得很快，我就利用多餘時間如火如荼地進行實作。
雖然花了不少時間，但該作法確實是可行的，
於是我在基本架構實現到八成左右後與團隊討論是否能夠整進專案內，
這時成員就提出了質疑
1. 原先目的的那個小需求，不客製接口，只用原生的，
再加上一些額外的流程一樣做得到，只大概會損失 10% ~ 20% 的效能，
而且這個效能長期來說可以忽略，沒有必要多花這麼多時間串接；
2. 這個客製流程我就算有信心改到沒 bug 真的可以用，
我走了的話，以後的人會很難維護
第一點我不介意多花時間來做這個流程，畢竟都做得差不多了，也很有成就感
第二點就無法反駁了，我完全沒有信心能夠把這套流程完美交接給別人
這個問題讓我陷入了困惑，在以前做一人專案的時候，
我可以毫不顧忌的追求效能，偶爾也會寫得很髒
但是要考慮到易維護性的話，很多東西就要變的綁手綁腳了
想請問，像這樣的抉擇，通常都是怎麼選呢
--
我覺得
Ｃ＃是世界上最強的語言了 π紅膠咖咖褐希希
Ｃ ◥▁▁▁▁ ◢ 麥
其他的應該廢除 省寶水啡啡雨嘉
＃ ◤
██ ／-
科
石 食 燕嘉
□–□◢◤ 舒
如果各位有興趣的話，可以現在開始學
譜
▼ㄑ ◢ 服
但是要安裝
VisualStudio ▼ㄧ ／◣ 特
因為我們只會支援
精英IDE，絕對不會接受
垃圾 ψ ◢ /◣– ◤ /█◣
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 101.8.147.212
※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1516458274.A.EC1.html
1F：→ angusyu: 留下文件不就好了嗎？都做完了還在那邊唧唧歪歪 01/20 22:32
2F：→ testPtt: 看要不要改 01/20 22:33
3F：推 maxqq: 無論如何文件都要寫得乾淨 01/20 22:38
4F：→ maxqq: 第二個我想你提的方案可以在未來效能擴充時的參考方案 01/20 22:39
5F：→ maxqq: 留下註解與方法即可 01/20 22:39
6F：→ maxqq: 容易維護，有時真的必須放第一考量 01/20 22:40
7F：推 SHANGOYANYI: 你客製化新的接口 舊的還在吧？ 新的別人不會用叫他 01/20 22:42
8F：→ SHANGOYANYI: 們繼續用舊的啊... 01/20 22:42
因為專案最後勢必是選一個做，
成員當然就會覺得如果我打從一開始就用簡單作法，就沒有轉移成本了
當下我都有衝動說那我兩個都做算了(還好沒說
※ 編輯: stu87616 (101.8.147.212), 01/20/2018 22:50:12
9F：推 CGS0: 留下文件 想一下怎麼教別人 01/20 23:20
10F：→ netburst: 管以後幹嘛 你只要管你接下來自己開發上好不好寫 01/20 23:55
11F：→ netburst: 離職以後都不甘你的事 01/20 23:56
12F：→ netburst: 多改了會加薪嗎 出BUG也是你死 01/20 23:56
13F：→ vi000246: 重構很髒的程式碼 達成效能跟維護兼顧 01/21 00:50
14F：→ vi000246: 不過我會選1 反正上面不在意就好 幹嘛多花時間做 01/21 00:52
15F：推 t64141: 在效能沒大問題前提下，我會以程式碼的乾淨優先 01/21 00:54
16F：→ t64141: 畢竟維護的是人，為了一點點效能犧牲維護性長期來說不一定 01/21 00:55
17F：→ t64141: 是好事 01/21 00:55
18F：推 CCben: 只聽leader的話就好，問它想要什麼。不要管你隊員講什麼可 01/21 01:23
19F：→ CCben: 維護性，因為說不定你現在接手的爛程式碼就是來自要求須有 01/21 01:23
20F：→ CCben: 可維護程式碼的豬隊員^^ 01/21 01:23
21F：噓 darkMood: 當然是易維護性啊，反正又不追求效能，別拖累別人啊 01/21 01:29
22F：→ y3k: 追求效能是機器運作效能還是人的作業效能? 01/21 01:34
23F：→ y3k: 前者還OK 後者我就認為糟糕 01/21 01:35
24F：→ y3k: 有些程式碼根本是外行人寫出來 只是可以動而已 這種當然要修 01/21 01:36
25F：→ y3k: 阿 除非只是一個已經快死的專案... 01/21 01:37
26F：→ y3k: 阿 我第一句可能造成誤會 說的是"現在"的作業效能XD 01/21 01:38
27F：推 strlen: 效能成本可以承擔的情況下當然選擇易維護性 01/21 01:59
28F：推 strlen: 文件和註解可以寫 但最好不要將之視為主軸 01/21 02:01
29F：推 abccbaandy: 沒有效能需求當然選易維護阿...不過好奇20%效能差異是 01/21 02:19
30F：→ abccbaandy: 什麼架構阿，有點猛 01/21 02:20
31F：→ joyce66789: 有沒有bug是你走後別人說的，不是你說的算。後人沒有 01/21 02:23
32F：推 RunRun5566: 少寫文件ㄅㄅ 01/21 06:07
33F：推 del680202: 像原PO這行為 在我公司稱作工程師的暴走 01/21 08:08
34F：推 del680202: 自high 請在不影響他人為前提 01/21 08:10
35F：推 shiauji: 易維護 框架再好爛掉沒人維護也沒用 01/21 08:18
36F：→ pttworld: 原本需求用量的評估。不常用的維護性優先 01/21 08:53
37F：推 stephen23032: 效能瓶頸不在這裡的話上我會選擇好用的，不是技術展 01/21 10:07
38F：→ stephen23032: 示。 01/21 10:07
39F：推 mozume: 先寫好維護的,有效能需求再調,在公司內寫可能會轉手多人的 01/21 10:07
40F：→ mozume: 程式時要先預定自己和接手是笨蛋的概念,文件不可信 01/21 10:08
41F：→ mozume: 推薦閱讀之前討論「如何沉住氣讀別人的 code」系列 01/21 10:10
42F：→ alan3100: 改底層又不能交接給別人 這就是地雷 01/21 11:16
43F：推 yyc1217: 我會以如何讓他人輕易上手維護為第一 如果效率只差一點點 01/21 11:24
44F：→ yyc1217: 的話 01/21 11:24
45F：→ yyc1217: 畢竟系統會一直改 不可能就這樣永遠不變 01/21 11:24
46F：→ yyc1217: 甚至是為了三個月後的自己著想 01/21 11:25
47F：→ ChoDino: 如果那接口是整個系統的瓶頸，你改寫他才有意義。 01/21 11:38
48F：推 shortoneal: 其實你一開始合的時候找人幫忙review就好 01/21 11:39
49F：→ shortoneal: 優化根可維護很少是完全衝突的，大部分都是懶的藉口 01/21 11:40
50F：→ ChoDino: 不然就是造成維護上的困擾。如果資源都用不完卻花時間在 01/21 11:41
51F：→ ChoDino: 這，是不明智的事。 01/21 11:41
52F：→ shortoneal: 今天如果你拿這種戰績去外面面試嘴砲，大部分會是扣分 01/21 11:41
53F：→ shortoneal: 而不是加分 01/21 11:41
54F：推 james732: 想知道這10%的提昇會有什麼好處？ 01/21 11:48
55F：→ james732: 更實際的說，可以讓公司省錢稅賺錢嗎 01/21 11:48
56F：→ james732: 省錢或賺錢 01/21 11:48
57F：推 clamperni: 如果是架構的話人腦效率比較重要 01/21 11:58
58F：推 WiseLin1125: 哪那麼複雜，問leader就好 01/21 12:14
59F：推 olen0622: 你不必想這麼多 這種專案都是能交件能丟給碼農維護優先 01/21 12:22
60F：→ olen0622: 不用特地想說我能把這東西做多好 風險人家無法承擔 01/21 12:22
61F：→ olen0622: 事實是你能優化搞不好大家也行阿 但有其他考量且沒必要 01/21 12:24
62F：推 Argos: 這不是廢話？沒人在乎效能差距當然是易維護性為最高考量 01/21 13:38
63F：→ Argos: 極度不專業的人才會在不要求效能的狀況下為了效能搞爛code 01/21 13:39
64F：→ Argos: 就算是要求效能 那也要把影響效能最大的核心割出來 01/21 13:40
65F：→ Argos: 其它部份還是以易維護性為最高考量 基本中的基本中的基本 01/21 13:41
66F：→ saladim: 好奇新改的介面是有多難懂跟多複雜? 01/21 14:47
67F：推 za755188: 大家都發明新的路 最後程式無法維護 01/21 15:14
68F：推 abc0922001: 當然是效能差又難維護，後面有事做+只有你能做（X 01/21 16:11
69F：→ atpx: 以管理面來說, 效能不是主要考量的情況還是以維護性為主 01/21 16:28
70F：→ iceonly: 挖，這10%是怎麼算的 01/21 18:40
71F：→ MOONY135: 只有自己才看的懂的...半年之後應該就會靠北自己了吧 01/21 19:09
72F：推 justben: 鍵盤工程師猜:底層那段應該只有你知道吧 建議就是 01/21 20:38
73F：→ justben: 把底層那段接口 寫得物件導向一點 或者整理一下就好了 01/21 20:38
74F：→ justben: 參數可以的話 多丟幾個框架 再過去 別人比較好查 01/21 20:41
75F：推 cutem: 在下不覺得這二者有衝突。 01/21 22:17
76F：推 chuegou: 以維護組語的經驗 效能取向就算註解 自己還是重看很久 01/21 22:47
77F：→ chuegou: 所以乖乖的走維護取向 01/21 22:47
78F：推 Sunal: 用2你要如何證明沒有bug 01/21 23:19
79F：→ PUTOUCHANG: 看薪水工時比, 時間少交差就好, 還做啥狗屁文件 01/22 01:38
80F：推 cobrasgo: 看有沒有類似compile flag的東西隔開，不然開個branch 01/29 08:22
81F：推 leveger0903: 有些公司不太接受程式重構 但如果有機會重構 我覺得 02/02 13:23
82F：→ leveger0903: 機會難得 有點羨慕 02/02 13:23