Re: [請益] 寫註解到底是不是好習慣

看板Soft_Job (軟體人)作者 (zrae)時間7年前 (2018/12/29 11:42), 7年前編輯推噓3(306)
留言9則, 6人參與, 8年前最新討論串9/24 (看更多)
這問題的背後是沒有答案 但我們可以根據目前世界一流的repo 來參考 絕大部分的世界級的framework 包含 linux 專案裡面都一定會有註解 只是註解多 或 註解少 其中讓我最喜歡的 專案大概是 laravel 連註解都寫得很藝術 我自己是贊成部分寫註解 而且要寫清楚 當專案架構越來越大 開發的人越來越多 尤其是 -> 功能越加越多 上頭 隨便天馬行空就來一筆 OOXX 的需求 ( X的!當初為什麼不講,現在要怎麼弄 ) 不太可能沒有技術債的產生 有時候因為時程關係 / 前人留下的技術債 / 上頭的天馬行空的新需求 有些地方是牽一髮動全身 雖然明知道最好的辦法是 某feature全部打掉重練 但是 整個重寫至少2個禮拜 照現在的邏輯下去寫 2個小時 以先解決的目前的ticket目的的前提 會讓你陷入一個 就算名稱取再好 你也無法講述清楚的情況 所以這時候寫註解 可以省去後來維護的人 或 幾個月的自己 方便快速地進入狀況 這時候 我是贊同寫註解 非此情況下的註解 我會比較希望看到 整個全局的概述 而非 單個block的論述 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.160.154.46 ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1546054941.A.672.html ※ 編輯: keke0421 (1.160.154.46), 12/29/2018 11:42:34

12/29 12:32, 7年前 , 1F
我接手過某個專案,上面就寫過2018/02/13 OOO要求加
12/29 12:32, 1F

12/29 12:32, 7年前 , 2F
入這功能,//2018/05/04 XXX要求刪除該功能
12/29 12:32, 2F

12/29 12:33, 7年前 , 3F
我接手後AAA又跑來跟我說OOO要再把功能加回去,這時
12/29 12:33, 3F

12/29 12:33, 7年前 , 4F
後就只能找上面三個來打一架了
12/29 12:33, 4F

12/29 13:09, 7年前 , 5F
覺得都是經常會遇到的狀況 哈哈哈
12/29 13:09, 5F

12/29 13:25, 7年前 , 6F
其實上面講的東西應該是 commit log 該有的.
12/29 13:25, 6F

12/29 13:34, 7年前 , 7F
看新的issue 的時候 如果有註解會比較容易清楚狀況
12/29 13:34, 7F

12/29 21:30, 7年前 , 8F
12/29 21:30, 8F

01/01 23:23, 8年前 , 9F
推這篇
01/01 23:23, 9F
文章代碼(AID): #1S9kqTPo (Soft_Job)
討論串 (同標題文章)
文章代碼(AID): #1S9kqTPo (Soft_Job)