PTT職涯區 / Soft_Job (軟體人)

[討論] 效能與易維護性的取捨?

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