PTT職涯區 / Soft_Job (軟體人)

Re: [請益] 在小公司待不太下去

看板Soft_Job (軟體人)作者 (183club)時間8年前 (2017/05/15 20:38), 編輯推噓49(51推 2噓 128→)
留言181則, 44人參與, 最新討論串3/5 (看更多)
(原文述刪) 如下面很多前輩講的，寫code要進步的方式太多了，而code review是個方法沒錯，但這 管道也是有機會讓人對寫程式失去行趣。 程式寫的好不好，都是一個創作，但如果公司要求code review，但主管是那種很守舊， 你根本沒辦法跟他討論design pattern，甚至連一些很成熟的framework都不敢用，這種c ode你寫的會爽嗎？ -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 223.136.244.136 ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1494851901.A.DAF.html
噓
05/15 20:42, , 1F
溝通也是code review中的一環....
05/15 20:42, 1F
→
05/15 20:53, , 2F
code review是leader把你之前解的bug抓出來，你的解法
05/15 20:53, 2F
→
05/15 20:53, , 3F
可行，但是否為最佳解。
05/15 20:53, 3F
推
05/15 21:46, , 4F
這就靠溝通了，並不是用了design pattern就一定是好的作法
05/15 21:46, 4F
推
05/15 22:10, , 5F
程度差的才會在那code review，跟人腦compiler有什麼差別
05/15 22:10, 5F
→
05/15 22:12, , 6F
直接TDD(software是醬講的)或testpattern(IC設計)往介面
05/15 22:12, 6F
→
05/15 22:13, , 7F
一打，加上formal verification跟Lint軟體就好了，什麼年
05/15 22:13, 7F
→
05/15 22:13, , 8F
代了還在人腦compiler
05/15 22:13, 8F
→
05/15 22:15, , 9F
覺得軟體這行越來越多稀奇古怪但不實用的名詞，都是炒作
05/15 22:15, 9F
→
05/15 22:16, , 10F
起來的，像code review, scrum, CI, CD, git flow, UML,
05/15 22:16, 10F
→
05/15 22:18, , 11F
DevOps...等。資工這行最會炒作一些沒用且趕流行的東西了
05/15 22:18, 11F
→
05/15 22:20, , 12F
像敏捷文化, 沒人精確地講得出它是什麼, 工程的人也會弄
05/15 22:20, 12F
→
05/15 22:21, , 13F
這些不精確的東西
05/15 22:21, 13F
推
05/15 22:27, , 14F
跟文化部有什麼不同, 欣賞就好
05/15 22:27, 14F
推
05/15 22:29, , 15F
TDD不也依樣 0.0
05/15 22:29, 15F
→
05/15 22:30, , 16F
五樓自表了，雖然有些講得沒錯
05/15 22:30, 16F
→
05/15 22:32, , 17F
政治問題
05/15 22:32, 17F
→
05/15 22:37, , 18F
給雞巴人review只是他在釋放壓力而已。說你格式錯，命名
05/15 22:37, 18F
→
05/15 22:37, , 19F
錯，檔案放錯地方，能用簡單的做法叫你改成企業級架構
05/15 22:37, 19F
推
05/15 22:55, , 20F
以職場來講,守舊並沒有什麼不好.
05/15 22:55, 20F
→
05/15 22:56, , 21F
引入新工具,卻出包,未必是好事.
05/15 22:56, 21F
→
05/15 22:57, , 22F
我會覺得這是你跟這個主管不合,並不是誰的錯
05/15 22:57, 22F
推
05/15 23:04, , 23F
我是覺得說服主管用一個新框架也是一種能力啦
05/15 23:04, 23F
→
05/15 23:06, , 24F
敏捷開發會議，每天開始上班前集合圍成圈各自說明今天
05/15 23:06, 24F
→
05/15 23:06, , 25F
準備進行的項目。
05/15 23:06, 25F
推
05/15 23:06, , 26F
要推新玩具 要以他的立場 去闡述對他有什麼"好處"
05/15 23:06, 26F
推
05/15 23:18, , 27F
Agile就是....壓榨工程師的精神
05/15 23:18, 27F
→
05/15 23:21, , 28F
我也不喜歡code-riview，有時候效能跟維護便利性會
05/15 23:21, 28F
→
05/15 23:21, , 29F
相衝
05/15 23:21, 29F
推
05/15 23:21, , 30F
agile沒記錯的話本意是讓開發可以快速遞代產品功能的修正
05/15 23:21, 30F
→
05/15 23:22, , 31F
到台灣目前跑起來基本上就是把瀑布式的時間壓縮成agile區間
05/15 23:22, 31F
→
05/15 23:23, , 32F
自己寫了一些能加速開發的小工具，但是卻被要求把沒
05/15 23:23, 32F
→
05/15 23:23, , 33F
用到的判斷式拿掉
05/15 23:23, 33F
推
05/15 23:30, , 34F
呵呵，這篇讓我想到資深同事一句話:直接switch case
05/15 23:30, 34F
→
05/15 23:30, , 35F
不是很清楚嗎？用什麼抵賽配疼，結果在他commit過的co
05/15 23:30, 35F
→
05/15 23:30, , 36F
de看到上千行的switch case
05/15 23:30, 36F
推
05/15 23:32, , 37F
良性的code review可以經由討論讓程式碼更好吧？
05/15 23:32, 37F
→
05/15 23:33, , 38F
很多open source專案都用gerrit之類的系統在做review
05/15 23:33, 38F
→
05/15 23:34, , 39F
但如果負責review的人不願意溝通覺得自己最棒就會很糟
05/15 23:34, 39F
還有 102 則推文
→
05/17 13:43, , 142F
能在介面的地方定好power、速度、gate count、test case
05/17 13:43, 142F
→
05/17 13:43, , 143F
、scenario的SPEC。之後讓engineer去發揮，若engineer做
05/17 13:43, 143F
→
05/17 13:43, , 144F
不到才來code review討論為何做不到？大概有兩個原因
05/17 13:43, 144F
→
05/17 13:43, , 145F
1.engineer程度差不能fit規格 2.Architect程度差訂錯規格
05/17 13:43, 145F
→
05/17 13:44, , 146F
結論：程度差的才會在那code review
05/17 13:44, 146F
→
05/17 13:44, , 147F
X至於沒被test case抓而的問題本來就不在應用場景內會被
05/17 13:44, 147F
→
05/17 13:44, , 148F
trigger到，會被應用scenario用到的就必需在test case內
05/17 13:44, 148F
→
05/17 13:44, , 149F
那就是2. Architect程度差訂錯規格。
05/17 13:44, 149F
→
05/17 13:44, , 150F
結論都是：程度差的才會在那code review
05/17 13:44, 150F
推
05/17 14:57, , 151F
code review跟程度差不差沒關係吧,只是管理方式而已...= =
05/17 14:57, 151F
→
05/17 15:32, , 152F
review不外乎一行一行解釋,或是上系統給別人看一遍
05/17 15:32, 152F
→
05/17 15:32, , 153F
就是有機八人根本不是做我這塊卻要叫我一行一行解釋
05/17 15:32, 153F
→
05/17 15:33, , 154F
所以結論確實是太機八的人你就不要想review別人扣
05/17 15:33, 154F
→
05/17 18:44, , 155F
一個code review 被解釋成這樣 哥也是醉了
05/17 18:44, 155F
推
05/17 18:46, , 156F
code review本身就可以當成是spec內的一個活動，找的問
05/17 18:46, 156F
→
05/17 18:46, , 157F
題跟spec根本也不同面向
05/17 18:46, 157F
推
05/17 20:41, , 158F
code review的目的不就是要打那些自以為寫得很好的人臉嗎
05/17 20:41, 158F
推
05/17 20:47, , 159F
跟程度怎麼沒關係?有些公司官大學問大，審核的人程度爛
05/17 20:47, 159F
→
05/17 20:47, , 160F
浪費寫程式的人許多時間「教」他基本語法
05/17 20:47, 160F
→
05/17 20:49, , 161F
同意code review本身是好的，但遇到不對的人就....
05/17 20:49, 161F
推
05/17 20:55, , 162F
那些批評的人多半是遇到白癡亂搞才認為他是不好的制度
05/17 20:55, 162F
推
05/17 21:13, , 163F
人與人之間的關係和溝通方式決定code review帶給你的印象
05/17 21:13, 163F
→
05/17 21:13, , 164F
我一直非常喜歡我現在公司的code review的感覺，大家非常
05/17 21:13, 164F
→
05/17 21:13, , 165F
熱衷於討論，而不是在貶低別人或是覺得別人找自己麻煩
05/17 21:13, 165F
→
05/17 21:14, , 166F
因為大家關係好，也清楚知道團隊的目標與核心價值是什麼
05/17 21:14, 166F
→
05/17 21:15, , 167F
這樣的code review對我來說就是很積極正面的
05/17 21:15, 167F
推
05/17 21:33, , 168F
感覺chiwa 大大的團隊氣氛不錯
05/17 21:33, 168F
→
05/17 23:47, , 169F
程度差的才review XD 原來國外一堆大神程度都爛到爆 長見識
05/17 23:47, 169F
推
05/18 01:07, , 170F
sunsamy 可能有點太偏激了 雖然我大概懂你想說什麼 但是一
05/18 01:07, 170F
→
05/18 01:07, , 171F
間公司那麼多人 一個ticket指派下去 我可能會就實作的方向
05/18 01:07, 171F
→
05/18 01:07, , 172F
跟別人討論一下 然後我們有共識 但是幾天後他的PR可能實作
05/18 01:07, 172F
→
05/18 01:07, , 173F
細節完全有很大的改進空間 這時候code review就發揮作用了
05/18 01:07, 173F
→
05/18 01:07, , 174F
不是嗎？ 對方或自己也能在每次討論的過程中學到些東西。
05/18 01:07, 174F
→
05/18 01:07, , 175F
你總不能說 我們只hire最強的人或寫得爛是程度差 所以就
05/18 01:07, 175F
→
05/18 01:07, , 176F
算了... code review就是一套機制來解決這個問題的 否則
05/18 01:07, 176F
→
05/18 01:07, , 177F
公司那麽大 人那麽多 偏激的作法在好的公司不會是一個可以
05/18 01:07, 177F
→
05/18 01:07, , 178F
接受的解決方案的
05/18 01:07, 178F
推
05/18 23:37, , 179F
review只是一種方法 做好或做壞是人的問題
05/18 23:37, 179F
→
05/18 23:39, , 180F
解釋成人肉compiler就是沒弄清怎麼把review變成能做好的
05/18 23:39, 180F
→
05/18 23:39, , 181F
方法
05/18 23:39, 181F
‣ 更多 join183club 的文章
文章代碼(AID): #1P6Q4zsl (Soft_Job)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 join183club 的文章
文章代碼(AID): #1P6Q4zsl (Soft_Job)