@chenyu0532
首先我们来弄清楚大家出于什么原因极力推荐 mac 和 linux。这块 LZ 自己已经描述的差不多了。
一个原因是这两个系统上有比 windows 更优秀的 shell 以及和 shell 结合的更好的工作流相关工具。通过它们，我们就可以将写代码外的其他事情通过脚本和工具交给机器自动化处理，比如打包、测试、分发、部署等等。那么带来的好处就是开发项目时，可以更加专注的写代码，一定程度上提高开发的效率。
另一个原因，对后端来说，基于现在 DevOps 的趋势，后端是需要熟悉运维相关的东西的，我觉得几乎是后端必须掌握的技能，这块不多说。而对于游戏前端来说，因为移动端和主机的普及，前端的代码更多的会在类似 linux 的系统上跑。熟悉这类系统，会对自己在这类设备上调试或调优更有帮助。
可能还有其他原因，我一时还想不到。

然后从 LZ 的角度出发，我觉得这两块都是锦上添花的技能点。
自动化这块，前端没有像后端那么依赖，很多脚本也可以找后端帮忙写，真要自己弄，脚本这东西学起来也快的，打包什么的，熟悉下 jenkins 什么的也够了。
调试调优什么的，如果只是普通测试，现在的开发工具已经做的不错了，几乎不需要自己深入到系统里面。而后期做到引擎那块，会需要了解这类系统，但也是后面的事情了。

那么技术上如何才能走的更远呢（这里不讨论管理那块）？我觉得就两个方向吧，一个是做全栈（让老板能把你一个人当多个人用），一个是做引擎（你能做别人做不到的事情）。
LZ 已经说了不想做全栈，那么另外一个方向上，单单会用一些语言以及一些引擎是不够的，会实现策划的需求也是不够的。而一般的游戏大厂，多半是会走华丽这条路线的，而走华丽路线，那么就会有自己的引擎或者懂得如何深入优化现有的引擎。
所以 LZ 的数学是否还记得多少？图形学学的怎么样了？ OpenGL 是否熟悉？是否从源码层次上吃透了现在的图形引擎？

@rocksolid 你说的那是另一种情况，说重了点也算是违法的了。

LZ 的情况就是类似人家字幕组无偿的一集一集的做了字幕分享出来，还被免费享受的人催，或者指责字幕质量低下。

不满意的可以提 issue，有能力的可以改了然后提 pull request，甚至 fork 了自己继续开发，再不行，就用脚投票，直接不用走人。

如果真心想用的，就要考虑花钱，花了钱买了服务还有问题，就要考虑投诉甚至起诉。

另外，LZ 这么重的怨念发到 V2EX 上就算了，我们这些吃瓜群众看看就算了，有同情心的，提些问题，问些现象，帮助 LZ 解决下也可以。但是怨念当做 issue 发到 github 上了，我就有点受不了了。

为什么人家 github 上的项目一定要完美，你是花钱了还是参与开发了？

蚊帐加空调~

不要买 6p，6p 性能问题很大。

同上，没 32G 内存没动力。CPU 的更新没啥意义。

可以用 Parallels Client 代替。

其实关键点在于，如果不去体验，是没法知道这些东西到底是自己的刚需还是一时兴起。

如果生活中的这些东西可以允许自己租来试用一段时间，那么我感觉可以少花很多冤枉钱。

很多程序会有内存泄露，隔两天重启下机器就可以了。
另外，个人觉得 macOS 的程序太占内存了，多开几个 IDE，多看几个网页，甚至 16G 都不太够用。

通过配置 https_proxy 环境变量，就可以通过 ss 来发送消息了。

@aheadlead 如何为 telegram-send 配置代理？貌似 telegram 需要翻墙才能发送消息

@lty494685444 题材很不错，片头很好听。就是感觉拍这个电视剧的人功底不行，叙事有些平淡。但这部剧值得一看。

@lty494685444 最近在看《超感猎杀》，感觉也不错。就是里面很政治正确，一部分人可能接受不了。

可以想办法装 vcenter。只要有一台 windows server 2008 以上系统的机器就可以了。
很容易装，也很容易管理。

@notes 大多数公司还是非常看重学历的，但是如果有项目经验，那么学历就是其次了。

@johnpeter123
做软件的，其实学历真的不重要。我们公司以前招的一个高中学历的，那能力碾压我们公司大部分人。

话说楼主这个薪资，还是在上海，没法吸引到主程那样的人来投简历呀。

界面挺清爽的，我第一个 star 了。

代码可以考虑用 typescript 写。

@xrlin 求教你的这个脑图用什么工具画的？

@esolve 差别挺大的，各个方面的差别。之前和朋友聊，可能和做游戏最接近的也就是做 Java 中间件吧。但反过来说，如果做游戏做到一定程度，要转其他的行业，也还是能胜任的，原因后面说。

从组织上来说。做游戏大多数都是工作室的组织结构，里面分程序、美术、策划。一个工作室不大，几个人到几十个人不等，看游戏规模。这么分下来，程序其实没多少人。大多数游戏开发的程序一般都遵循少而精的原则来招人。即使游戏做大了，最多也就扩充部分人，然后再拆分出几个工作室出来。不会像互联网那样，几十个人围着一个组件做。

从业务上来说。对游戏需求的理解一般不能直接沿用到其他行业，逻辑的实现方式也因为底层结构不同，也不能直接沿用到其他行业。不过思考问题的方式整个软件行业都差不多，有能力吃下游戏逻辑，其他行业的业务代码也不会有什么问题，只是花时间理解需求和底层结构而已。

从技术上来说。这里针对涉及底层技术的后端，而不是一般的业务逻辑实现。由于游戏开发是工作室性质的，程序少而精，所以主程一般什么都要会！从长短连接的网络通讯、数据库、缓存、线程进程管理、多机集群，到运维、后台页面框架、巨量日志的生态分析，到关键游戏逻辑的各种 AI 算法、各种复杂战斗系统的实现等等，麻雀虽小，五脏俱全。
由于游戏通常情况下，比其他行业更容易引入用户，所以游戏程序面对性能挑战也会来的更早。你不可能有时间来慢慢改架构来应对流量的急剧上升，所以早期的架构制定很关键。

游戏的技术挑战大致分为关键系统实现、上线时的单机负载、游戏火了以后的集群实现上的挑战。大部分游戏基本在前两项就过不去了。由于游戏的高响应要求（比电商等的响应时间高一个数量级），单机的高承载以及逻辑和底层的强关联性，游戏逻辑状态的复杂等，再加上服务器很精贵、开发时间很紧张、人员少，所以做游戏开发很有压力！
但相对的，只要经历过项目上线，就会对技术有很大的提升，特别是那些上线过全球统一服的游戏！

@ghbai 如果我理解的没问题的话，这个方案是无法保证同一个生产者产生的 cmd 被有序的消费。