@3dwelcome 这应该是国内大多数中小型公司的常态，我们都知道有些事情是对的，但是却往往被情感左右。说到底一个人都不完美，更何况一个群体了。

所以尽管工作氛围不尽如人意，但是决定我们自身如何的还是我们自己。工作沟通上保持积极，认真做好自己的工作，专注和坚持从来都不容易，真的是需要长久的磨练的。有点鸡汤的味道了，祝你能够踏上自己所想的那条路。

CRUD 也是有讲究的，你看，实际上就两种操作，一种是修改，一种是查询。
简单的 CRUD 从前端到后端甚至数据库字段都完全一致，就是面向数据库编程，Service 都不需要。

复杂一点的，把这两种操作当成两套代码来写：

修改操作多以动词命名，会精炼出业务的实际需要的操作列表，把他们全部放在 Service 里面，每一个方法就是一个事务，或者使用门面模式封装独立的命令执行（命令模式）。

查询操作完全取决于你的消费方需要什么样的数据，把查询的逻辑处理全部放到 Repository 里面，返回 View 或者 DTO 啥的，只专注于如何批量查询并组合成需要的数据，可以是 SQL，可以是 HTTP 请求。很多人喜欢把查询也放到 Service 中，但实际上两者的关注点是不一样的。

读写分离以后好处是显而易见的，查询和修改都可以单独进行优化，最重要的是更加清晰可读。
当然以上只是一种方法，从技术上来讲，写业务代码最大的难度和关键点在于需求是否足够清晰，领域知识是否完备。反之造轮子则不需要这些额外的知识，但终究来讲轮子也是服务于某一个技术点的，最终也是要服务于业务的。

帧同步需要客户端计算结果严格一致，不然就会走偏，服务端在一局的游戏中只扮演数据转发的角色。

如果只是想要知道如何使用，则不必关心背后的算法，只需要学习一些使用案例，在不同的场景下使用不同的算法。
当然如果是专业搞数据信息安全这一块那就厉害了，起码数学功底要够硬。

不要自己去创造加密算法。
不要自己去设计加密算法。
不要自己去实现加密算法。

除非你知道自己在做什么。