Re: [請益] 沒註解的專案該如何維護

看板Soft_Job (軟體人)作者mysteriousGE ( )時間8年前 (2017/07/23 00:05)推噓8(8推 0噓 8→)

留言16則, 10人參與討論串2/2 (看更多)

※ 引述《mickeyboy (mickey)》之銘言： : 爬了一下版規，如果有觸犯到，再刪文謝謝 : 幫朋友代PO : 最近接手公司的新專案，結果發現該專案 : 幾乎完全沒註解，可能一個檔案裡面 : 註解不超過10個字，也沒手冊 : 雖然變數名稱那些都是用"有意義的英文"命名 : 大致上能猜得出"可能是跟什麼有關" : 例如薪資單可能是A檔案，但A檔案中又一堆function : 目前只能從MVC開始慢慢追，想請問版上的前輩們 : 如果遇到這種專案維護，有什麼技巧可以快速入手的 : 問公司的前輩，意思是摸索久了，自然就會記得了 : 感謝「沒註解的專案該如何維護」但其實如同推文中很多板友說的沒註解不代表程式寫得不好最高境界的 clean code 是無註解的題外話：「好程式 -> 不寫註解」並不等價於「不寫註解 -> 好程式」程式寫的爛還是乖乖寫註解比較實在...XD 我先假設你要問的其實是「很難閱讀的專案該如何維護」我建議的藥方是 Unit Test ￣￣￣￣￣套上 Unit Test 有兩層意義： 1. 確認每個工作單元的行為是否和你猜想的相同也可作為後續維護程式的「規格文件」 2. 作為重構的保護網，確認重構後行為沒有改變實務上的步驟的大概是： 1. 建立可以方便撰寫、執行 Unit Test的環境這得仰賴 IDE 是否有相關的框架、套件可以支援例如 Visual Studio 內建的 MSTest 2. 小部份重構（還沒有加 Unit Test 保護，切勿大規模重構）接下來或多或少會面臨 Unit Test 根本就包不上去的情況因為程式撰寫時根本就沒有考慮過可測試性、耦合的程度太過嚴重所以比須先使用一些技巧提高程式的可測性（例如依賴注入之類的） 3. 包上 Unit Test，確認工作單元的行為 4. 重構。讓程式碼更好閱讀、具有更高的可測性、可維護性真的重構不出夠漂亮的程式碼，就乖乖加上註解吧～ Unit Test 是一門博大精深的學問如何寫出好的test case、測試的工作單元該如何切割、各種情況如何驗證、...等都是不小的學問，這邊我就不多作贅述了～ Google 「91 TDD」會有很多很棒的文章 :p 以上，獻醜了 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.169.90.185 ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1500739518.A.27B.html

→

james732

07/23 00:31, , 1^F

07/23 00:31, 1^F

→

dnabossking

07/23 01:13, , 2^F

07/23 01:13, 2^F

推

dnabossking

07/23 01:16, , 3^F

07/23 01:16, 3^F