[請益] 碰到與主管在設計理念上不合該怎麼自保

看板Soft_Job作者 (tommady)時間7年前 (2016/10/16 02:21), 7年前編輯推噓22(24推 2噓 51→)
留言77則, 35人參與, 最新討論串1/9 (看更多)
個位前輩好， 不才小弟我前天與主管發生爭執， 是軟體架構上的設計想法不同。 文章可能有點長， 如果前輩們不喜愛， 還請見諒。 小弟寫後端的，有一個case分配剛好是 主管寫game server 我寫game logic 由於是第一個遊戲， 所以沒有任何前例或者範本或通用架構， 現在寫的一切就是未來的依循， 然而在前期討論都很順利， 意即 ， game server就是包含除了實際遊戲邏輯以外全部的部份， 我只要寫好遊戲邏輯，例如牌類比大小， 我只消管怎麼比大小就好， 其餘的都由game server處理。 這看起來很完美， 但實際做出來的時候， 我原本預想由我提供幾個interface， server只要呼叫這幾個就能完成一局遊戲， 比如: 1. start 2. stop 3. command handle 争議點在command handle， 我原本期待的是game server收到任何 client傳來的命令，只需要by pass給這interface就好， 這個interface會自行處理。 但是主管堅持，他只提供client命令的讀寫 ， 其餘的遊戲邏輯搞定。 也就是他只管server client之間溝通的library。 這樣變成我的遊戲邏輯得處理命令的接收， 邏輯得fork一個thread去聽有無命令進入， 而不是定義該怎麼處理命令， 然而這樣會讓未來每款遊戲都需要重覆的處理命令。 怎麼想都覺得這樣十分鬼異， 我說， 我想要的是只需要填肉，骨幹可以通用的架構。 主管回， 你別管這麼多，以後的人寫不好寫不順， 我會開除他，別管骨幹通用。 争論到最後，主管直接爆氣講， 你別覺得自己寫code很厲害， 我說這樣就是這樣。 當然，主管都講到這份上了， 我只能默默的說， 只是想提醒這樣架構會造成重覆， 以及通用性不足。 然後就吞了。 唉，小弟以前寫bios的，單兵作業比較多， 請問我該如何處理這種多人協同作業上的歧義呢？ 感謝。 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 180.217.165.21 ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1476555697.A.B3C.html
→
10/16 02:25, , 1F
喔對了，主管還挑明，以後誰敢改他這方式架構，殺全家。
10/16 02:25, 1F
→
10/16 02:25, , 2F
。。
10/16 02:25, 2F
→
10/16 02:25, , 3F
十分的無言。
10/16 02:25, 3F
推
10/16 02:28, , 4F
聽話 辭職 選一個
10/16 02:28, 4F
推
10/16 02:30, , 5F
吞阿 他是主管欸。反正出事責任是他扛
10/16 02:30, 5F
→
10/16 03:00, , 6F
你有遇過平常大小聲 出事就把屬下推出去擋的主管嗎?
10/16 03:00, 6F
→
10/16 03:12, , 7F
他會負責就照他的指示寫 他不負責就早點閃免得當替死鬼
10/16 03:12, 7F
→
10/16 06:09, , 8F
至少這case的要拿到。
10/16 06:09, 8F
推
10/16 06:44, , 9F
你把他想成 你有兩層要寫 不就好了
10/16 06:44, 9F
推
10/16 07:05, , 10F
再寫一層interface?
10/16 07:05, 10F
噓
10/16 08:58, , 11F
你的主管是對的
10/16 08:58, 11F
推
10/16 09:17, , 12F
反正他要負責，就給他負責，輕鬆點，拿錢辦事，又不是一輩
10/16 09:17, 12F
→
10/16 09:17, , 13F
子在這家公司做事
10/16 09:17, 13F
推
10/16 09:28, , 14F
如果依照上一層是接收指令後，分析指令，呼叫邏輯
10/16 09:28, 14F
→
10/16 09:29, , 15F
那其實，你主管的方式可能是比較正確
10/16 09:29, 15F
推
10/16 09:35, , 16F
把 command_handle 拆細一點，比對 start/stop
10/16 09:35, 16F
推
10/16 11:15, , 17F
你是被主管聘來幫他做事，不是被聘來跟他吵架的
10/16 11:15, 17F
推
10/16 11:18, , 18F
照主管說的做阿 我只管錢有沒有進來而已 干我屁事
10/16 11:18, 18F
推
10/16 11:28, , 19F
你不是老闆 就是需要妥協 客戶要大便就給他大便 頂多提醒
10/16 11:28, 19F
→
10/16 11:28, , 20F
一下這是大便
10/16 11:28, 20F
推
10/16 11:41, , 21F
寫個負責處理命令的去呼叫interface
10/16 11:41, 21F
推
10/16 11:49, , 22F
這不是軟體架構問題 是工作分配問題
10/16 11:49, 22F
→
10/16 12:47, , 23F
寫清楚接手時就是被這樣要求的,別被牽拖就好
10/16 12:47, 23F
→
10/16 12:56, , 24F
總比哪種前面接手就有問題,還反過來問你為什麼的好
10/16 12:56, 24F
推
10/16 13:59, , 25F
我覺得你主管是對的耶....
10/16 13:59, 25F
推
10/16 15:04, , 26F
我比較偏向你主管的架構分類...
10/16 15:04, 26F
→
10/16 15:27, , 27F
本來就不會只有兩層 中間一層主管不想寫 叫你寫而已
10/16 15:27, 27F
推
10/16 15:30, , 28F
離職
10/16 15:30, 28F
推
10/16 15:50, , 29F
而且我覺得你主管的工作不叫game server, 應該是api ada
10/16 15:50, 29F
→
10/16 15:50, , 30F
pter lib, 可以參考別人架構 https://goo.gl/DMx1WT
10/16 15:50, 30F
→
10/16 15:56, , 31F
你的工作就是用主管的lib把remote data存進db, 懂了吧
10/16 15:56, 31F
→
10/16 16:06, , 32F
想太多,趕快做完交差領錢就對了,在台灣還期待什麼是對的
10/16 16:06, 32F
推
10/16 17:30, , 33F
這主管好啊~ 很明確地表明了分工態度, 誰聽誰的很清楚; 要
10/16 17:30, 33F
→
10/16 17:31, , 34F
是遇到打混戰的主管跟你說好好好, 最後再翻臉不認帳, 那才
10/16 17:31, 34F
→
10/16 17:31, , 35F
要幹在心裏.
10/16 17:31, 35F
→
10/16 17:45, , 36F
學習被領導，學習cowork
10/16 17:45, 36F
→
10/16 18:05, , 37F
還好，不是只有我覺得主管是對的
10/16 18:05, 37F
→
10/16 19:07, , 38F
client 跟 server 溝通不能因為處理遊戲邏輯卡住或等待
10/16 19:07, 38F
→
10/16 19:07, , 39F
。
10/16 19:07, 39F
抱歉, 小弟圖和文的解釋中沒有提到命令的收送方式, 我們用Golang實做, 所以client每個命令進來game server, 都是一個單獨的goroutine, 我的想法是, 這條goroutine應該要直接呼叫interface的command handle, 而非還得傳channel給game logic去處理.
推
10/16 19:12, , 40F
離職阿
10/16 19:12, 40F
推
10/16 19:57, , 41F
先不管這個架構誰對誰錯 基本上主管要負責 你就照他說
10/16 19:57, 41F
→
10/16 19:57, , 42F
的做，然後錢有進戶頭就好了
10/16 19:57, 42F
※ 編輯: tommady (114.44.197.244), 10/16/2016 20:26:01
→
10/16 21:26, , 43F
一進來就生一條 goroutine ? really?
10/16 21:26, 43F
→
10/16 23:52, , 44F
這厲害了,一個cmd一個goroutine ??? 怪可怕的
10/16 23:52, 44F
對, 因為關於balance的部份, 有另一台server在玩家進入game server之前就先管理, 所以一台game server, 不會有過多玩家的問題, 況且依照golang的特性, 幾百萬條goroutine都不是問題, 因此很放心的就每個命令一條goroutine XD. ※ 編輯: tommady (114.44.197.244), 10/17/2016 07:19:03
→
10/17 08:00, , 45F
所以看來你沒有做過 profiling，有用過 runtime/pprof嗎
10/17 08:00, 45F
→
10/17 08:02, , 46F
而且如你所述的話，你把程式的穩定性交給前一台srv
10/17 08:02, 46F
→
10/17 08:04, , 47F
一個 goroutine 算你 2KB 好了 1M 就 2G 了
10/17 08:04, 47F
→
10/17 08:05, , 48F
而且你什麼時候有去做 GC 呢？ 不管怎麼看風險都很大
10/17 08:05, 48F
→
10/17 08:06, , 49F
如果有看系統 dashboard ， memory 一直往上，你家的
10/17 08:06, 49F
→
10/17 08:06, , 50F
DevOps / Ops 不會跳腳嗎？ 有沒有考慮用 channel
10/17 08:06, 50F
→
10/17 08:06, , 51F
加固定數量的 goroutine 比較好呢？
10/17 08:06, 51F
推
10/17 09:33, , 52F
這種沒有什麼標準答案的東西你是在爭什麼？不就兩條路
10/17 09:33, 52F
→
10/17 09:48, , 53F
https://goo.gl/YgmfY2 不覺得一個cmd一個goroutine是個好注
10/17 09:48, 53F
→
10/17 09:49, , 54F
意, 還是需要有 load balance 跟 worker pool
10/17 09:49, 54F
→
10/17 09:49, , 55F
我沒有實際遇過goroutine, 但是從文件來看一個 thread block
10/17 09:49, 55F
→
10/17 09:50, , 56F
應該說一個 goroutine block 就會在建立一個 goroutine
10/17 09:50, 56F
→
10/17 09:51, , 57F
把資源分配全部交給go 感覺就很危險 除非你有座 backpresure
10/17 09:51, 57F
推
10/17 11:03, , 58F
推 Jichang，我看的時候也是這樣想，不過時間要夠。
10/17 11:03, 58F
→
10/17 13:26, , 59F
建議原PO都依你主管的去做就好 甚至今天主管硬要我變數全部
10/17 13:26, 59F
→
10/17 13:26, , 60F
取a b c 但他一個月給我十萬 我照寫不誤 懂？
10/17 13:26, 60F
推
10/17 15:00, , 61F
golang寫出來的東西無法模組化嗎? 為什麼會爭這個?
10/17 15:00, 61F
噓
10/17 18:04, , 62F
我覺得不想溝通的人是你 你沒去理解你主管的設計理念
10/17 18:04, 62F
→
10/17 18:05, , 63F
你還是快點離職吧 不要繼續待比較好
10/17 18:05, 63F
受教了, 因為玩家數量永遠衝不過200... 所以profiling就懶惰了... 如果說要用channel去限制命令傳達的數量, 那何不直接game server在聽的時候, 就做管控呢? 為什麼得丟到game logic來管控呢? 這不是多費一道工嘛? 這也是我十分想不透的一點. 我以為game logic只要純粹定義怎麼玩一局遊戲就好, 而不是還得管其他拉里拉雜的. 一點拙見, 還請包含. 至於為什麼會爭執... 其實主管只要告訴我, 他的想法好壞在哪裡, 別情緒化就爆炸, 我一定會接受的, 至於現在, 我就是"當狗"聽他的作法, 但是十分好奇他的設計想法, 又或者是我想法太狹隘, 所以才來板上請求賜教. 感謝. ※ 編輯: tommady (114.44.197.244), 10/17/2016 21:00:45
→
10/17 21:07, , 64F
就你上面回的第二段，請查一下 defensive programming
10/17 21:07, 64F
→
10/17 21:08, , 65F
如果你不能理解為什麼，可以問問主管或是其他比較有
10/17 21:08, 65F
→
10/17 21:08, , 66F
經驗的人
10/17 21:08, 66F
謝謝您的回覆, 我的game logic裡面當然會有一些簡易的檢查判斷, 例如最高上限幾個人, 目前cpu, memory使用量, 然後反饋給game server, (其實cpu, memory 使用量我也覺得應該是game server要幫我監控才對 XDDD) 我想應該能阻擋一些可怕的例外, 但是小弟想理解的是令一層面的問題, 為什麼放著簡單的function call不用, 偏要IPC. 感謝您. ※ 編輯: tommady (114.44.197.244), 10/17/2016 21:22:08
→
10/18 07:12, , 67F
設計始終出自於需求，沒有絕對優勢的設計模式
10/18 07:12, 67F
→
10/18 08:06, , 68F
若是這樣，我想你能不能 show 一下你的 test cases 呢
10/18 08:06, 68F
→
10/18 08:06, , 69F
我們可以從 test case 看出來別人（api, server）怎麼用
10/18 08:06, 69F
→
10/18 08:07, , 70F
有助於討論原本的設計哪種比較好
10/18 08:07, 70F
→
10/18 13:32, , 71F
去上班講難聽點就是當狗啊 XDDDD
10/18 13:32, 71F
→
10/18 13:36, , 72F
聽他的記得錄音
10/18 13:36, 72F
推
10/19 00:33, , 73F
https://github.com/urfave/negroni 阿就裝個middleware
10/19 00:33, 73F
→
10/19 00:34, , 74F
inject response
10/19 00:34, 74F
→
10/20 00:36, , 75F
如果主管有提出實際分法就照做,最怕的是沒提又要等人提
10/20 00:36, 75F
→
10/20 00:36, , 76F
等人驗證,搞個好像是出錢的人才可怕
10/20 00:36, 76F
推
10/20 16:26, , 77F
先閉嘴硬肏程式碼 做完這期就閃
10/20 16:26, 77F
‣ 更多 tommady 的文章
文章代碼(AID): #1O0dEniy (Soft_Job)
討論串 (同標題文章)
以下文章回應了本文 (最舊先)：
完整討論串 (本文為第 1 之 9 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共9篇)
‣ 更多 tommady 的文章
文章代碼(AID): #1O0dEniy (Soft_Job)