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

[NDark (溺於黑暗)]

※ 引述《tommady (tommady)》之銘言：

: 争議點在command handle，
: 我原本期待的是game server收到任何
: client傳來的命令，只需要by pass給這interface就好，
: 這個interface會自行處理。
: 但是主管堅持，他只提供client命令的讀寫 ，
: 其餘的遊戲邏輯搞定。
: 也就是他只管server client之間溝通的library。
: 這樣變成我的遊戲邏輯得處理命令的接收，
: 邏輯得fork一個thread去聽有無命令進入，
: 而不是定義該怎麼處理命令，
: 然而這樣會讓未來每款遊戲都需要重覆的處理命令。
: 怎麼想都覺得這樣十分鬼異，
: 我說，
: 我想要的是只需要填肉，骨幹可以通用的架構。

你的架構是data driven的一種.
理想上 應可以彈性同時支援 你自己的需求 以及 你主管的需求 , 才是好設計.
你執著在於要給data的人照你的方式給,就失去合作跟分工的意義了.


我以往實作幾次類似的系統, 我把這邊的Data叫做Command.
我想像成這樣的事情是將 Client Game Logic 原本是大量黑箱的情形
"解放" 將控制權拆給 給Command的人. 讓Client變成一個Command播放機.


Client詢問 -> Server回覆可能不同的Command(s) -> Client 播放Command

但是為了要把Command的類型定義的詳細有彈性.
Server的Command內容最好是懂Client的人一起做,(我當時是主程式S/C一把抓)
避免Server背景的人比較沒有Client運作概念,
所以不知道Client需要甚麼,想像起來比較抽象.


打比方說 當戰鬥開局,對Server請求戰鬥結果,同時要播放戰鬥後特效時

你的想法比較接近

Server 回覆

Command_UI_VictoryFadeIn (介面進場)
Command_Effect_VictoryExplosion (煙火特效)
Command_Audio_Victory (勝利音效)


你主管的想法比較接近

Server 回覆

Command_Victory (勝利)

接著Client 就應該知道要播放介面,特效,音效
後者的想法並沒有特別不好,
其實兩者都能夠達到規格目的,
因為從某個角度來說Client的規格,對Server來說就是一個黑箱.
所以你Client的責任就是把這個黑箱作好, Server可以不想知道這黑箱的內容.



如我一開始所說,你的架構裡應能支應兩種不同的角度(才是好架構)
你應該換個角度來看當Server回覆 Command_Victory 的時候
其實 Command_Victory 的運作內容 可以是由Client轉譯為播放:

Command_UI_VictoryFadeIn
Command_Effect_VictoryExplosion
Command_Audio_Victory

這樣就能夠保持原本你要的系統,又同時能符合主管的需求.
你把他想像成你正在重構開發方法從黑箱為命令系統,
而這轉譯就是過渡時期,重構的是你,當然你要多做點事情.




總之,技術問題是一種自我修練,
不要為了架構問題跟別人吵架,文無第一武無第二.

對有些人來說,有時候
        把案子做完,不要出包,今年的年終有領到,
        家裡的小孩沒有需要為了醫藥費煩惱.已經是一種奢求.

我認為能在兩邊都顧及的方式把事情做完也是一種需要克服的困難及挑戰.


共勉之.










--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 124.109.118.86
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1476580211.A.AFA.html
推 maxqq: 真是有道理，team work 才是重點，軟體沒有最好只有更好
→ kiawe: 『文無第一武無第二』同意！
推 dollar1019: 同意～架構符合當下需求都是好的
→ f124: 把案子做完,不要出包,今年的年終有領到 這才是真的
→ TSW: 我覺得你講的跟原PO提的根本是不同東西....
→ TSW: 原 PO 那個 game logic 看起來像是 server side 跑的
推 tommady: 是server side，但沒差，謝謝回覆。
推 Argos: 如果確定好需求 才能用像這種黑箱方式吧？不然你這樣一個命
→ Argos: 令 我Client就寫死在程式裡做三種動作 那有一天我需求改成
→ Argos: 我有300種動作要能隨著server端命令變換不就頗麻煩？
→ Argos: 所以確定1.需求不變 2.就算需求變 就強迫讓Client改版 但
→ Argos: 這可能又會衍生出其它問題...