因为很多公司对架构师的要求不只是架构师，更是 TL 。
TL 要做什么？攻克技术难题。
那大部分公司都用什么技术？ Java 。

你这种情况属于主干开发，分支发布。
发布分支上发现了 bug，在发布分支上修复，并遴选到主干上。
#33 有 conflict 应该尽早处理，等你过了几个星期开发完 dev 分支，估计都忘了那个 test-bug 了。

前面有人提到 git flow，其实你的 test 分支相当于线上分支，以这样的视角参考 git flow 。

safari 和 firefox，看油管偶尔会卡死，卡死只能重启整个浏览器，我一堆标签每次重启都很痛苦。
chrome 就没出现过问题。难道传闻谷歌故意给其他浏览器做负优化是真的？

让他们 Java 程序发起请求，你这边抓 handshake 包看看啊

之前出国在 Hertz 上租车，会员积分用 points

对向移动，可以理解成一边静止，另一边单向移动。这样问题是不是变得更简单了？

关键问题在 HR，HR 不 care 面试者有没有白跑一趟，HR 的工作目标是要完成业务部门的招聘任务，只要业务部门要求面试者来现场面试，HR 就要想方设法吸引面试者过来。

所以 HR 习惯性彩虹屁，提高面试者预期，至于面试者白跑一趟嘛，有啥影响？报销路费也是花公司的钱。

如果一个软甲只加代码不修改，是几乎不会出错的。接口也一样，不存在修改接口，只有加接口，用 /v1/xxx /v2/xxx 去区分。

@barrysn 所以答案不是很明显么？业务变更没有规范或不遵守规范

我比较好奇为什么致命告警总是半夜两三点爆发，而早上的却很少听说？
半夜两三点流量特别大？早上却很小？

@lsk569937453 所以你是希望研发都用官方的 SDK，然后你截获官方 SDK 发出的请求，做了一些 hack 的事情（例如染色？数据抽取？路由？），再转发出去？
这里 tcp 栈的消耗相对于你的 hack 的消耗可能不值一提？
如果只是做数据抽取，抓包会不会更好
如果是改数据包，你的序列化的操作可能才是瓶颈
如果是路由，有很多现成的中间件啊

@lsk569937453 这个跟 service mesh 中的 sidecar 不是一回事，你这个操作是把包组件（ sdk 组件）封装成服务。如果你只是把 redis，数据的 tcp 协议封装成 http 协议，意义不大。

不就是把进程内调用改成 RPC 吗？

今天才思考过这个问题，看你在哪个方面看，如果是收入角度，那么和我以下说的无关。毕竟行行出状元嘛。

做底层架构开发，其实很类似搞科研，在某一个技术领域钻研，钻精。你的圈子可能会越来越小，毕竟你成为了那几个拔尖的人才，简单来说就是深度发展。

做业务开发，相对来说会提高涉猎面，你有可能往业务架构发展，往产品，售前，销售等业务线发展，接触的人或者社交圈子相对较大。简单来说就是广度发展。


不过也没有绝对的，做业务开发，不关心业务，只守着一亩三分田，也不会广度发展的。做底层开发，时间安排得好，社交圈子也可以扩大的。

没有这些知识，你连论文都看不懂，更别说实现了。

你以为那些二维码 lib 天生就存在的吗？还不是人写的，为什么那个人不可以是你自己？

？？？
是我理解错题目了？
难道不是在一个 10W 个元素的数组中，把第 10 个元素移动到第 5 个元素的位置吗？那么只要重排 5~10 位置上的元素就可以啦。跟第 11，12，13，第 10 万的元素有什么关系呢？时间复杂度就是元素移动的距离。
好像还有置顶和置尾功能？用标记就好啦，查询的时候用 where 过滤一下。

越看评论越觉得我弱智了，是我理解错了吗？

@raysonlu 怎么会呢？
假设你当前页有十条数据，你现在把第 7 条数据拖到第 4 条数据前，那么需要变更的数据有 D，E，F，G：
1 A--A
2 B--B
3 C--C
4 D--G
5 E--D
6 F--E
7 G--F
8 H--H
9 I--I
10 J--J

所以结合场景，如果你一页所展示的数据大小为 100 条数据，那么最坏的情况下，你要变更 100 条数据，无论你的总量是多少。
但如果你支持跨页拖拽，你就当我没说。

你拖拽的跨度有多大？
假设你一个页面有一百条数据，那么每次拖拽用交换排序，最多更新一百条数据的索引值。

select * 不是一个好习惯