说实话这个标题可能比较欠扁。不过在这种辞旧迎新的气氛里还是觉得应该不吐不快吧。
从入职新公司到现在为止一年过去了，新公司的工作能发挥自己主观能动性的任务非常之少，除了年初在公司没有任何可用的垂直搜索方案的时候就自告奋勇地给自己部门搭了一套 es 集群，到年后将这个方案接入到公司公用的 binlog 信息流之中。再到后来为了接入方便开发了简单的 SQL 解析，以及工作时间处理各种集群查询、删除之类的操作导致的 OOM/GC 之类的问题啊什么的(感觉自己已经负责了不少运维的工作233)。其余的工作大多还是搬砖居多。
称之为搬砖一点都不为过吧，就是写写 CRUD ，写写 api ，然后和前端和其它系统和外部门的人来各种联调。
大公司么，总是会花多余的钱让稍微高级一些的人去干低级的事情。反正有钱。
话虽然是这么说，写写简单的 api ，过程也不是那么一帆风顺，比如你给前端提供了 api ，明确地写好了接口文档，列出了所有的可能情况，但前端在开发的时候还会来不停地骚扰你，这个怎么回事啊，这里怎么 bad request 了，那里怎么 param error 了。工作了四年的前端在调用别人的接口报错都自己不会自己去检查一下，就眼巴巴地指望着你去帮他找出问题所在。但是容不得吐槽呀，这是我们老大亲自招来的丰富经验的前端工程师啊。更何况还有其他的从做内核/大数据转来做 web 的又不是太愿意学习的工程师。年中绩效评定的时候，boss 跟我说，在公司里能够配给我的资源不会总是优秀的，但我挺想问问，这种老大招来的不靠谱的人给我们基层员工带来的痛苦，就是这么一句配给的资源不是最优秀的就可以一笔带过了么。
以下省略一万字吐槽。
嗯，因为公司的招聘流程不会允许你插手，所以你没有办法控制当前情境下的同事的技术水平。所以只能想一些别的办法来规避自己的痛苦了。本文如果是纯粹的吐槽也没啥意义，下面来说一些手段来减轻这种境遇下的痛苦吧。
情境一：
同事吐槽说，你的接口有问题吧，我怎么调用报错了，我的调用代码明明没有写错的，要不你来帮我看看我的代码。
如果提出这个请求的是一个菜鸟工程师，在 web 开发方面经验不足，那么尽量帮一帮他，告诉他什么是正确的写法，并且告诉他通过哪些渠道能够补齐自己欠缺的知识。当然了，如果这位同学下次没有动脑子又来问同样的问题。就谎称暂时忙，没空帮忙。
如果提出这个要求的是一个所谓的有丰富经验的工程师怎么办呢？把 http://httpbin.org 扔给他，再把自己的 demo caller 扔给他，让他自己去对比 http request head/body。如果这样对方还是搞不明白门道，拜托，你是怎么成为我的同事的。
情境二：
接口的用户分不清楚 http 的 form post 和 json post 有什么区别，而且他用了一种你也不会的语言，你没法帮他调试代码。但是他又声称自己不会改，之前只用过这一种post方式，你写的接口太麻烦，赶紧改。
碰上这样的同事真是想大嘴巴抽丫的啊。。但是没办法，为了饭碗还是不能发作对不对。这里我们也有办法。当然了，这里的办法仅仅针对比较简单的接口。我们可以同时提供 form post 和 json post 的双重兼容。这件事情在php里做着最方便，下面给一个php的例子：
<?php
func parse() {
$http_body = file_get_contents("php://input");
$http_body_arr = json_decode($http_body, true);
$_POST = array_merge($_POST, $http_body_arr);
}
这样就可以同时兼容普通的http请求和json post了~
此外，项目应该尽早引入 swagger 之类的 api 管理工具，和数据 mock 工具，这也是前后分离、契约编程的精神。能够最大程度地降低沟通成本。何乐不为。
情境三：
前端同学说，我靠我这个ajax上报数据为什么不稳定，有时候能拿到用户信息有时候拿不到。
其实我是不想帮前端去查前端自己的bug的，不过还是从了吧。
前端的ajax请求一般情况下是异步请求，很多人会在document.ready之后再进行ajax调用。不过纯异步的ajax有一个问题，例如前端写了一个ajax调用获取用户信息，然后将用户信息渲染到了页面的某个<div>里，而现在新的业务逻辑希望能够在页面ready的时候把这个用户的信息上报到api。有些前端程序员可能会直接在ajax的代码里去读取div的text/html，然后把内容上报到后端去。这样的话有什么问题呢？
这其实是一个很常识性的错误，ajax本身是异步执行，所以在你的代码里执行：
ajax_a();
ajax_b();
虽然执行有先后，但success和fail并不一定总是同时完成的，比如你ajax_a调用的接口本身就比较慢啊什么的。
这种时候如果你ajax_b里还依赖于ajax_a中返回的数据，那么就不能像上面例子中这样去写代码了。
比较老式的处理方式是：
ajax_a() {
success: {
ajax_b();
}
}
看着似乎也不麻烦？这只是个简单的例子，如果我需要 ajax_a => ajax_b => ajax_c 这样的执行顺序呢？或者更加复杂一些的呢？
例如：
ajax_a
||
// \\
ajax_b ajax_c
\\ //
ajax_d
||
// \\
ajax_e ajax_f
\\ //
final_handler
这年头前端的业务逻辑也确实会有这么复杂的，不是以前那样吐个数据彼此没关系就完事了。
这样的数据依赖如果你用传统的ajax写法的话肯定会蛋疼地紧，好在js现在已经解决了这个问题，感兴趣的同学可以去看一下 promise。
不过我比较怀疑我们这里的前端猴年马月才能知道什么是 promise。
总结
作为一个后端程序员，http 协议的基础一定要过关。对于常见的错误码要烂熟于心，除了谁都知道的 404，500，502，504，302，304 之外，还有一些框架里自己定制的错误码，例如你看到一个系统的接口返回了 400 bad request 或者415 bad media type，那这个系统很可能就是一个 java 系统。。而这代表你的请求在某个地方有着数据结构上的错误，或者你的 http 头里没有本来应该有的 Content-Type 而导致后端不能够正确识别请求。此外可能还有 http 499，客户端主动关闭连接，这种情况下你自己的后端日志上实际上是看不到任何返回的。要定位问题的话，可能就只能从端上来做了~
能控制招人的话一定不要给自己的团队招猪队友。
