在DJ的日子

时光荏苒，转眼到DJ已快三个年头，自认为这是我收获最多的一家公司，特此记之。

工作氛围

DJ整体工作节奏还是比较轻松的，基本上不加班，小团队，组织结构简单，没有多少办公室政治。

从产品定位上，由于早年定位于社交招聘导致使用DJ的大部分是学生应届生，这一定位导致DJ社招相对薄弱，最终让雇主对DJ的社招可能缺乏一些认同，再加上一些垂直招聘网站lg，boss等后起之秀，DJ的处境确实不是那么乐观。

在技术架构上，除早期遗留项目，Web主框架已经全面迁移到SpringMvc。服务层采用的是基于Dubbo的微服务架构，消息组件为RocketMq，配合Worker和定时任务进行异步任务的处理。存储这一块主要是主从 Mysql 集群配合 Redis 集群作缓存，Orm为业界流行的轻量级框架ibatis，去年已经升级为Mybatis。早年基于配置文件对项目进行管理，升级维护异常麻烦，后来由基于ZK的配置管理中心接管，持续集成为Jenkins和Maven包。这就是DJ后端的技术栈，希望能给有志于来DJ的人一些参考。

完成工作

回顾这三年，印象比较深刻的工作如下：

• lp网验证码破解
• 邀约服务id更换
• 基础服务拆分
• 延时队列
• Maven包依赖查询工具
• 应对XSS攻击，添加CSP头
• 搭建现金支付、订单管理架构

剩下的大部分时间都是业务开发。

心得体会

第一是要遵循一定的规则。这一条相信大家都听腻了，各种规范、最佳实践等等都是在教大家遵循一定的规则，这里我就不再赘述了。我想强调的是第二点。

第二是有时候要勇于打破规则。或许是遵循规则强调的太多了，有时候都忘了打破规则。一味地遵循规则可能会给自己或他人带来大麻烦，而打破规则往往能另辟新径。举个例子，我在基础服务拆分的时候就遇到了这个问题。我们的SOA架构基于Dubbo，一个完整的服务包括api、client和service三个包，api里主要是一些model类、枚举和服务接口，client里只有一个非常轻量的consumer配置文件，service是dubbo服务的真正的提供者，这样一个工程如果依赖服务，只需要引入api和client包即可。为了降低服务之间的耦合性，以及Maven包循环依赖的可能性，api和client里不允许引用其他服务的api和client，因为B的service里有可能依赖A的client，如果A的client里可以引入B的client，B的service就引入了自身的client，这样就会报错。一个平常非常好的规则在服务拆分的时候就造成了大麻烦，比如服务A和B分别拆出来一部分服务到C，C是一个新的服务，那么如果一个工程依赖原来的A中的服务，现在挪到C中了，那么工程就需要将C的api和client包引进来，如果拆出来服务很多，这势必会给原来服务的使用者造成很大的麻烦，因为他需要pom文件加入很多新的api和client依赖，这个时候就要变通一下，打破这种规则，这样对原来服务的使用者就完全透明了。在工程上这通常称为“白名单”。

第三是要有主人翁心态。现在经常可以在职位要求中有那么一些词：“良好的沟通技能”、“自驱动”、“责任心”等等，其实本质上是一种主人翁心态的养成，上面那些词都是这种心态的外在表现。一个简单的道理，你给别人干活不愿意干，给自己干有不愿意干的吗？给自己干你会不自驱动吗，会没有责任心吗？说了那么多，那如何养成呢？首先从个人要抛弃“我给公司打工，干好干差反正都不是我的，差不多得了”这种心态，这可不是给你灌鸡汤啊，有人可能会说凭什么呀，凭长远来看这对你自己是一种提升，比如你干一个活你自认为达到了70分，如果要达到80甚至90分，你可能就要开动脑筋费一些精力，这个过程中你可能会学到一些以前没有接触的东西，很明显你的能力提升了。但是如果你坚持上面的那种心态得过且过，虽然暂时轻松了，但错过了提升自己的机会；另一方面公司要从文化上进行引导，还要建立合理的奖惩机制，毕竟“名利”总得有一样吧，大家都是现实的人。

第四是无论自己干活还是安排别人干活一定要有明确的时间节点。这话什么意思呢？比如在生活中我们经常和朋友说这话的话：“找个时间大家聚一下啊”，这种多半聚不成，因为没有明确的时间地点。在生活中这么说还有情可原，在工作中这么说就会造成大家不知道往哪里使劲。有时候不形成书面的时间点，光是在心里那么一想有时候都大有改观。比如当初学习Coursera上的机器学习课程，也没啥计划，刚开始挺好一周学完一节，最后虎头蛇尾不了了之。上年又准备拿起来，当时正好快放假了，定的目标是放假前学完，最终只用了18天（2018.12.30-2019.1.17）。

第五是勿以“量变”而不做。有时候对于一个问题暂时没有从本质上解决它的办法，这个时候难道什么也不做了吗？不是，其实你可以做一些工作从量上对它进行改变。比如支付这一块当时技术调研，如果引入分布式事务对现有架构冲击较大，而且无论是两阶段提交还是Try-Commit-Cancel这种模式都无法100%保证事务一致性，最终做了妥协，采用消息、定时任务以及人工来保证支付数据的最终一致性。从运行到现在的结果来看，数据不一致的情况非常少，有的话大部分情况下消息和定时任务可以自动处理，只有极少数才需要人工参与。这就是一个只在“量”上解决问题的例子。

第六是当你觉得比较舒适甚至懒散的时候就该到新的环境中去了。记得以前换工作面试官经常问的一个问题是为啥要离职，当时都会说想学习一些新的东西。后来转念一想，你想学习新东西老的公司也可以啊。实际上，无论在哪里，如果你想学，新东西总会有。真正想到一个新环境中去是因为老的环境已经挺熟悉了，什么都见怪不怪，什么都习惯了，到达了一个比较舒服的状态，也就是俗话中的有点“皮”了。有人说我不会，无论在一个环境中待多久我都是一种处子的心态，好我敬你是条汉子，你牛！还有一个更重要的原因是新环境会拓宽你的视野增长你的见识。举个简单的例子，我上家公司是一个做政府项目的公司，他们的架构是公司内部打war包，分发到各地部署，你可能觉得很low，但这确实是适合他们的架构，因为政府的一些系统不允许连接外网，没法进行远程部署。假如不来DJ，我不会见识到互联网公司的一种技术架构，反过来更全面的看原来公司的架构方式。举个不恰当的例子，当你没听过原子弹的时候，你可能抱着炮弹沾沾自喜，当你听过原子弹，仅仅是知道有原子弹这回事，都足以让你做出很多改变，比如你自然而然的会想别人用原子弹我改怎么应对，我要不要造，我能不能造，如何造……等等。

最后，感谢DJ给我这样成长的机会，感谢hy、dd、wx、mg等的帮助。