爬了一下版規，如果有觸犯到，再刪文 謝謝
幫朋友代PO
最近接手公司的新專案，結果發現該專案
幾乎完全沒註解，可能一個檔案裡面
註解不超過10個字，也沒手冊
雖然變數名稱那些都是用"有意義的英文"命名
大致上能猜得出"可能是跟什麼有關"
例如薪資單可能是A檔案，但A檔案中又一堆function
目前只能從MVC開始慢慢追，想請問版上的前輩們
如果遇到這種專案維護，有什麼技巧可以快速入手的
問公司的前輩，意思是摸索久了，自然就會記得了
感謝

需要的時候再改，不需要勉強自己全部吸收

個人認為寫code最好能做到"程式本身即註解"除非某處需要註解當時的spec或不合常規的需求，我才會註解幾年下來，年輕一輩的還是認為我的程式讀起來沒什麼問題一點點分享:)

從資料流去看吧，按下什麼button，會到哪個function摸透了寫成文件偷偷藏著（X

程式碼不就是最好的註解了...

資料流+1 從入口到終點整個看過至少知道流程

Clean code的概念啊，不過怕是Clean code的不註解概念下寫的Code卻不Clean

一堆人以為自己code很好讀 然後說不用註解= =寫的清楚加好的註解就是事半功倍啊不然每個人認為的好讀根本天差地遠

我是先找入口點，然後找尾端(存取資料庫)，接著看中間有沒有粗略歸納出幾層如果有稍微分層或是分模組，那大概的雛型就有了，接著再慢慢根據功能點去追細節

從主要button點下去開始追資料流了...

X! 程式碼就是最好的註解無誤 聽前人說明還不如我自己看然後還從無註解的舊架構翻成新架構 練功MAX

有沒有看過註解錯的程式 這樣我倒不如不要註解

如果是C#有做summary維護效率差很多

你要的是一整個架構的spec吧? 我發現其實這種東西不多而且因為長年修修改改 也未必準確...從流程下去追 問前輩"為什麼這樣處理" 反而比較快

半調子而且還跟code不同步的註解才是恐怖

程式碼要當註解，也要參數跟方法有好好寫啊曾經遇過接手的老專案，class叫a01跟b01這樣的

先問用途 從上往下看快太多

這個只能認命追了

邏輯流

有用框架會比較好追，像react、mvp，沒有就要看他命名了

二樓根本答非所問....只想說自己的事情

靠ide去追code了

少在那邊 99%的程式都爛到無法自我表達好唄 乖乖寫你的註解

寫註解不是很基本的概念嗎?為什麼一堆人不寫

clean code的概念是有些人寫了註解就懶得重構重構+適度的註解才比較好讀懂

事實是 拿我寫clean code藉口說看程式就好不用寫註解 註解只會過時的 通常code一點也不clean連註解都不肯好好維護 哪有心寫clean code？而且clean code也沒全反對註解 該解釋的就好好解釋清楚齁

看個案吧~ 不過目前能run得好好的東西就盡量別去動

沒註解好過註解騙你

註解騙人的真的很慘

有意義的命名跟注解沒啥兩樣，如果你不懂為何要這樣做，一樣都看不懂

多半都是自以為易讀實際是爛code那種懶、隨便的心態寫出來的東西 最後都很多藉口

因為有些人覺得寫註解很low

你不知道以後程式都給AI寫嗎?註解只是用來幫助記憶或給不懂的人看的

易讀? 哪考慮那麼多 案子先處理掉 接下來就是下個人的問題了

所以說懶就承認 把「會被註解騙」拿來當藉口的 寫不出什麼clean code的啦 賣鬧阿

當一支報表數十個欄位，我寧願用數字排列加上對應清單還比較好

啥邏輯劉?沒看過有人寫個FUNCTION全部擠一起3000行?

公司前輩的code都沒註解，但我一目了然

原來不寫註解是因為懶0.0

在職時滿註解，離職後clean code。這樣有了解嗎~~呵

先搞懂那系統是幹麻用的 怎麼用 再來追吧