回看板
Disp BBS
看板 Soft_Job
作者 stu87616 (文組工程師)
標題 [討論] 效能與易維護性的取捨?
時間 Sat Jan 20 22:24:29 2018

各位先進好，

小弟現在手上的專案迎來了一次架構優化的機會，正好由我負責

為了達成某個特定的小需求，我發現下到底層去客製一些接口就可以完美做到，

由於本來份內的工作就完成得很快，我就利用多餘時間如火如荼地進行實作。


雖然花了不少時間，但該作法確實是可行的，

於是我在基本架構實現到八成左右後與團隊討論是否能夠整進專案內，

這時成員就提出了質疑

1. 原先目的的那個小需求，不客製接口，只用原生的，

   再加上一些額外的流程一樣做得到，只大概會損失 10% ~ 20% 的效能，

   而且這個效能長期來說可以忽略，沒有必要多花這麼多時間串接；

2. 這個客製流程我就算有信心改到沒 bug 真的可以用，

   我走了的話，以後的人會很難維護


第一點我不介意多花時間來做這個流程，畢竟都做得差不多了，也很有成就感

第二點就無法反駁了，我完全沒有信心能夠把這套流程完美交接給別人


這個問題讓我陷入了困惑，在以前做一人專案的時候，

我可以毫不顧忌的追求效能，偶爾也會寫得很髒

但是要考慮到易維護性的話，很多東西就要變的綁手綁腳了


想請問，像這樣的抉擇，通常都是怎麼選呢

