这真的是围城。
不知道楼主现在是哪个阶段，我自己想的是等 30+结婚生娃了，就找个国企当做最终站，有空带带娃做点小项目，只要工资能应付贷款之类的就行。

上次听同事说他前同事也是年纪轻轻跑去电信云，干了不到一年就跑路了

搜狗。用了有十年了。一开始打动我的功能是按下 u+部首偏旁，就可以打出字。还有自定义短语之类的。

没，刚好昨天生日，回了趟家，过完生日直接跨年。

有三倍跟调休的话，还是不亏的。我们那 8 小时算一个工作日，加班 12 小时算 1.5 天 x3 倍，薅公司羊毛的好机会。
回头随便找个周末+调休，回家就是了。
挣钱嘛，不寒碜

有测试的话，就简单自测主要逻辑，然后交给 QA 测，有时候状态不好，能让他测出来一堆 bug ，修着修着，代码就走样了，有时候上线了也不安心。
没 QA 就要全部自测。自测完还出问题的功能，一般情况是漏掉某些条件分支的处理，十分钟内查日志修 bug 重新发版，快得很。

if 写得太暴力，看着简单，逻辑反而弯弯绕绕地

不如开空调或者暖气，让房间温度适宜一点。
我房间除了大冬天没有暖气确实冷，秋天或者夏天开空调，就算不盖被子也不容易着凉。

有点点强迫症，自认为是对自己代码比较负责的，之前也给项目内的同事做过 code review 。总体感受就是，shit 山是无法避免的。

追求完美是不现实的。代码开发是要解决实际问题，而需求是不断变动的。你无法预测到两三年后的功能需求，打补丁是在所难免的。
你无法保证自己每一段代码都是“完美的”，你也无法保证每个同事都对自己有高要求。即使你能保证自己的设计思路一致，别人再接手的时候，也不能再次还原你的想法。时间久了就夹杂着每代开发不同的“想法”在里面了。

反正我已经看开了。之前卡同事的代码卡得比较严。现在只要别歪得太离谱，我会先给过。
搞 code review 是累活，不少团队 leader 嘴上说着要有追求，要规范 blahblahblah ，等到评绩效的时候就对你的付出视而不见。
我会尽量保持对自己的要求，跟同样有兴趣的同事交流。至于其他人，我真的管不着了

淦，发出来好像吐槽的偏多了。重申一下，4 代我认为是好玩的，整个系统是有优化和提升的，作为系列的粉丝我认为值得买。

罗列一些看法。

剧情关卡有点新意，不同关卡间提供了短片介绍武器、铠甲之类的科普。
文明目前还只有 8 个，不同国家的模型的差异比 2 代的大，更像是 3 代那种。
AI 比 2 代强了不少，能打得有来有回，不会无脑堆城堡。
相较前代，UI 优化了一些操作。比如大规模作战的时候，能直接显示各兵种数量，点选跟反选某个兵种也简单。
但同时也简化了不少东西。比如 2 代的跟随和巡逻没有了。僧侣外出拿个圣物，步兵走太快一直脱节，没有保护效果。
小地图里面的肉类资源更加显眼，但没有了切换资源、军事视角的操作。后期在一堆营地里面找个金矿很费精力，也不能快速找出分散的军力。
兵模更加高清和精致，但是辨识度没低清的 2 代高。动作跟音效反馈很一般，视觉上我感觉有点延迟。
图标过于抽象，UI 界面也是非常简洁。看着很“新”，但是这种模拟历史的 RTS 游戏，我更希望画风能更加写实一点，然后兵种介绍再配个立绘+文字描述，就很舒服了。这作的美术风格，我是不太喜欢的。
科技树很简陋，没有兵种数据，同时也没有地图编辑器。不能像前作那样直接进编辑器让不同兵种互抗，了解对战的真实强度。

总得来说，底子不错，内容还不够充实，同时有不少功能都是“待开放”的阶段。想玩可以玩，等个一年半载会更舒服。（希望如此）

IO 多的可以用多线程，计算多的用多进程，去看下 multiprocessing 这个库咯

老哥你是国人吗，怎么这段话看着那么像。。翻译过来的

我自己没这么用过，但是我见过第三方库的常见做法是，先用 DeprecationWarning 提示用户，告知他们做好迁移准备（比如改用另一个函数），并在某个版本之后移除掉这些函数 /方法

瞄了一眼你之前的贴子以及电脑配置，既然你没有在家打游戏的需求，而且有笔记本，那么真不如把台式机放在公司。

这样就可以解决以下问题：
1. 上班的时候直接使用台式机，回家后才需要远程到公司。正常情况在公司 coding 才是主要场景吧？
2. 网络直接连办公网，解决了使用内网服务的问题。不必再写完拉回公司测试。
3. 薅公司羊毛，7x24 小时不关机！不用担心忘记开机的问题
4. 电费虽然没多少，一年下来还是有几百块的，聊胜于无。

苹果的刀法一直是这样的。
比如你想要买 64G 存储的手机，他只给你 32G 和 128G 两个档，低的肯定不满足需求，只能加钱买超过自己需求跟预算的档位。
买苹果的产品就要为了“加一点”而付出更多的钱。

@0576coder #11

前后端分离因为做了解耦，不同技术组合之后的选择比较多反，而没什么开箱即用的方案。不熟这一套的话，得慢慢迭代，慢慢优化。我自己用的这套迭代了五六年，每开一个新坑就调整一点结构。。

哦对，我把兼容性忘了。。我们搞部门内部的管理系统的，如果对方用的 ie 反而要被我们怼的 hhhh 。

你的目标用户要是用 win xp + 低版本 ie 的占比大的话，那就放弃 vue 跟 react，老老实实用原生 js 或者 jquery 吧。这种情况下实现前后端分离，其实也能做到，就是渲染数据比较折腾。

后台管理系统是很适合用前后端分离的模式来开发的。我之前参与过一个项目就是从 php 后端渲染，切换成前后端分离的（不过前端用的是 angularjs ）

拆分之后前后端只需要靠 API 和数据来交互，更容易理解，也方便分工。另外 vue 跟 react 的组件库也比较新，人手不足的话不用自己去造新轮子。
但既然你提到你不会前端，那还是得听听负责前端开发的同事的意见，负责干活的比较有发言权，如果他也想尝试，那就放开手去干。
现有团队比较熟 php 那套的话，那就直接基于原有的框架做 API 化的改造，一般只需要在 Controller 这层动刀子就行。再做个接口权限限制，再定个接口规范，就差不多了。