Re: [討論] 怎麼跟自以為是的同事相處

看板Soft_Job作者 (藍廳)時間1年前 (2022/10/26 11:50), 1年前編輯推噓25(25028)
留言53則, 31人參與, 1年前最新討論串3/10 (看更多)
提供一點不一樣的看法 ※ 引述《leo5916267 (封膜獵人)》之銘言: : 也許在軟體也蠻容易遇到類似個性的同事 : 我們是新創公司,我進去前已就有一個前端工程師,他從0建構了整個產品A 代表他能力不算差 而且產品A有很多他習慣的practice : 我是產品B的前端,剛好我們產品線不急,被拉去支援他們 改版 : 但在合作上就覺得跟他相處很不舒服 : 可能是把我當競爭對手吧? : 喜歡用高姿態/批判的方式codereview, 有些人講話是比較機歪 但review comment只要不是「這邊寫得好爛」這種垃圾話 應該都還是有點價值 然後個人認知中的code review 最主要的目的,是要讓你的code能符合既有的style 細到變數命名,粗到目錄結構、pattern的運用 有沒有重造輪子,還是有既有的utility function可以用但你不知道? 很多工程師(包含小弟我XD 都會有自己的寫法最屌的錯覺 對於沒看過或不熟悉的做法總是看不順眼 code review就是在確保 一個repo在多人維護下也能有一定程度的一致性 而不是每次都要在review過程中討論出一個很猛的寫法或架構 : 而我對他提出寫法的意見,才提開頭一句 : 就霹靂啪拉回了十句,順帶挑我程式毛病,我覺得更像是用公事來打壓別人 想像一下,你從0開始寫出了整個專案 一個新來的工程師,不了解既有的convention,上來就想照自己的方式寫 你會不會覺得奇怪? : 就講不得,而整個團隊都對他很頭痛,但又要依賴他做事情,很多文件需求都沒寫清楚,很多事情都綁在他身上,而且專案架構維護性蠻差的,我看了整整一個月才懂他的思路,大概就是小孩子拿AK的感覺 脾氣不好,但又依賴他做事,就更代表他確實能力不錯 文件需求不清楚是小公司滿常見的,而且需求應該是PM負責吧怎麼會是工程師來寫需求? : 我們做事不得不都要照的他的方式做事,但他又很自我中心,跟他配合心力大概4成是處理情緒問題4成才是程式問題 由他建立起的專案,按照他的方法做事,應該沒什麼問題 因為你也是短期支援而已,要是被你一通亂改改到他看不懂 後面要收拾的也不是你 : 我網路上找過類似的關鍵字 : 攻擊性強的同事 : 自以為是的同事 : 他的性格滿符合上面相關搜尋找到的描述 : 不知道各位前輩是怎麼應對的 : 我現在是當練EQ,大概還要半年改版完忍忍 這段都是個人心情的部分,就不多做評論 : 程式部分就消極應對,我有好的想法就跟別人討論,在他的專案只用他寫過的方式做 有好的想法,也要看專案性質跟時程 不一定你在A專案的好做法,到B專案也適用 尤其前端又是生態系很亂的一個環境 光React管理CSS的做法,就有三種以上知名的solution 每過一兩年都會看到「原本那套過時了,現在應該要用這個啦」的說法 如果你想套新的作法,當然就是要跟身為原作者的他討論 很多情況都是一段你看起來很糞的code 但前人已經想過幾種可能的優化方法,只是受限於某些條件無法這樣做 或是大家判斷這邊再改動的可能性很低,乾脆就先放著能動就好 因為沒有實例,所以我也無法給你太具體的建議 不過如果想做refactor的話,最好還是要有條理的整理出 舊做法哪裡不好,新做法哪裡好 是改善了效能、改善可讀性、改善擴充性,還是什麼呢? 如果你真的對自己的做法很有信心 也可以直接做個prototype後PR就丟出來 把重要的人全部拉進去當reviewer 要是多數人認同你的做法,只有他在PR裡面亂噴 就算最後沒辦法merge,那也是幫助你在公司建立credit 他則是在敗自己的人品 那也許有一天專案出事,主管就會想到要找你去救 到時候自然是你想怎麼寫就怎麼寫 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 125.228.191.217 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1666756242.A.FE3.html

10/26 12:25, 1年前 , 1F
code review不僅是一致性的問題而已,還有程式碼品質,執
10/26 12:25, 1F

10/26 12:26, 1年前 , 2F
行效率。
10/26 12:26, 2F
要優先度來說小弟還是認為一致性是最優先的 如果有一定規模的專案,一般的feature照原本的practice寫 效能跟可讀性應該都不會差到哪

10/26 12:32, 1年前 , 3F
推這篇
10/26 12:32, 3F

10/26 12:46, 1年前 , 4F
中肯推
10/26 12:46, 4F

10/26 13:03, 1年前 , 5F
code review 的好處很多,我個人另加一項:"事前預防總比
10/26 13:03, 5F

10/26 13:04, 1年前 , 6F
事後補救來的好",趕上了上線時間又如何,bug在客戶面前
10/26 13:04, 6F

10/26 13:04, 1年前 , 7F
爆了,客戶一樣翻臉拍桌
10/26 13:04, 7F

10/26 13:09, 1年前 , 8F
中肯,推
10/26 13:09, 8F
※ 編輯: w0005151 (125.228.191.217 臺灣), 10/26/2022 13:44:46

10/26 14:35, 1年前 , 9F
bug在客戶面前爆 是沒QA 跟code review關係?
10/26 14:35, 9F

10/26 15:00, 1年前 , 10F
客戶容忍度高可以讓客戶QA
10/26 15:00, 10F

10/26 16:19, 1年前 , 11F
推~前端的話一致性很重要,因為可以不一致的可能性太多
10/26 16:19, 11F

10/26 16:19, 1年前 , 12F
10/26 16:19, 12F

10/26 17:24, 1年前 , 13F
10/26 17:24, 13F

10/26 17:27, 1年前 , 14F
中肯XD
10/26 17:27, 14F

10/26 17:28, 1年前 , 15F
推這篇,工程師最常犯的一件事情就是,只顧做自己的事
10/26 17:28, 15F

10/26 17:28, 1年前 , 16F
有時候眼界沒放這麼高,事情不是你想的那麼簡單
10/26 17:28, 16F

10/26 18:06, 1年前 , 17F
這篇正解
10/26 18:06, 17F

10/26 18:21, 1年前 , 18F
客戶爆掉的時候已經交接給學弟的學弟了
10/26 18:21, 18F

10/26 18:31, 1年前 , 19F
確實,一致性超重要
10/26 18:31, 19F

10/26 18:48, 1年前 , 20F
覺得蠻中肯
10/26 18:48, 20F

10/26 19:42, 1年前 , 21F
同意這篇
10/26 19:42, 21F

10/26 20:33, 1年前 , 22F
10/26 20:33, 22F

10/26 20:45, 1年前 , 23F
10/26 20:45, 23F

10/26 21:00, 1年前 , 24F
10/26 21:00, 24F

10/26 23:38, 1年前 , 25F
我蠻認同這篇
10/26 23:38, 25F

10/26 23:43, 1年前 , 26F
以前我也是看不慣我家RD頭的老舊寫法 後來進來的一
10/26 23:43, 26F

10/26 23:43, 1年前 , 27F
些同事差不多心態 開發用當代最炫砲的php寫法 也沒
10/26 23:43, 27F

10/26 23:43, 1年前 , 28F
做code review
10/26 23:43, 28F

10/26 23:46, 1年前 , 29F
這些人後來拍拍屁股離職 留下一堆不太好維護的程式
10/26 23:46, 29F

10/26 23:46, 1年前 , 30F
碼 就由待在這的同事維護 我也有接到這種的 出事的
10/26 23:46, 30F

10/26 23:46, 1年前 , 31F
時候感到頭痛
10/26 23:46, 31F

10/27 01:39, 1年前 , 32F
有些人重構或是design pattern玩過頭了 都會寫出一些很
10/27 01:39, 32F

10/27 01:39, 1年前 , 33F
難懂的code 用IDE追半天還看不懂在寫啥
10/27 01:39, 33F

10/27 05:17, 1年前 , 34F
笑死XDDDDDDDDD
10/27 05:17, 34F

10/27 08:30, 1年前 , 35F
10/27 08:30, 35F

10/27 12:43, 1年前 , 36F
中肯 code review cmts就算是回一大堆 但如果都是有價值
10/27 12:43, 36F

10/27 12:43, 1年前 , 37F
的cmt 那也沒什麼問題
10/27 12:43, 37F

10/27 12:44, 1年前 , 38F
能夠願意理性討論的都還是好同事 最白爛的是被留了cmt直
10/27 12:44, 38F

10/27 12:44, 1年前 , 39F
接不甩你按resolved 的
10/27 12:44, 39F

10/27 13:02, 1年前 , 40F
有一說一,工程師也要學溝通
10/27 13:02, 40F

10/27 14:39, 1年前 , 41F
我的實際經驗是...想太美了 就算對方敗人品大家都知道 只
10/27 14:39, 41F

10/27 14:39, 1年前 , 42F
要架構是他做的 團隊有時程壓力就不可能對他的權限/職務
10/27 14:39, 42F

10/27 14:39, 1年前 , 43F
做任何異動 就算某個part是你做起來 你處理比較準比較快
10/27 14:39, 43F

10/27 14:39, 1年前 , 44F
會嘴你的還是會嘴 最終管理層也只是認知到“這兩個人以後
10/27 14:39, 44F

10/27 14:39, 1年前 , 45F
盡量別排一起” 接著兩邊摸頭 回到原案依然你做你的他嘴
10/27 14:39, 45F

10/27 14:39, 1年前 , 46F
他的 什麼都不會變
10/27 14:39, 46F

10/27 14:42, 1年前 , 47F
唯一解法 該翻臉翻臉 就事論事公開地吵 吵到大家受不了
10/27 14:42, 47F

10/27 14:42, 1年前 , 48F
但先決條件是你不怕離開團隊也不怕當黑臉
10/27 14:42, 48F

10/27 18:05, 1年前 , 49F
推這篇
10/27 18:05, 49F

10/27 19:55, 1年前 , 50F
10/27 19:55, 50F

10/28 06:45, 1年前 , 51F
推,想要大量重構,也要有出問題站出來負責的心態
10/28 06:45, 51F

10/28 13:21, 1年前 , 52F
中肯
10/28 13:21, 52F

10/29 16:42, 1年前 , 53F
推這篇
10/29 16:42, 53F
文章代碼(AID): #1ZMAwI_Z (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容:
完整討論串 (本文為第 3 之 10 篇):
文章代碼(AID): #1ZMAwI_Z (Soft_Job)