--
[圖]

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 101.8.147.212
※ 文章代碼(AID): #1QOr4Yx1 (Soft_Job)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1516458274.A.EC1.html
※ 同主題文章:
[討論] 效能與易維護性的取捨?
01-20 22:24 stu87616
Re: [討論] 效能與易維護性的取捨?
01-21 09:48 Ommm5566
→ angusyu: 留下文件不就好了嗎？都做完了還在那邊唧唧歪歪1F 01/20 22:32
→ testPtt: 看要不要改2F 01/20 22:33
推 maxqq: 無論如何文件都要寫得乾淨
第二個我想你提的方案可以在未來效能擴充時的參考方案
留下註解與方法即可
容易維護，有時真的必須放第一考量3F 01/20 22:38
推 SHANGOYANYI: 你客製化新的接口 舊的還在吧？ 新的別人不會用叫他們繼續用舊的啊...7F 01/20 22:42
因為專案最後勢必是選一個做，
成員當然就會覺得如果我打從一開始就用簡單作法，就沒有轉移成本了
當下我都有衝動說那我兩個都做算了(還好沒說
※ 編輯: stu87616 (101.8.147.212), 01/20/2018 22:50:12
推 CGS0: 留下文件 想一下怎麼教別人9F 01/20 23:20
→ netburst: 管以後幹嘛 你只要管你接下來自己開發上好不好寫
離職以後都不甘你的事
多改了會加薪嗎  出BUG也是你死10F 01/20 23:55
→ vi000246: 重構很髒的程式碼 達成效能跟維護兼顧
不過我會選1 反正上面不在意就好 幹嘛多花時間做13F 01/21 00:50
推 t64141: 在效能沒大問題前提下，我會以程式碼的乾淨優先
畢竟維護的是人，為了一點點效能犧牲維護性長期來說不一定是好事15F 01/21 00:54
推 CCben: 只聽leader的話就好，問它想要什麼。不要管你隊員講什麼可維護性，因為說不定你現在接手的爛程式碼就是來自要求須有可維護程式碼的豬隊員^^18F 01/21 01:23
噓 darkMood: 當然是易維護性啊，反正又不追求效能，別拖累別人啊21F 01/21 01:29
→ y3k: 追求效能是機器運作效能還是人的作業效能?
前者還OK 後者我就認為糟糕
有些程式碼根本是外行人寫出來 只是可以動而已 這種當然要修阿 除非只是一個已經快死的專案...
阿 我第一句可能造成誤會 說的是"現在"的作業效能XD22F 01/21 01:34
推 strlen: 效能成本可以承擔的情況下當然選擇易維護性
文件和註解可以寫 但最好不要將之視為主軸27F 01/21 01:59
推 abccbaandy: 沒有效能需求當然選易維護阿...不過好奇20%效能差異是什麼架構阿，有點猛29F 01/21 02:19
→ joyce66789: 有沒有bug是你走後別人說的，不是你說的算。後人沒有31F 01/21 02:23
推 RunRun5566: 少寫文件ㄅㄅ32F 01/21 06:07
推 del680202: 像原PO這行為 在我公司稱作工程師的暴走
自high 請在不影響他人為前提33F 01/21 08:08
推 shiauji: 易維護 框架再好爛掉沒人維護也沒用35F 01/21 08:18
→ pttworld: 原本需求用量的評估。不常用的維護性優先36F 01/21 08:53
推 stephen23032: 效能瓶頸不在這裡的話上我會選擇好用的，不是技術展示。37F 01/21 10:07
推 mozume: 先寫好維護的,有效能需求再調,在公司內寫可能會轉手多人的程式時要先預定自己和接手是笨蛋的概念,文件不可信
推薦閱讀之前討論「如何沉住氣讀別人的 code」系列39F 01/21 10:07
→ alan3100: 改底層又不能交接給別人 這就是地雷42F 01/21 11:16
推 yyc1217: 我會以如何讓他人輕易上手維護為第一 如果效率只差一點點的話
畢竟系統會一直改 不可能就這樣永遠不變
甚至是為了三個月後的自己著想43F 01/21 11:24
→ ChoDino: 如果那接口是整個系統的瓶頸，你改寫他才有意義。47F 01/21 11:38
推 shortoneal: 其實你一開始合的時候找人幫忙review就好
優化根可維護很少是完全衝突的，大部分都是懶的藉口48F 01/21 11:39
→ ChoDino: 不然就是造成維護上的困擾。如果資源都用不完卻花時間在這，是不明智的事。50F 01/21 11:41
→ shortoneal: 今天如果你拿這種戰績去外面面試嘴砲，大部分會是扣分而不是加分52F 01/21 11:41
推 james732: 想知道這10%的提昇會有什麼好處？
更實際的說，可以讓公司省錢稅賺錢嗎
省錢或賺錢54F 01/21 11:48
推 clamperni: 如果是架構的話人腦效率比較重要57F 01/21 11:58
推 WiseLin1125: 哪那麼複雜，問leader就好58F 01/21 12:14
推 olen0622: 你不必想這麼多 這種專案都是能交件能丟給碼農維護優先不用特地想說我能把這東西做多好 風險人家無法承擔
事實是你能優化搞不好大家也行阿 但有其他考量且沒必要59F 01/21 12:22
推 Argos: 這不是廢話？沒人在乎效能差距當然是易維護性為最高考量
極度不專業的人才會在不要求效能的狀況下為了效能搞爛code就算是要求效能 那也要把影響效能最大的核心割出來
其它部份還是以易維護性為最高考量 基本中的基本中的基本62F 01/21 13:38
→ saladim: 好奇新改的介面是有多難懂跟多複雜?66F 01/21 14:47
推 za755188: 大家都發明新的路 最後程式無法維護67F 01/21 15:14
推 abc0922001: 當然是效能差又難維護，後面有事做+只有你能做（X68F 01/21 16:11
→ atpx: 以管理面來說, 效能不是主要考量的情況還是以維護性為主69F 01/21 16:28
→ iceonly: 挖，這10%是怎麼算的70F 01/21 18:40
→ MOONY135: 只有自己才看的懂的...半年之後應該就會靠北自己了吧71F 01/21 19:09
推 justben: 鍵盤工程師猜:底層那段應該只有你知道吧 建議就是
把底層那段接口 寫得物件導向一點 或者整理一下就好了
參數可以的話 多丟幾個框架 再過去 別人比較好查72F 01/21 20:38
推 cutem: 在下不覺得這二者有衝突。75F 01/21 22:17
推 chuegou: 以維護組語的經驗 效能取向就算註解 自己還是重看很久
所以乖乖的走維護取向76F 01/21 22:47
推 Sunal: 用2你要如何證明沒有bug78F 01/21 23:19
→ PUTOUCHANG: 看薪水工時比, 時間少交差就好, 還做啥狗屁文件79F 01/22 01:38

--
作者 stu87616 的最新發文:
點此顯示更多發文記錄