作者:
stu87616 (文組工程師)
2018-01-20 22:24:29各位先進好，
小弟現在手上的專案迎來了一次架構優化的機會，正好由我負責
為了達成某個特定的小需求，我發現下到底層去客製一些接口就可以完美做到，
由於本來份內的工作就完成得很快，我就利用多餘時間如火如荼地進行實作。
雖然花了不少時間，但該作法確實是可行的，
於是我在基本架構實現到八成左右後與團隊討論是否能夠整進專案內，
這時成員就提出了質疑
1. 原先目的的那個小需求，不客製接口，只用原生的，
再加上一些額外的流程一樣做得到，只大概會損失 10% ~ 20% 的效能，
而且這個效能長期來說可以忽略，沒有必要多花這麼多時間串接；
2. 這個客製流程我就算有信心改到沒 bug 真的可以用，
我走了的話，以後的人會很難維護
第一點我不介意多花時間來做這個流程，畢竟都做得差不多了，也很有成就感
第二點就無法反駁了，我完全沒有信心能夠把這套流程完美交接給別人
這個問題讓我陷入了困惑，在以前做一人專案的時候，
我可以毫不顧忌的追求效能，偶爾也會寫得很髒
但是要考慮到易維護性的話，很多東西就要變的綁手綁腳了
想請問，像這樣的抉擇，通常都是怎麼選呢
有些公司不太接受程式重構 但如果有機會重構 我覺得機會難得 有點羨慕
作者:
angusyu (〒△〒)
2018-01-20 22:32:00留下文件不就好了嗎？都做完了還在那邊唧唧歪歪
作者:
testPtt (測試)
2018-01-20 22:33:00看要不要改
作者:
maxqq (max)
2018-01-20 22:38:00無論如何文件都要寫得乾淨第二個我想你提的方案可以在未來效能擴充時的參考方案留下註解與方法即可容易維護，有時真的必須放第一考量
你客製化新的接口 舊的還在吧？ 新的別人不會用叫他們繼續用舊的啊...
作者:
CGS0 (Mike Chen)
2018-01-20 23:20:00留下文件 想一下怎麼教別人
作者:
netburst (133 134 592)
2018-01-20 23:55:00管以後幹嘛 你只要管你接下來自己開發上好不好寫離職以後都不甘你的事多改了會加薪嗎 出BUG也是你死
重構很髒的程式碼 達成效能跟維護兼顧不過我會選1 反正上面不在意就好 幹嘛多花時間做
作者: t64141 (榕樹) 2018-01-21 00:54:00
在效能沒大問題前提下，我會以程式碼的乾淨優先畢竟維護的是人，為了一點點效能犧牲維護性長期來說不一定是好事
作者:
CCben (new man)
2018-01-21 01:23:00只聽leader的話就好，問它想要什麼。不要管你隊員講什麼可維護性，因為說不定你現在接手的爛程式碼就是來自要求須有可維護程式碼的豬隊員^^
作者:
y3k (激流を制するは静水)
2018-01-21 01:34:00追求效能是機器運作效能還是人的作業效能?前者還OK 後者我就認為糟糕有些程式碼根本是外行人寫出來 只是可以動而已 這種當然要修阿 除非只是一個已經快死的專案...阿 我第一句可能造成誤會 說的是"現在"的作業效能XD
作者:
strlen (strlen)
2018-01-21 01:59:00效能成本可以承擔的情況下當然選擇易維護性文件和註解可以寫 但最好不要將之視為主軸
沒有效能需求當然選易維護阿...不過好奇20%效能差異是什麼架構阿，有點猛
作者: joyce66789 (拉拉) 2018-01-21 02:23:00
有沒有bug是你走後別人說的，不是你說的算。後人沒有
像原PO這行為 在我公司稱作工程師的暴走自high 請在不影響他人為前提
作者:
shiauji (消極)
2018-01-21 08:18:00易維護 框架再好爛掉沒人維護也沒用
作者:
pttworld (批踢踢世界)
2018-01-21 08:53:00原本需求用量的評估。不常用的維護性優先
效能瓶頸不在這裡的話上我會選擇好用的，不是技術展示。
作者:
mozume (米蟲)
2018-01-21 10:07:00先寫好維護的,有效能需求再調,在公司內寫可能會轉手多人的程式時要先預定自己和接手是笨蛋的概念,文件不可信推薦閱讀之前討論「如何沉住氣讀別人的 code」系列
作者:
yyc1217 (somo)
2018-01-21 11:24:00我會以如何讓他人輕易上手維護為第一 如果效率只差一點點的話畢竟系統會一直改 不可能就這樣永遠不變甚至是為了三個月後的自己著想
作者:
ChoDino (Dino)
2018-01-21 11:38:00如果那接口是整個系統的瓶頸，你改寫他才有意義。
其實你一開始合的時候找人幫忙review就好優化根可維護很少是完全衝突的，大部分都是懶的藉口
作者:
ChoDino (Dino)
2018-01-21 11:41:00不然就是造成維護上的困擾。如果資源都用不完卻花時間在這，是不明智的事。
今天如果你拿這種戰績去外面面試嘴砲，大部分會是扣分而不是加分
想知道這10%的提昇會有什麼好處？更實際的說，可以讓公司省錢稅賺錢嗎省錢或賺錢
作者: WiseLin1125 (Wise) 2018-01-21 12:14:00
哪那麼複雜，問leader就好
你不必想這麼多 這種專案都是能交件能丟給碼農維護優先不用特地想說我能把這東西做多好 風險人家無法承擔事實是你能優化搞不好大家也行阿 但有其他考量且沒必要
作者:
Argos (Big doge is watching u)
2018-01-21 13:38:00這不是廢話？沒人在乎效能差距當然是易維護性為最高考量極度不專業的人才會在不要求效能的狀況下為了效能搞爛code就算是要求效能 那也要把影響效能最大的核心割出來其它部份還是以易維護性為最高考量 基本中的基本中的基本
作者:
saladim (殺拉頂)
2018-01-21 14:47:00好奇新改的介面是有多難懂跟多複雜?
作者: za755188 2018-01-21 15:14:00
大家都發明新的路 最後程式無法維護
作者:
atpx (秋雨的心情)
2018-01-21 16:28:00以管理面來說, 效能不是主要考量的情況還是以維護性為主
作者:
iceonly (只有冰)
2018-01-21 18:40:00挖，這10%是怎麼算的
只有自己才看的懂的...半年之後應該就會靠北自己了吧
作者:
justben (BEN)
2018-01-21 20:38:00鍵盤工程師猜:底層那段應該只有你知道吧 建議就是把底層那段接口 寫得物件導向一點 或者整理一下就好了參數可以的話 多丟幾個框架 再過去 別人比較好查
作者:
cutem (大少爺)
2018-01-21 22:17:00在下不覺得這二者有衝突。
作者:
chuegou (chuegou)
2018-01-21 22:47:00以維護組語的經驗 效能取向就算註解 自己還是重看很久所以乖乖的走維護取向
作者:
Sunal (SSSSSSSSSSSSSSSSSSSSSSS)
2018-01-21 23:19:00用2你要如何證明沒有bug
作者:
cobrasgo (人魚線變成鮪魚線，超帥)
2018-01-29 08:22:00看有沒有類似compile flag的東西隔開，不然開個branch