前几天看到某技术论坛一些帖子的相关话题，有一些自己的想法，当然自身也是经历过的，随便写写。
对于刚工作的小伙来说，进入一家公司，如果是那种基础架构部门那么可能涉及业务的机会不是很多，比如我第一份工作是大数据相关的，那会需要参与到后台架构的设计，业务的开发。我那会基础还可以，但对于架构是没经验的，而且部门的新业务没有适合的可行经过线上验证过的方案，所以只能从零开始，不过这个项目早期是内部需求，不需要多大的并发量这种。
后来了解大数据相关的技术，包括hadoop，hbase，负载均衡技术等，当然那会自己感觉是挺感兴趣的，就查看了下hbase的一些源码和负载均衡的一些实现，不过现在肯定不会了。后来开始写业务需求，需求不是复杂，不过让我思考到一些业务之外的东西，那就是如果让我接触过一个陌生的东西，我如何能解决它？可能这一方面要了解相关的技术，还需要在某种程度上知道怎么个回事，包括原理，出问题知道怎么弄等，可能这些在工作中是没有机会或者说没有场景让你去了解内部实现。
后来从事游戏后台的开发，工作这几年，游戏的类型相对固定，使用过几种框架，各有缺点。都是从当时的背景因素下决定的，这里不再多说。并不会因为后台框架的选择不同导致游戏能不能顺利上线。有些类型的游戏比如mmo这种框架足够应付，而对于其他的可能不行，只能出于游戏的类型去选择，当然这些是需要知道的。
比如游戏中的一个随机权重区间算法出宝箱，有100个区间，不会因为你选择使用容易理解的O(N)算法或者很难理解的O(logN)而成功，可能后者效率更高，但这里的业务是低频和量级很小的那种，所以使用前者足够。当然，如果你知道可能更好，后期如果profile时发现有问题可以及时更新。
技术还是为项目和产品服务的，当然技术很重要，因为从一个业务切到另一个，可能不一样，但技术方面可以相通，不过这里的技术比较笼统。比如可以作为面试官拿来考候选人的点，因为你面业务对方可能不熟悉。有些技术可以在某些方面深入和发现潜在的问题，这些跟业务不相关。
有的时候，写业务需求，只是堆逻辑代码，对于我所熟悉的游戏来说，有复杂度的除了固定那几项，其他的都是比较容易完成，当然最后结果怎么样，感觉这部分的稳定性和正确性很重要。如果在工作之外，看过一些好的设计思路，也是可以用到当前的项目中的。
