對於相當一部分公司，都有自己帶程式碼review系統，在這樣的系統上，程式設計師可以檢視同事釋出的程式碼，可以學習他人的優秀的程式設計思想，如果發現他人的程式碼有不足的地方，或者有一些bug，可以在相應的地方進行標記評論，這樣的平臺算是很不錯了，可以促進同事們之間相互學習，相互促進改正問題，從某種程度上來說，可以避免掉一些錯誤的發生，然而，近期，一名程式設計師網友吐槽他遭遇了一個奇葩的事情。 據這名程式設計師網友說，最近他的工作不算太忙，有空了他就在平臺上看看其他人的程式碼，學習一下其他人的思想，如果發現問題了，就順便提個評論幫助對方改進，上次提了幾個comments(評論）然後發現被人默默從PR裡面移除了，他也沒有多想，今天他又在程式碼裡提了一個評論上去了，結果，剛提交上去，那人隔著幾個座位直接對他說不要加了，程式碼馬上要提交了。於是這名程式設計師網友覺得這人有點奇葩，這名程式設計師網友說：“其他人都挺好。審查程式碼是互相學習，不是挺好的嗎？我很感謝給我提建議的人。”，針對這名程式設計師網友遇到這樣的事情及他個人的觀點，讓我們一起看看其他網友們都是怎麼認為的吧！

上世是朵花：這名網友說的可以體會，凡事也不能聽一面之詞，按裡說給人提建議應該是受歡迎的，畢竟對對方有幫助，如果在具體操作層面做得有問題可能也不會受歡迎。

美團員工：你這個同事心態有問題

上世是朵花：如果提出的建議確實是有價值的，一味拒絕就說明是心態問題。

網友三：給建議是活雷鋒啊，

上世是朵花：沒錯，正常情況下是這樣，如果具體操作層面沒啥問題的話。

網友四：我更希望提好的建議，如果僅僅是觀念不同而不是對不正確的糾正或更優解那感覺不太好

上世是朵花：同感，這名網友的80%的觀點我是非常同意的！ 網友五：稽核程式碼挺好的機會互相學習

上世是朵花：嗯，沒錯，這種機制是很好的，前提是需要有人主導一個規則，別讓小夥伴們給玩壞，玩的變味了就糟糕了。

網友六：要是老是找茬說我大括號不要另起一行，我也不加你

上世是朵花：呵呵，有道理，所以我說要看具體操作層面嘛。

網友七：你們遇到過測試審查開發的程式碼嗎？不是領導要求的，只是測試測得時候，看著程式碼測

上世是朵花：那說明這名測試同學是開發出身呀，這種測試方法並不是很建議，容易陷入程式碼邏輯，無法梳理整體思路。

網友八：除非發現錯誤，不然不要提意見。風格規範之類的問題應該由編碼規格檢查器來搞定，人沒法對軟體發火不是。

上世是朵花：沒錯，在這件事情上，大家的觀點還是比較類似。 針對這樣一個事情，看了之後，給人的感覺是他的同事不對，人家好心提建議為啥要拒絕呢？不過仔細想想，拋開具體的操作層面的事情來判斷誰對誰錯，也未免有點果斷了，這要看具體提的是什麼問題了，有時提的問題讓對方感覺沒有任何價值，甚至說還不如原來的那樣，那就會讓對方感覺是在浪費人家的時間，不是在幫忙，而是在幫倒忙，所以，我們評論程式碼也要慎重，說出去的話，就是潑出去的水，無法收回的，如果提一個好的評論，讓人看了之後眼睛一亮，感覺十分有價值，我想對方會是十分敬佩你的，如果提一些不屑的問題，反而會增加對方的反感，不是麼？具體這個度怎麼把握與權衡就需要按實際情況去自己琢磨與領悟了，因此，針對這樣的案例，我不會拋開具體事實而去評論誰對還是誰錯，這樣是不科學的，建議這名樓主網友可以仔細分析一下自己的問題和具體環境氛圍等因素，想必一定能從中得出一個答案！

以上所有圖片均來之網際網路

大家好，我是“上世是朵花”。如果你有什麼好的看法或者觀點可以在評論區展現你的才華，互動交流，如果想進一步瞭解我，那就關注我吧！