Re: [閒聊] Code Review 意見不合

[jackyu (孫權)]

小弟弟我覺得這篇思考的點和我不知道為何搭不太上
但是其實原原PO我覺得倒是問題不大
不過在面子勝過一切的華人圈, 你要了解一件事
就是code review change => 你輸給了這個reviewer => 頗多工程師的邏輯

※ 引述《yauhh (小y寶貝)》之銘言：
: ※ 引述《blabla123 (念不停 煩不煩？)》之銘言：
: : 公司規定提交的 code 至少要經過另外二個人code review才可合入，
: : 可能我比較死板，每次我一定先檢查變量名命名法則是否符合規範，
: : 還有代碼執行效率，打的 Log 有沒有在前面加上 DEBUG開關，然後才
: : 會開始檢查相關邏輯問題。有個同事常叫我幫他 code review，但是他
: : 常覺得這沒必要，那沒關係，代碼執行正確就好了。今天，小的終於
: : 忍不住了，和他說「我有我 review的標準，並且會努力提高這個標準
: : ，如果你覺得我 review的不重要，那別讓我 review就好了，我真的
: : 不在意(OS:你媽，幫你看代碼，花時間，到時出bug也是多少得負責，
: : 老子不如多做其它的事，還聽你抱怨)」對方也就同意了，有點像不歡
: : 而散的感覺。各位在 code review 的有發生過類似的事嗎？或者有其
: : 它 code review 過程中的趣事可供分享？
從原文看到很有可能變量命名是公司的規定
代碼執行效率我比較好奇, 因為演算法和設計/系統/介面接口有很大的不同
有O(n)的做法可是不得已作成O(n^2)也是有(特別是code很老和需求太雜)
我通常不會那麼佛去看這塊, 因為設計的review是架構師才有權力決定其對錯
自己review這個真的吃N倍的力又不討好

如果在多人合作的環境LOG開關是很重要的禮貌:
因為LOG太雜是很傷害debug的精力, 而且還要修過版本控制裡的內容我才能好好的做事
unit test是自己在上傳前就要搞定的事, 當然包括移除不必要的LOG
若是日後整合測試, 當然要留開關

: 我想你應該先判斷，自己的思維有沒有問題：
: 1. 你已經在記恨同事不幫你買帳，這種記恨變成下次有機會你就挑起爭端的
:    藉口。

這邊我實在看不出來他在記恨耶, 我看到的是原原po再強調他要求被拒絕的事
只是這個"要求"若是公司規範, 那這有甚麼好檢討的?
如果不是, 還是要看細節. 我只能說他是龜毛了些

: 2. 你的說詞如果照字面來看，是強調因你的身份為 reviewer 而給品質
:    帶來保障，而更甚於因你的 review 帶來品質的保障。
這邊實在看不出來, 原原po的ego有那麼高嗎?

他只有說"我一定按公司的標準, 再加上以品質為前提的標準"
"若是覺得我的標準太龜毛, 請找別人"
再依描述他們公司一個BUG的歸責似乎reviewer也會有或多或少的影響
既然和自己有關, 多要求一些有何相關?

: 3. 你的說詞如果照字面來看，同事可以不要找你 review 而是找別人幫他
:    review ，所以你根本不必對他警告什麼事嘛。
: 4. 你覺得 code review 是一種連帶要求別人按照你喜歡的方式寫程式
:    的手段嗎？
:     review, revision, bug, coding style 等等，這些詞彙彼此是有不同內涵。
: 我覺得你是錯的：
: 1. 記恨而會講出的那一番話，像是「我有我的原則，不要浪費我的時間」，
:    應該是上次發生爭端之後講的話，而不是下一次 review 之前你先樹立的
:    障礙。你的錯是在你把你自己的人格擋在同事之前，同事不經過你就不得
:    涉入工作，於是你的人格妨礙工作，妨礙公司的運作。
這論點有問題.
若是人格特質是有利該團隊運作的, 為何算是樹立障礙?
公事公辦我倒是不覺得有啥機掰之處
我的經驗妨礙團隊運作大多都是工程師莫名其妙的自尊心
有些人當reviewer挑人毛病很爽, 被review認為若是屈服就很不爽
擇善固執之後私下關係好的我真的沒看到幾個(華人..哀)
好來好去review就等於虛設了

: 2. 當你要強調你對現有的 code review 情況不滿的時候，應該客觀談那一件
:    事情，而不應該把你自己的人格帶進來擺在上位。
我覺得他的論述很客觀啊, 阿就被reviewer一直盧
當然這是片面說詞, 不過就這片面說詞而言, 看不出來
而且我覺得這應該是就事論事後還被爐才爆發的

: 3. 「管他去死」這樣的思維，在你的工作環境中，其實是代表你培養了可能
:    讓你不適任的因素了。
ㄟ, 不聽我的話BUG出來怪我囉? 當然管他去死啊
不適任在哪裡? 覺得我的review是屁然後真的出事了我還被以review的身分被high light

: 4. 人家可能只是說 review ，多看一眼，至於什寫法叫做問題，是要另外有
:    開放討論的。你光是叫人一定要改，假如不改，你就不接受，那其實，一
:    方面這不是開放討論，另一方面，由你指揮別人一定要改的那些東西，
:    如果有問題，應該是你要全權負責。
這個就是藏在細節裡的魔鬼了
很有可能review是他們公司dual programming的一環(我猜)
因為到時候bug tracking可能只記錄誰review,
但是review process沒有(有哪家公司會龜毛到這種地步嗎?XD)
這時候被反咬不就很悶?

給blabla原po,
我很高興在台灣這種職場文化還有這種個性, 沒被磨掉
但是要記得, 若是你沒有100分的實力
別人只會記得你有"60分的龜毛", 並且質疑你對團隊的傷害和產出不成正比
我建議你以後在review用"建議"就好, 然後真的管他去死
並且增強實力, 然後默默的紀錄不聽你建議真的造成bug的事項
久了一攤開, credit有了講話也大聲

另外, 要旁敲側擊知道不接受是因為不想做還是不爽做
不想做是時間問題, 不爽做是面子問題
這兩點處理的手腕很不一樣

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 124.8.77.163
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1424116498.A.8AE.html
→ yauhh: 我能回答的是，我所寫的只是寫出整體理解之下的一些概念，
→ yauhh: 分細項描述只是想要把細節鋪陳舉例。但是以你逐項反擊的
→ yauhh: 方式來說，我看是劃錯重點。書面的東西畢竟與整體概念有差
→ yauhh: ，若你真的細細地分析，有一些東西就會從你自己的理解/誤解
→ yauhh: 更加延伸出去，而之後所談到的東西，對之前原先在想的，會
→ yauhh: 有所失真。我不覺得有什麼好浪費時間計較我所評論的究竟
→ yauhh: 多麼對或錯，畢竟是原po自己先邀請大家提供意見，所以我才
→ yauhh: 給予意見而已。
推 blabla123: 謝謝回覆，其實我不在臺灣工作　Orz。我壹般會
→ blabla123: code review 會加上個問號（？）因為是建議的心態
→ blabla123: （壹方面對對方業務不了解）此外
→ blabla123: ，大家都可以看到妳的 comment，如果妳 review 不合理
→ blabla123: ，架構師應該會出來說句話的。
→ blabla123: THANKS!!
推 blabla123: 謝謝您的建議，我會學習的！