Re: [閒聊] 寫code不加註解真的很顧人怨嗎

[k12s35h813g (old cat)]

※ 引述《SkankHunt42 (凱子爸)》之銘言：
: ※ 引述《ianlin1216 (伊恩可可)》之銘言：
: : 餓死抬頭
: : https://i.imgur.com/3QcIsVN.jpeg
: : 本魯不是資工系的啦
: : 所以不知道寫程式不加註解會有多嚴重
: : 想請問相關從業的鄉民
: : 實務上遇到這種情況真的很賭爛嗎
: : 乾五西恰
: 大家好 我月薪28k軟體工程師啦
: 我的觀察齁 程式設計師有好幾種類型
: 1. 無口型
: 做了很奇怪的事也不註解，commit也找不到原因
: 等到哪個有重構強迫症的改壞程式以後才發現原來看似很奇
: 怪很醜的寫法才是最佳解 但因為沒註解所以大家還是繞了一圈
: 無口型有高手也有智障
: 2. 廢話型
: if(IsMatched()) {
:   // IsMatched 回傳true時會進來
:   doSomething();
: }
: 典型的話癆，可能以為自己在寫教科書
: 3. 宅宅型
: if(!Initialized()) {
:   assert(false && "you shall not pass!!!!!");
: }
: 喜歡在註解裡面埋梗，不懂梗的同事會很痛苦
: 4. 版本控制是什麼型
: // 2024/12/25 by SkankHunt42
: 不知道版本控制為何物，在註解特地註明自己改了這段程式碼
: 5. 上班不知道在想什麼型
: // ( )( )
: 可能在想LISP
: 6. 連環形
: // 把這則comment複製到另外3個檔案，7天後之後，你就會升職加薪。
: // 如果不複製，績效就會被打C
: 7. 影片說明型
: // The video in this link explains this piece of code.
: // https://www.youtube.com/watch?v=dQw4w9WgXcQ

真的有這麼奇葩的註解嗎
上 code 前不是都會做 code review 嗎
現在很多工具除了會做 style check，commit message 之外，
甚至有些工具會檢查註解是否符合格式吧
這種亂上 code 真的不會被幹到起飛嗎
把自己名字打上去也太好笑，直接讓人抓出是誰寫出這坨糞是吧
雖然 git blame 一下，也是會被抓到就是

我們在上 code 到 server 還要自動驗證是否可以編譯過，是否通過冒煙測試
還要經過資深同事 code review 過，都沒有問題才能上 code 到 server

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 111.240.74.137 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/C_Chat/M.1735138512.A.F86.html
推 fman: 有餘力做code review的公司不多，畢竟每個人手上的事情都一
→ fman: 沒有人會想再去幫別人看code，就自己的code自己負責，很多系
→ fman: 統爆炸也是這個原因 XD
推 NDark: 因為工具越來越強 整體軟體業都朝向人力精簡配置方向
推 jeff666: 就沒人專門負責統合 上司有空看就看 沒空可以work就好
→ NDark: 這樣的團隊(尤其是新創)會更不在乎團隊合作
→ NDark: 帕魯的伺服器就號稱一個人搞定
確實，之前在新創公司待過，遇過有同事把dram 相關的設定關掉，讓整個硬體部門陪他
解一個禮拜的bug 。我就知道code review 多重要了
※ 編輯: k12s35h813g (101.10.4.54 臺灣), 12/25/2024 23:01:05
推 Richun: 有些公司的code只要能動就好，什麼工具都當不存在，review
→ NDark: 一個人是要做甚麼code review
→ NDark: 註解是不是用英文寫的commit message是不是只寫fix都可能
推 DivineSX: 小軟體公司很多步驟都是一個人幹，驗證測試時間也不一
→ DivineSX: 定完善，所以有錯誤挺正常的
→ Richun: 更是找不到有空的前輩看，所以薪水越爛的鬼故事越多。
→ NDark: 銀行/支付/自駕這種就是另一種文化畢竟金錢上下生死攸關
推 arrenwu: commit message: hot fix  <--- 這種嗎XD
這種我覺得還好，有些bug 真的很微小的，我們有的時候也會上 Fix typo 的訊息
※ 編輯: k12s35h813g (101.10.4.54 臺灣), 12/25/2024 23:04:04
→ NDark: 我自己的side project還蠻常這樣的畢竟沒人會看啊
推 Sopure13: 老公司也會啊 以前不review沒事就一直不會改
推 v86861062: 真好qq
→ TSMCfabXX: 不會 你要先說服老闆花錢多請一個人來互相review
→ TSMCfabXX: 然後你老闆還要再跟上面的老闆說服
→ TSMCfabXX: 說我們單位每年花百萬請工程師的工作 output
→ TSMCfabXX: 有一部分時間花在做 code review
→ TSMCfabXX: 然後大老闆就會說 這個工作沒有必要 不用做
→ TSMCfabXX: 然後部門文化就定型了
我遇到的狀況是，開發是你的責任，幫同事code review 也是你的責任，自己想辦法在時
程內完成QQ
推 strlen: 一堆公司都馬能動就好 這可是慘業
※ 編輯: k12s35h813g (101.10.4.54 臺灣), 12/25/2024 23:25:51
→ qwer338859: 案子很忙的時候REVIEW都馬隨便看看就好
→ lay10521: 忙得要死 review看個3分鐘意思一下
推 Galbygene: code review、code style 不少公司都沒在做吧
→ strlen: 做clean code比較像在為了未來的自己好維護
→ Mormory: 最怕人都離職了才爆炸的code，一直講要review又不給人，
→ Mormory: 是要叫誰去review啦
推 rewisyoung: 通常做新專案客戶有要求就會統一做code style 的整合
→ rewisyoung:  然後現在文件也直接用vscode插件直接gen出來
推 h0103661: 對，良好的編程習慣是對自己好，否則會有惡性循環，之
→ h0103661: 前寫太爛導致後面難以維護所以寫更爛
推 dongdong0405: 更多的是ZIP檔版控的公司…
推 tacodrem: 當leader就是那個亂搞的人，一切都不再會是問題了~
推 judge54532: 有啊 有驗證跟review才能上code,不過從頭到尾所有事
→ judge54532: 情都是同一個人在做
推 L90156: 2不是廢話，是最有價值的資訊。當你實務上遇到改來改去的
→ L90156: 變化，非A也非B的情況下又要滿足另一種"情境"，就懂了。
→ L90156: 複合型情境超過10種以上，可見複雜度高的實務需求。
推 Rdex08: 一個人搞定...那他辭職不就直接爆開
推 educk512: 說不定現在可以直接丟給AI寫註解
推 XXXaBg: 現在有AI就還好了 比較麻煩的是多個檔案的那種
推 WuZun: 沒好處賺沒人喜歡CR 檔人快速拉屎deliver升級加薪跑路
→ hotrain13: 不是每間公司都有那麼多人力做review啦
推 jazon: 你公司是已經很大的了 多的是根本不review 所以容易踩坑
推 Haruna1998: review和style都是project to project的
推 entaroadun: 園區科技大廠一樣是會動就好，事情沒有那麼理想
推 wei115: review的覺得很好笑就會放過去惹