Re: [討論] 前人的code 後人翻寫的機率高嗎?

[banqhsia (BEN)]

※ 引述《peanut97 (丁守中)》之銘言：
: 大家中秋節快樂，快收心了。
: 想問一個假設性問題，大家在工作上，如果有一份專案的 code 是某位前人一手寫的
: 後來新人加入，變成前人帶新人，此時繼續維護那份code。
: 但再過一陣子，前人離職了，唯一的創始者走了。
: 新人把舊 code 重構，或是砍掉重鍊的機率高嗎？

        先跟主管、老闆提，確認有人支持你，不然你會被當成怪物

        「為什麼要改？」
        「系統好好的幹麻改？」
        「改了有好處嗎？」
        「會花多久時間？」
        「時間剩不多，要動不動隨便你，不要影響到時程」


: 我的想像是，如果一份code是出自於1個人之手
: 我的想像是，如果一份code是出自於1個人之手
: 那麼code就是他的世界觀、他的切入點
: 那麼code就是他的世界觀、他的切入點
: 後面的人看著他的世界觀，有時候不一定能全部接受
: 而有人的地方就有政治
: 當他還在的時候，當然就不會亂動。
: 而當他走了的時候，後面的人，一看不爽，就可能改寫成自己看得爽的、
: 好改的code。
: 如果是一個團隊，那當然要好好討論為什麼要改
: 哪些因素造成現在不好的情況，以及主管同不同意改等等的。
: 只是我很好奇，1,2人的專案，改的機率高嗎？
: 是不是，code只能是「現在還存在公司的人」能控制的才行。


我們公司的經驗，以前因為很多原因 (十幾年前的 code)

導致系統沒有測試、沒有嚴謹的 coding style、方法註解也很少

copy paste 是基本，沒有遵照 SOLID

