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