楼主:
tommady (tommady)
2016-10-16 02:21:34个位前辈好，
不才小弟我前天与主管发生争执，
是软件架构上的设计想法不同。
文章可能有点长，
如果前辈们不喜爱，
还请见谅。
小弟写后端的，有一个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的，单兵作业比较多，
请问我该如何处理这种多人协同作业上的歧义呢？
感谢。
楼主:
tommady (tommady)
2016-10-16 02:25:00喔对了，主管还挑明，以后谁敢改他这方式架构，杀全家。。。十分的无言。
作者: iFEELing (ing) 2016-10-16 03:00:00
你有遇过平常大小声 出事就把属下推出去挡的主管吗?他会负责就照他的指示写 他不负责就早点闪免得当替死鬼
作者:
pttworld (批踢踢世界)
2016-10-16 06:09:00至少这case的要拿到。
作者:
Jichang (C.C.Lemon)
2016-10-16 06:44:00你把他想成 你有两层要写 不就好了
作者:
maxqq (max)
2016-10-16 09:17:00反正他要负责，就给他负责，轻松点，拿钱办事，又不是一辈子在这家公司做事如果依照上一层是接收指令后，分析指令，呼叫逻辑那其实，你主管的方式可能是比较正确把 command_handle 拆细一点，比对 start/stop
作者: luckyshin (大屁) 2016-10-16 11:15:00
你是被主管聘来帮他做事，不是被聘来跟他吵架的
作者:
f124 (....)
2016-10-16 11:18:00照主管说的做阿 我只管钱有没有进来而已 干我屁事
作者:
yyc1217 (somo)
2016-10-16 11:28:00你不是老板 就是需要妥协 客户要大便就给他大便 顶多提醒一下这是大便
作者: badyy (nick) 2016-10-16 12:47:00
写清楚接手时就是被这样要求的,别被牵拖就好总比哪种前面接手就有问题,还反过来问你为什么的好
作者:
stosto (树多)
2016-10-16 13:59:00我觉得你主管是对的耶....
作者:
balaking (看八卦长知识)
2016-10-16 15:04:00我比较偏向你主管的架构分类...
本来就不会只有两层 中间一层主管不想写 叫你写而已
作者: giantwinter 2016-10-16 15:30:00
离职
作者:
balaking (看八卦长知识)
2016-10-16 15:50:00而且我觉得你主管的工作不叫game server, 应该是api adapter lib, 可以参考别人架构
https://goo.gl/DMx1WT你的工作就是用主管的lib把remote data存进db, 懂了吧
作者:
htury (冰点)
2016-10-16 16:06:00想太多,赶快做完交差领钱就对了,在台湾还期待什么是对的
作者:
bobju (枯藤老树昏鸦)
2016-10-16 17:30:00这主管好啊~ 很明确地表明了分工态度, 谁听谁的很清楚; 要是遇到打混战的主管跟你说好好好, 最后再翻脸不认帐, 那才要干在心里.
作者:
anr2 (???)
2016-10-16 17:45:00学习被领导，学习cowork
作者: dnabossking (少狂) 2016-10-16 18:05:00
还好，不是只有我觉得主管是对的
client 跟 server 沟通不能因为处理游戏逻辑卡住或等待。
作者:
now99 (陈在天)
2016-10-16 19:12:00离职阿
作者:
mathrew (Joey)
2016-10-16 19:57:00先不管这个架构谁对谁错 基本上主管要负责 你就照他说的做，然后钱有进户头就好了
作者: AlanSung 2016-10-16 21:26:00
一进来就生一条 goroutine ? really?
作者: badyy (nick) 2016-10-16 23:52:00
这厉害了,一个cmd一个goroutine ??? 怪可怕的
作者: AlanSung 2016-10-17 08:00:00
所以看来你没有做过 profiling，有用过 runtime/pprof吗而且如你所述的话，你把程式的稳定性交给前一台srv一个 goroutine 算你 2KB 好了 1M 就 2G 了而且你什么时候有去做 GC 呢？ 不管怎么看风险都很大如果有看系统 dashboard ， memory 一直往上，你家的DevOps / Ops 不会跳脚吗？ 有没有考虑用 channel加固定数量的 goroutine 比较好呢？
作者:
Argos (Big doge is watching u)
2016-10-17 09:33:00这种没有什么标准答案的东西你是在争什么？不就两条路
作者:
anr2 (???)
2016-10-17 09:48:00https://goo.gl/YgmfY2 不觉得一个cmd一个goroutine是个好注意, 还是需要有 load balance 跟 worker pool我没有实际遇过goroutine, 但是从文件来看一个 thread block应该说一个 goroutine block 就会在建立一个 goroutine把资源分配全部交给go 感觉就很危险 除非你有座 backpresure
作者:
iamshiao (CircleHsiao)
2016-10-17 11:03:00推 Jichang，我看的时候也是这样想，不过时间要够。
作者:
Argos (Big doge is watching u)
2016-10-17 13:26:00建议原PO都依你主管的去做就好 甚至今天主管硬要我变量全部取a b c 但他一个月给我十万 我照写不误 懂？
作者:
genesic (嗯?)
2016-10-17 15:00:00golang写出来的东西无法模组化吗? 为什么会争这个?
我觉得不想沟通的人是你 你没去理解你主管的设计理念你还是快点离职吧 不要继续待比较好
作者: AlanSung 2016-10-17 21:07:00
就你上面回的第二段，请查一下 defensive programming如果你不能理解为什么，可以问问主管或是其他比较有经验的人
作者: gogogogo3333 (gogogogo33333) 2016-10-18 07:12:00
设计始终出自于需求，没有绝对优势的设计模式
作者: AlanSung 2016-10-18 08:06:00
若是这样，我想你能不能 show 一下你的 test cases 呢我们可以从 test case 看出来别人（api, server）怎么用有助于讨论原本的设计哪种比较好
作者:
Argos (Big doge is watching u)
2016-10-18 13:32:00去上班讲难听点就是当狗啊 XDDDD
作者:
justben (BEN)
2016-10-19 00:33:00作者: badyy (nick) 2016-10-20 00:36:00
如果主管有提出实际分法就照做,最怕的是没提又要等人提等人验证,搞个好像是出钱的人才可怕
作者: longlongint (华哥尔) 2016-10-20 16:26:00
先闭嘴硬肏程式码 做完这期就闪