”我热爱的是做游戏，相对于玩游戏，我知道这两者的差别 …“
这，是我来北京找工作，面试时自我介绍的开头。
不知不觉，已经工作五年，经历了三家公司，做过五六个项目，一步步，算是摸爬滚打的过来了。
聊聊过去，聊聊自己。
启蒙
上大学前，并没有接触过编程。
仅有的经验只是金山打字通的打字练习、做PPT，管管教室电脑（就是开关机）；噢，当然还有打游戏。
大一初识C++，经典的谭浩强老师的 《C++程序设计(第二版)》，拿着忘了从哪蹭的100道经典C++练习题，一顿猛敲。
大二，就拉了个团队去做个游戏，学了点C++的皮毛，就准备撸起袖子大干一场，正好有个齐鲁软件大赛，正好有个手机游戏项目，正好就拉了几个人，一个暑假都在学校奋斗，还好，没有半途而废，算是一个完整的游戏吧？。。
后来，加入仰慕已久的ACM实验室，开始撸题。
后来，没有考研，决定就业。
…
感悟
游戏开发
从第一份工作到现在一直是在做手机游戏，一直用的是Cocos2d引擎来开发，有接触了解，也做过一些Creator、Unity的Demo，但真正工业级的项目没有碰过。
在我所经历过的各家公司，也各有特色与偏重，没有同质性的公司。
我目前的理解，做游戏（仅客户端而论），可以先大概分为两部分：
- 游戏；每一行代码都能在游戏中体现，为游戏内容品质服务。
- 基础组件
- 中间件
- 业务功能
- 产品；项目从立项到上线，所额外负责的工作。
- 版本控制
- 打包、SDK接入
- 跨平台扩展
- 更新机制
- 游戏优化
- 统计反馈
- 测试支持
游戏
游戏开发中，所做的每个改动，都可以在游戏中直接表现出来。
我把游戏分为三个部分，各部分所重视的角度不同：
- 基础组件；基础组成部分，一般涉及到自研底层代码及引擎底层代码，相对重视效率与性能。
- 中间件；为业务功能研发做中间转接口，将基础组件拼接组装或封装调整，相对重视通用性及便携性。
- 业务功能；实现各种需求，直面用户，相对重视灵活性。
在开发的时候，明确并了解所开发的模块属于哪个部分，从而知晓它的重点偏向。
比如，开发业务功能，更重视灵活性，多与需求方沟通，了解他们的本意，不要厌恶、恐惧变化，甚至要拥抱变化，以 “任它需求千万变，不如我代码灵活又简便” 为目标。
再比如，如果开发基础组件，理论上，不应该为了使用方便，而去牺牲它的执行效率。
产品
这部分可能跟游戏的实际开发无关，但是却是完整的产品必经之路。
这些部分或许与游戏的品质等无直接相关，但是会直接影响团队的研发效率。就如同产品与包装的关系，包装不代表产品品质，但是好的包装亦能影响用户心中的价值。要不然，月饼、白酒的包装会越来越华丽呢？
这部分的特点是 简单繁琐 、 涉及广度大 、一次就好。
- 简单繁琐；很多简单且繁琐的事情，相对于技术可能更考究细心与耐心。
- 涉及广度大；一般涉及的范围很大，虽不至于天文地理，但也基本和项目的开发截然不同。
- 一次就好；基本实现一次就好，不需要频繁迭代维护，甚至不维护。
这些特点，导致这部分的内容，更像一个苦差事。但随着各种自动化工具、集成工具的发展，完全可以把这些内容脚本化，进而可视化、自动化，慢慢的就会找到这部分的乐趣，能把一堆繁琐的东西理的井井有条，还是很有成就感的。
有一点要谨记，做好文档，做好规范。
软技能
很多行业慢慢由增量时代转入存量时代，做开发亦是如此。
由于模块拆分的越来越细，第三方的服务越来越多广泛且专业，导致开发一个产品的门槛越来越低。
不能再像以前那样，闷头只钻研技术，而忽视软技能的发展。我不否认依旧有很多硬靠技术吃饭的人，但我知道，我不是。
技术&软技能，就像一块木板的长和宽；最终拼的是面积，而不是单纯的长或单纯的宽。但不要因噎废食，过于注重软技能而忽视技术；要做的是以技术为基础核心，同时也注重软技能的发展。
沟通
沟通是一门很大的学问。
小的来说，沟通可以简单分为：
- 向上沟通
- 向上级汇报
- 向下沟通
- 向下级安排任务
- 跨界沟通
- 向其他部门咨询或请求援助
其实，不仅仅是说话，所写的文档、代码等，也都可以算是沟通的一部分。
沟通的目标是让别人理解你的观点，或者是理解别人所表达的内容。无论哪一个方面，都需要换位思考，并且有事直问，不要妄加揣测。
主人翁
全心全意去做当前所做的项目。（我可没说把公司当成自己的家。不一样吗？你品，你细品！)
不要只做自己该做的，剩下的高高挂起。
原因如下：
- 早晚都要自己带团队做产品，与其到时抓破头皮，不如早做准备。
- 看的越多越仔细，会发现一些不曾注意到的细节，都是知识，都是财富。
- 有时候，编程也是门经验学科，有很多坑早晚都要踩过一遍就知道，踩得越晚，坑越深。
- 给上级一个让你晋升的理由。
在开始，大家都是消费者，但可以慢慢成为一名生产者，产出对团队有利，对自己又何尝不是。
一方的利益获得不一定伴随着另一方的利益损失，世界上有很多多赢的事情，只要利益的获得满足自己的预期即可。
体会一句话：你可能血赚，但我绝对不亏。
一个咖啡杯的故事
真人真事，在一个早上，我去便利蜂买杯咖啡，它们就是那种自助咖啡机，排在我前面的人，并没有放置咖啡杯，就开始扫码结算，这时我可以
- 提醒他，让他先放杯子。
- 不提醒他，让他自生自灭。
选择不提醒，最好的结果是，机器检测到没有放咖啡杯，然后提示放咖啡杯；最坏的结果是，机器直接出咖啡，客人手忙脚乱拿咖啡杯去硬放，烫伤自己，然后…。
选择提醒，就一句话的事情，可以避免很多事情；即使对我自己而言，也节省了我的时间，否则按最坏打算，我的这杯咖啡，什么时候能拿到呢。
其实，这个现象就跟团队内的合作沟通一样，很多东西提前通知，做好预备，往往一句话的事情，可以其他人很多的弯路，对整个项目而言，必然有利而无害的。
方向
工作这些年，早期，基本花了很多的时间花在摸索上，更多的关注在如何做一个完整的项目，也就是俗话中的深度和广度中的广度。
现在，对这一行有了大概的认知与理解，更需要的是去进阶一些深一层的东西。就像之前的策略 以技术为主，软技能为辅的发展一样，在技术中也要找到一个专精领域，再以其他领域为辅去进行进一步的发展。
然后，技术上很多东西是相同的，没有必要把自己局限于某个角色，在不同的角度思考问题，会发现不同的内容。
最后，依旧是那句话，屁股决定脑袋。所在的位置，利益诉求，会影响信息、判断与决定，每个人的阅历、想法不尽相同，不需要逼迫着所有人 思想的统一、行为的统一。
准则
专业的事情交给专业的人，简单繁琐的事情交给脚本，留出时间做重要且核心的事。
目标
不做总线，做一个被自己替代的人。
总线，是必不可少的组件；它的阻塞会导致系统无法运行。
但有的时候，有些总线就没必要存在。
一个例子：
之前在生成 Android包及热更的时候，必须由开发来执行。
大概流程是这样的：
- A想要包测试内容
- 告知开发出包
- 开发出包完成，交给A
这样有诸多弊端：
- 出包占用开发电脑资源，影响开发原有功能开发
- 由于出包不便，必然会减少出包测试的请求，整体上讲对项目不利
- 期间有多个交接口，无法查进度，隐性所需时间拉长。（比如A告知开发出包，开发是否立马去出包，或者忘记出包等）
- 在忙碌的时候，手抖导致出包错误，重新出包
- 等等
这个流程中，开发就是总线，但是这个总线是必要的吗？显然不是。
于是，采用一些方法去把总线替换掉：
- 将出包相关脚本化、自动化
- 使用Jenkins实现接口暴露及工作空间共享
这样，出包的流程变为：
- A想要包测试内容，登录内网jenkins地址，根据需求出包
- jenkins出包
- A从jenkins空间中拿包
这样，开发从这个流程脱离出来，并且对于A有更多的配置选项可以配置，更为便捷，同时，出包进度也可视化，更有利于减少隐性时间消耗。
当然，这只是简单的一步，为了让它更加可靠且易用，必然要经历大量测试并且有一些预警机制，每隔一段时间进行使用者的反馈来扩展功能。
这只是简单的关于总线的例子，其实很多东西，都是表面上的总线，就如同那句话：
世界正在变得越来越自动化。因此我认为，并非每个人都需要学习编程，而是每个人都需要学习和理解如何实现自动化。—— 《Don’t Learn to Code — Learn to Automate》
未来
未来，谁都不知道会怎么样。
能做的就是总结过去经验，把握当下。
确定长目标与短目标，以一年或关键时间点为期，进行总结，看是否在既定的路上前进。
重视并珍惜每一个机会，每一个项目，只有在总结的时候才去考虑收益的事，剩下的期间全心全意的去做事。
多想多讨论多实践多总结，步入一个良性的循环。
然后，多读书，保持健康。
引用内容：