[ 北京 ] 滴滴出行招聘代码拯救师

[taowen]

[ 北京 ] 滴滴出行招聘代码拯救师

你没有看错，职位的名称就叫 代码拯救师 。

月薪： 40k+

工作地点：北京上地

谁都知道这不是一个招人的好时候，年终奖正朝我们迎面走来。但是只要你认为你能够接受下面的挑战，待遇问题都是可以谈的。

希望即将归队的你有这样气质：

• 我们现有的架构 API <-> DB <-> MIS 。前台 API 有 20 万行代码，后台 MIS 有 20 万行代码。你的任务是把这些代码拆解出“出行流程”，“账单”，“支付”，“地面网点”等 Micro service 。类似的事情 Twitter 等公司都干过： http://conferences.oreilly.com/software-architecture/sa2015/public/schedule/detail/40363
• 追求自身价值。太多优秀的码农在做然并卵的事情了。对于 CMS 类的小破网站，天天 DDD 来， TDD 去，浪费青春和生命。我们希望你对商业价值敏感，对于自身成就敏感。你所拯救的代码正在改变数亿中国人的出行方式，我们确保你最终收获的不仅仅是诗一样代码带来的愉悦感，而且会真正感觉到自己在做 something matters 。
• 能够和代码洁癖狂愉快共事。我们的主力码农毕业于国内对代码质量最有追求的两大黄埔军校，豆瓣和 ThoughtWorks 。希望你能够忍受 Code Review 时的 WTF ，并能化悲愤为动力。我们的架构师之前是百度的 T9 专家，百度 90%的服务器上都跑着他的代码。
• 不认为自己是 C++/Java/Python/xxx Developer ，不以擅长某种语言做为求职目标
• 最低要求：可以现场用键盘表演纯快捷键的 Refactoring Kata

需要更多信息，请联系： [e-mail]

[canesten]

相关的软件基础设施完备吗？
比如 MQ ， Zookeeper ， Dubbo 或者 Docker 什么的？
涉及到基础设施改革的问题有决策权吗？
40 万行代码，读代码，熟悉业务能给多长时间？
这个岗位并不是一个持续需求的岗位，弄干净以后如何保证不会发生卸磨杀驴的事情？
这个岗位要招多少个人？每个平级的代码拯救师之间的分歧要如何解决？
除了解耦归纳以外，性能考量要做吗？
如果涉及到为了性能做出的架构改革或者基础设施改革有话语权吗？

[snow4young]

一语中的：对于 CMS 类的小破网站，天天 DDD 来， TDD 去，浪费青春和生命。

[xufang]

慎如此坑，左耳朵耗子就是前车之鉴。
大概率成为牺牲品，没有百万年薪，不要动心。

[otbzi]

@canesten 跟我一块儿干就好了。什么都 ready 了，还要我们干什么？

[whistle]

千万不要去，滴滴据说天天空降领导，基本上苦哈哈加班把活干完了，就可以把你边缘化了

[canesten]

@whistle 有同感
百度的 T9 和 TW 的人不是创始团队的吧？
如果是一开始就让这两股人来干，一定不会导致现在需要大规模重构的情况吧？
百度的 T9 和 TW 两个正规军的人都没把这重构搞定，难题在哪？
我觉得不是技术和经验吧？
如果公司内的 CTO 或者 Tech Leader 这种活会干又没干，那是不是有点吃干饭的嫌疑？
还是不愿意背锅？
那愿意背锅干活的人是不是应该比这些不敢背锅的人赚的更多一些？
名利不可兼得嘛，那些已经有了名的虚职高管可以少拿一些钱吧？

[BenX]

我觉得这个贴要火，先 mark

[canesten]

@BenX
我觉得这贴不会火，今天是周六， V 站上活跃人数减少很多的。
而且楼主也不来回帖，可能明天就沉了，不会有几个人看到。

[viperchaos]

@canesten 我感觉要火

[itbeihe]

感觉会火，加一把火柴。

[professorz]

先是觉得这帖子逼格真高，看了几个楼发现回帖真犀利！

[Email]

初级菜逼工程师写的代码.招高级工程师去重构.

[wuranbo]

火钳刘明

[wuranbo]

@Email 主要是自己矛盾阿。承认一边就行了滴滴都占理，因为毕竟产品的成果在那里。

[canesten]

@otbzi
贵司是做什么业务的？

[freeindex]

刘明

[Knights]

这么多代码要重构，谁去写会疯掉的吧。

[ianisme]

是该拯救了 bug 太低级了

[wh0syourda66y]

还不如彻底重写，我们公司也碰到这种坑，浪费了大半年结果一点用也没有

[hantsy]

MicroService 与 DevOps 不可分割， DevOps 跟不上，是白搭，试想如果有 Netflix 那样服务超过 200 的时候怎么部署。

滴滴也就这一两年的事，从一开始设计就应该考虑服务分离。

在没这 MicroService 这个概念，我那时的项目(37 个 maven modules, 7 个部署包)已经做最基本的考虑：

1. Restful API, 符合 Richardson mature model Level 2
2. 批处理服务分离，主要用到 Spring Integration ， Batch ， AMQP 等，使用 AMQP 与 API 交互
3. 通知分离（邮件，推送等）
4. UI 全部是 SPA （网站， APP 使用了 IONIC ）

这都是一年前的架构方面的考虑了。

现在的新项目完全采用 Spring Cloud, 特别是 Netflix （ MicroService 的成功典范） 的集成。

1. Ops 上更新换代（ AWS ， Circle CI ， Docker ， Vagrant vault ， ELK ）
2. Restful API 符合 Richardson mature model Level 3
3. API 更细，也进行分离，使用 Zuul 代理
4. Service Discovery, Load Balance, API Gateway/Aggregate 基本上都是用 Netflix 技术， Logging trace （ Spring cloud sleuth ）等