前端不玩游戏做个毛线前端啊！
昨天胡扯游戏的群友们，关于 前端程序不玩游戏，就不可能做好游戏……吗？ 这篇中的观点，进行了一次激烈的讨论。
本文标题，就是群友的观点，暴躁而真实。
我把观点做了一些整理，尽量原样还原，再讲讲我的观点。
期望在管理维度，用完善的流程来驱动不坏的结果
团队必须有人对游戏感特别好，让这个人来盯好产品就可以。
有游戏感的程序员，因为理解业务，不要非常精准的看文档也做的出来功能。而不玩游戏的程序，做东西太费劲了。
之前认识一个程序，游戏玩的老多了，都是问：你就说抄谁吧。这种程序在工作沟通中省力。
但真正到了个人工作感受中，每个人都有自己的认知。你觉得哪种正确就按照自己觉得正确的方式去驱动团队。
不是每个好的程序都能体验到游戏的快乐。
游戏的设计最下层的业务结构设计和技术能力，这应该是一个程序员最重要的职责。具体到对于业务的实现，还看策划跟程序的互补关系。
我希望找一个重度游戏玩家，理解游戏，最好还能懂交互，底层技术能力也靠谱，略懂 DDD，这样真的就是看到哪里抄哪里就可以。
而在现实世界中，找个技术能力靠谱的就已经很难了。基本业务拆分做不好的，那肯定基本的表逻辑，业务逻辑都大概率问题，就是技术不行。
但经常遇到的问题，是前端看起来交互困难，改起来 bug 来回反复，这种在业务层和数据层，大概率已经乱七八糟了。
复盘下来就是技术没有做好最基本的业务代码结构的拆分和对未来变动的预期，程序都理解不了策划给的文档，做的东西跟文档不一样。
需求里面业务逻辑和产品交互，这块不要指望程序员。如果这些东西都压到程序，那就是团队管理的问题。
要么换管理的人要么换程序，看怎么选择了。
曾老师补充：
DDD（Domain Drive Design，领域驱动设计）
因为 人是系统最大的BUG
DDD 期望消除信息不对称，将常规MVC三层架构中自底向上的设计方式做一个反转，以业务为主导，自顶向下的进行业务领域划分。（依赖倒转模式？）
https://developer.aliyun.com/article/1436383
期望在执行维度，用高效的执行来产出更好的结果
我曾经待过一个前端主程是老板徒弟的团队，连文档都不看。沟通成本太大，别人2天弄好，换这种人，不理解，来回扯一周。
你见过一个不玩游戏的，知道什么是血条，什么是技能，什么是BUFF？一个从不开车的你还指望坐上去立马下赛道？
天生再厉害也不会懂自己没见过的东西。一个没玩过游戏的前端，怎么天生突破认知，具有很强的游戏感？逻辑上就说不过去。
玩游戏不是要他一定要体验到游戏的欢乐，而不是让我鸡同鸭讲。不是说最重要的职责做好，就其他什么都不用的。
对于业务实现，怎么 节省成本 也是很重要啊。
一个完全不玩游戏的程序，理解成本就会比其他的高，开发成本自然就高。
什么叫技术能力靠谱？技术都没问题，结果产品做的图层全部错乱，花3、4天来整理。从代码逻辑和技术层面来说，可能完全没有问题的，但是做出来的东西会导致纠错成本增加。
还有维护？弄一个逻辑错乱的表格，你怎么维护？不是拆不清楚啊，按程序的逻辑很好填，按策划和维护的层面就不一定。
维护出现问题，不是 bug，是成本增加。
为什么管理维度和执行维度如此不同？
暴躁不可怕，可怕的是有时候需求稍微有点变化，他会突然开始奋发图强推翻重构。
问程序玩过啥游戏，回答王者荣耀的，基本可以判定不咋玩游戏。
有些时候，或者很多时候，当你发现你找的这个前端开发他（就是不怎么懂，甚至讨厌游戏）不行时候，你层级上已经没有选择余地——常见中厂，大厂，以及缺乏技术合伙人的团队。
甚至，可能人家态度很好，代码效率也高，就是不玩游戏，高度依赖文档——大厂团队的边缘项目经常分配到这种。
那怎么办？懂游戏的前端当然是最棒的。不懂，但是似乎还能干活的前端，你又干不掉——凑合用吧，还能如何？
从我遇见的比例推测，不多，但是也不算少，当然最主要是那种，爱免费低价的独立单机游戏，讨厌商业化游戏。因为很多程序员选什么引擎，或者为啥当程序员，单纯是因为觉得好找工作能赚钱。
玩不玩游戏？国民游戏可能玩玩而已。而是大部分时候面试程序的那个人，就算他自己是程序，他不一定想到这个问题。
或者就算想到了，但是对面明显代码能力可能不错—— 苦苦策划吧
并不会有足够的人手，家各司其职，效率就会更高。除非不去分配任务，否则某个策划需求一个时间周期里必然会对应一个美术和一个前端的工作分配啊。
人力充沛，整体进度不容易耽误，但是必然是更合适沟通的那个前端做了更多活，也是现实里容易 鞭打快牛 的缘故。
人力充沛，整体进度不容易耽误，毕竟钱能解决很多问题，除了解决不了没钱和好玩。
人越多，人员流动就越多，就越难以做非标准化的创意工作。对抗人员流动，需要让所有的工作尽量标准化，标准化的游戏不好玩，就这样。
还有一个问题是，国内游戏行业普遍是年抛型项目，不在意是否屎山，因此标准化积累很差
如果程序不玩游戏，策划不懂数据结构，最后大概率就是效率极其低下，并且下一个项目也没有任何提升。
所以正常所以概括点，面对前端程序（如果写代码能力还行）要不要懂游戏，懂自己家游戏这个问题，那就是曾老师说的两个方向，只是极端情况一个结果。文档写清楚，是个可以无止境的概念。
方向一 一个期望在管理维度，用完善的流程来驱动不坏的结果——极端结果，这个程序可以写代码，就是不玩游戏，苦苦策划吧，文档写清楚。
方向二 一个是在找谁来执行维度先行过滤，找不到合适的继续找，找到后再用高效的执行弥补找不到的时间成本，以期待产出更好的结果——极端结果，自然还是艹尼玛，玩过连连看，那也凑合吧，苦苦策划吧，文档写清楚。
测试怎么办？测试也要喜欢玩游戏吗？策划、程序、测试把他们三个脑海中文档没写清楚的地方如何对齐？
文档写清楚可能永无止境，但可以用一场需求评审会来对齐这些细节。至少策划要讲清楚，有程序和测试要求他把某些细节补充到位。但清楚到一个复杂的程度，文档通常就没啥人看了。
而且，草台班子就不配有QA，策划测试一锅端，策划自己就是QA，自己的策划自己测！
其实这俩个问题提大部分团队还是受困于钱的问题，钱不够，所以 DEADLILNE 近在眼前，所以人手分工不够，所以流程拆解不开，所以文档编写不细，所以执行时间不足，
所以出问题的是时候要么是程序不懂游戏、要么是策划文档没写清楚。
真把一个哪怕是最不懂游戏的程序拉出去找地方泡泡茶，瞎聊几句，大部分还是能吐槽几句搞不懂哪个XXX怎么会设计成XXX样子，我看人家XXX都是XXXX。然后问，你咋不提呢？哎屁股后面还一堆催债的，哪里有时间去想去问去XXX。
曾老师：用结果说话，这世界完美的人非常少
对于群里的激烈讨论，我当然是那个和稀泥的。
但实际上，这两个讨论站在不一样的角度，是没办法融合的。
而且，真实的商业世界，就是追求平衡之术啊！
曾老师认为，一切还是结果说话，这世界完美的人非常少。管理者大多数都是在做平衡。
只是有的人，可以接受不完美；有的人，无法接受不完美罢了。
明白自己的下限，是创业的基础。
明白团队的上限，是选对方向的前提。
结合自己和团队的特点，做出高于团队上限的事情，是管理的能量。
德鲁克说过：管理，就是让平凡的人做出不平凡的事。
然而优秀的程序员，大多数无法接受不完美 ╮(╯＿╰)╭
我相信我们这个漏洞百出，千疮百孔的互联网，也是跑着一堆代码屎山。而且这些屎山呢，会永远存在下去的。
前段时间全球 Windows 蓝屏，还有阿里云的宕机事故，都是低级别的人类搞出来的？
「小官巨贪」这类案例，不正是官僚科层系统有 BUG 的明证吗？
行业内卷，大家都希望希望今天提需求，第二天就出结果。没有足够的时间，哪来精品呈现？
所以大家总会有一天，会变成自己讨厌的样子……这是不可避免的
到了一定的位置后，还会发现，这才是世界的常态。
突破思考壁垒后，又发现，原来坚持高标准是可以获得更大成功的！但前提是需要更多的条件。
而这些条件，往往又需要一些气运的支持。这些气运，是有概率的。
接着我们又发现，努力可以增加这个概率。但增加的不多。
所以，大部分人就会放弃努力成为完美的人，反而会甘愿做个不完美的人。这叫就 不惑。
有少数疯子，一直在坚持。
他们最后，要么变成了疯子，要么变成了骗子，要么变成了老赖，要么就去了另一个世界。
只要少数人，他们成功了，变成了大佬。
https://civitai.com/images/26139677
机械工业出版社 & 胡扯游戏赠书活动（点击链接参加）
最胡扯群昵称评选：机械工业出版社 & 胡扯游戏赠书活动（第一期）
《学会说不：成为一个坚定果敢的人（原书第2版）》
《体验传递：游戏用户体验分析与设计》
《学会提问（原书第12版·百万纪念珍藏版）》
特别介绍
有很多重要内容，公众号发不了，但群里特别能聊。
群里有独立开发者，游戏公司创始人、大厂负责人、量子理论研究者……
关注公众号可以进群一起唠嗑，独立游戏、商业游戏、流量游戏、研发、投放、发行、运营、招人 都能聊，纯唠嗑也欢迎。
下面几个系列文章花了不少精力，可以读一读：
创业系列：
效率系列：
产品分析：
立项系列：
混变系列：
运营系列：
成长系列：
会议系列：
奇技淫巧：
荐号系列：
电子游戏是怎么赚钱的：
再多读几篇：
都刷到这里了，不来个「点赞」「分享」「在看」一键三连吗？