錯誤不是丟 null 就是 false (欸! 我的 Exception 呢？


每個 team 成員想怎麼寫就怎麼寫，不管後續的漣漪

反正東西交出來就好 多棒



然後中間當然成員就是來來去去的

我看這之中大概也是 有人進來 -> 看 code -> what the fuck？ -> 離職

大概就是這種循環



因為自己痛過，知道 clean code、設計模式 的重要性

進公司沒多久就跟主管說這 code 不能搞，一定要重構



每個工程師一定看不爽前人的 code XD

但是不是說說而已，總是要提出改善的方法

理所當然地，你前面那些問題我都被問過

幸好我的主管與老闆也是支持我這件事情

但是我們討論的結果，現在的 code 也沒辦法全部翻掉，怎麼辦



在那個時候剛好要把原本的系統生出一套 API

原本的系統是 server-side template render，模板與資料、樣式高耦合

這個沒辦法改成 API



我們的作法是，把原本 DAO 抽出來，放進框架裡當成 library

然後加一層 Adaptor 讓新系統相容舊模組


舊的 DAO 邏輯怎樣就不去動他，要改一律在 Adapter 裡面改
(就算 method rename 也是)


在這個新系統，以 SOLID 與設計模式為基楚

controller 與邏輯之間，包裝成 service 呼叫 (一律把該寫的東西放在該去的地方)

service 只准有抽象的敘述，實作的部分寫成介面去依賴，由子類別注入 service

使用 DI Container 自動注入依賴的類別，不准直接 new (方便替換測試)

提交功能分支以前，要一併提交單元測試與 functional test，否則不准進 develop



這些都是規定好寫在專案文件裡面的 (以前沒有的文件，現在開始留下記錄)





接著就是重頭戲的部分 --- 跟人有關的


coding style 怎麼統一？ 就算統一了還是會有漏網之魚

不小心看到 violation 還是會白眼翻到尾椎



所以這邊必須用自動化工具檢查，綁在 CI 流程裡

這樣已經可以省掉很多人工的部分


接著定期 code review，挑出變數不懂、「比較不易修改」的類別… 等等


這樣至少做到了幾件事情

1. 以前沒有的，現在開始留下記錄
2. 把 legacy code 加上 test
3. 把系統改成 API server 從視圖抽離後，再動前端 (refactor 分階段)
4. 統一 coding style
5. 符合 SOLID、易於修改的架構 (為了以後著想)




當然前面幾篇貼文，有些前輩也有提到

「有人的地方就有政治」


這句話應該劃 _底線_ 三顆星 ★★★

這之中太多阻礙了，電腦不會背叛你，人會 XDD



做了這麼多品質保證措施，一定會遇到成員反對

「一個變數而已，幹麻花這麼久時間討論？」

「我覺得 code review 花太多時間」

「我覺得一個東西，幹麻拆這麼多類別，放在一個不就好？」




深入探討提出這些問題的同事心態，不外乎幾個原因

1. 影響 issue solving 時間              --> 覺得產出變慢

2. 覺得寫單元測試很麻煩                 --> 覺得程式會動就好

3. 覺得一個類別不用提煉為抽象+實作      --> 現在又沒這麼多需求 幹麻拆？



但他們忘記事實是，程式本來就是會修修改改的，而且也是會給別人改的


這讓我想到一句話
        「
            據統計，你現在挖的坑，有80%會自己來擦屁股

                                                -- 不知道是誰  」





即便跟他們說品質是什麼，clean code 的重要性，他們還是覺得『不需要』

所以大多數的問題，都是「人」造成的



stop writing legacy code，從你我開始


但如果你身邊沒人支持，更進一步的說: 沒有得到老闆/主管支持

這公司也差不多 GG (因為不在意品質)




如果你是 team 的其中一個人，試著先從統一 coding style 開始





我在 Modern Web 2018 聽到有一場 keynote 是 Terry Yin 大神的「遺留代碼經濟學」

裡面有提到，其實也不用這麼討厭 legacy code

因為有那些東西，我們工程師才得以被養活。

如果你發現有 code 裡面處處是坑，怎麼辦？    那就別再挖坑了啊！！



我們現在做的，只是把以前沒做的都補回來而已

但是，不要再欠下更多的技術債

債總有一天還是要還的，而且還會生利息




最後我要說一句

很多前輩們會建議，要重構前先寫測試


但是

一個萬能類別/萬能方法/高耦合，要寫單元測試，發現整個系統都要寫

有些 hard code 的 class 還不見得可以 mock



「人」的問題


無解。







--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 123.241.170.131
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1537805551.A.271.html
推 kewang: 推！這場有去聽，很讚！                                  09/25 00:16
推 t64141: 精闢, 解法也很實用                                      09/25 00:17
推 yuanyu90221: 推                                                 09/25 00:22
推 ppppman: 推 code review和coding style真的很重要 但人多意見多    09/25 00:23
推 fanatics5566: 精闢，推個                                        09/25 00:23
→ ppppman: 真的都是人的毛～ 但執行良好的話後面維護會輕鬆很多      09/25 00:24

   大多數的人不懂的品質的重要，只想著「我速度會不會會拖慢」

   但是請記住，是因為有穩定的品質才得以讓開發更快速

推 abccbaandy: 這篇基本上大部分人都卡在第一步吧XD                  09/25 00:48
推 Hevak: 推                                                       09/25 01:43
推 FukadaKyoko: 不錯~蠻流暢清楚的說明                              09/25 01:49
推 marmot00: 推MW2018那場演講，獲益良多                            09/25 02:00

   這場聽完讓我很印象深刻

→ angusyu: 所以你意思是說你提的才是對的，別人提的都只是懶惰       09/25 02:53

   不太懂您的意思？

   我可以理解求開發加速的心切，但是「欲速則不達」
   程式碼本來就會修改改，做這些事情只是讓修改更方便進行
   否則開發效率也會趨近於零，最後完全加不下去任何程式碼。

推 drajan: Clean code已經是proven best practice 想反對就拿出合理   09/25 03:34
→ drajan: 的理由來                                                09/25 03:34

   我很慶幸我站在巨人的肩膀上

   我可以接受反對的人不懂 clean code 的重要
   但是明明知道，卻一直說服自己「沒必要」「會拖慢進度」
   這樣的態度相信其他夥伴也無法接受

推 scottxxx666: 推                                                 09/25 04:33
推 scottxxx666: 推                                                 09/25 04:33
推 SmileJoS: 這篇文章所要表達的意義，就感覺跟MW2018那場很像，沒想  09/25 08:05
→ SmileJoS: 到是講者親自來回....                                  09/25 08:05

  不是我，內文已修正補上。 我是會眾 XDD

  「我在 Modern Wen 2018 聽到」

推 Sunal: 在此篇情境下不重構有更好解法？                           09/25 08:09
→ Sunal: 我是想不太到啦                                           09/25 08:10
推 sharku: 推                                                      09/25 08:20
推 Y78: 推                                                         09/25 08:31


→ banqhsia: 抱歉，用 PTT+ 真的很爛，讓我存檔的時候蓋掉所有人的
→ banqhsia: 推文，如果有蓋掉您的推文還請大家再推一次...
推 ian90911: 推 不過原po怎麼把留言區色碼都變白的
→ banqhsia: 因為我用編輯文章來回覆推文，但是 PTT+ 很容易回覆失
→ banqhsia: 敗，我怕文章不見，就先複製起來 backup，結果真的存檔
→ banqhsia: 失敗，全部不見。我就拿 backup 那一份來貼上，就變成
→ banqhsia: 空白了...
推 vegeman: 不過換個角度想 可能產品晚一天上線估計公司少賺100萬 老
→ vegeman: 闆可能也懶得管以後補坑要請多少人 現實跟理想的認知偏誤
→ tkucuh: 在兩個公司待過，coding style一開始都要求，後來為了趕進
→ tkucuh: 度也都放棄了...不知道現在有沒有好一點
        有兩件事情是不可以被妥協的

        1. clean code
        2. testing

        我知道很難 XDD

→ robber1234: 理想跟現實就是有一段距離,光是reivew跟unit test
→ robber1234: 就能多花多久時間.經驗上來說並沒有比較快,後來也沒省
→ robber1234: 到時間.很多小功能定太多界面還是寫unit真的很耗時的
→ robber1234: 如果你老闆你主管你CTO願意讓你慢慢搞那當然最好,但..
→ robber1234: 目前只有被一直要求趕上時程,從來沒被要求code clean
        在 clean code 這本書的前面幾個章節，有提到:

        程式碼最後失控，難道是 PM/PO/主管/客戶 的錯嗎？
        不，錯的是我們 RD，這都要怪我們「不夠專業」。

        看完 clean code 你就會明白，時間與產出是現實的問題，
        但我們的專業，不就是要讓程式碼變得更清楚明白 易於修改和穩定

        Unit test 能讓 component 表達他原來想要做的 intent
        而不會歷經改朝換代之後，已經不知道程式碼原本想要幹麻了。


        「測試又叫作不會說話的文件，靠人來傳承系統，注定會失敗」
                            -- Terry Yin, 遺留代碼經濟學, Modern Web 2018



推 bndan: 推這篇..前半文的做法 其實蠻多舊式的系統都蠻需要的 = =
※ 編輯: banqhsia (114.34.5.66), 09/25/2018 13:37:23
推 darkch: 推！clean code 真的重要
推 es8603: 講到心坎裡
推 booloo: 我們公司兩個技術主管桌上都放了本Clean Code，一開始專案
→ booloo: 的架構也都是照著Clean Code的思想在重構，但是三個月後進
→ booloo: 度嚴重落後，重構後的系統穩定性還更差，上層評估會影響
→ booloo: 收益......就取消重構專案了。
推 booloo: 很遺憾，重構所產生的收益沒辦法量化，但是後台的崩潰率可
→ booloo: 以量化，而且直接跟KPI掛鉤......