前面写过一篇中间件与责任链模式，最近被同事揪出来打了脸，感觉有必要再做一次学习和分析，下面就是新的学习成果～
中间件
让我们从例子开始，我们发现网站的评论系统中有人恶意进行xss攻击，因此想要对用户的请求做简单的xss过滤，简单地来做的话可以对所有用户提交内容中的尖括号
进行过滤。那么可以完成形如下面的函数：
// input = `script>`
func XSSClean(input string) {
input = strings.Replace(a, `<`, `[filtered]`, -1)
input = strings.Replace(a, `>`, `[filtered]`, -1)
}
把这个函数封装进我们自己的utils包中，在业务层需要进行xss过滤的时候只要使用XSSClean函数对输入字符串进行处理即可。
这些问题来自于github项目：
> https://github.com/monklof/Back-End-Developer-Interview-Questions
我整理了一些自己的答案，之后要是有想法了大概会陆陆续续更新吧(大概
说明
这篇文章翻译自一位外国友人的关于面试后端程序员的文章，我比较喜爱这篇文章。一是因为它极大的拓宽了我的视角，另一方面是其中的一些问题非常具有启发性。不仅对于面试者，对于面试官来说也是个不错的参考。于是迫不及待的翻译了一下，给各位看官做个参考。
这篇文章中，许多问题我并没有完全理解，所以翻译可能存在不准确的地方。如果有读者发现有一些翻译有误或者不好的地方，请不吝赐教。
原文参见 @arialdomartini [https://github.com/arialdomartini]的: Back-End Developer
Interview
最近公司迁移机房，不知道为何用google
authenticator来做验证。这下直接导致我们在这个公司有三种形式的token。。。实体token、宁盾和ga。真够麻烦。
不过迁移机房之后至少我们可以不用登陆windows
server来做跳板，所有过程在终端完成。那么就可以直接用expect脚本来实现自动化了。问题就剩下怎么生成这个随时会变的token。
去github上找了找，结果发现离线生成ga的token竟然是可行的。这点和我当初想的不太一样。之前道听途说，token在服务端和客户端都用了非常牛逼的加密算法，所以才导致其破解不了。但实际上看来加密算法竟然是可以直接公开的。。对于这种算法而言，必须的条件就只有一个，就是分发给你的独一无二的key。用这个key在服务端和client端每30s进行一次计算，然后就可以得到一个六位数字，关心具体算法的可以看这里：
> https://github.com/cch123/googleAuthenticator
两边进行匹配即可。而在服务端识别key和用户身份则是通过当初把这个key分发到哪一个账户下了，也就是把key发给了哪一
elastic官方为了统一混乱不堪的技术栈版本号直接来了个大跃进，把logstash/kibana/elasticsearch之类的东西统统变成5.0。
说起来我们用es也有一段时间了，感觉一路用下来总结的话，最坑的还是数据同步和各种深度翻页导致的full
gc问题。再回头看看当初在博客上写的es相关的文章，感觉真是水orz，哪天有闲就删掉吧。。
这次升级5.0，官方把原来的marvel搭配了几方新药(security、alerting、graph等)作为一个新的组件x-pack进行发布。如果想要用x-pack的话，需要在es和kibana里分别用plugin进行安装。然后，因为穷逼们付不起一年好多好多刀的license，所以可以用最简单的free
license凑乎一下。free license里只包括了monitoring，其实就是以前的marvel了吧。
要说对于使用方最大的变化嘛，就是什么head、kopf之类的插件这次全都不能用了。。。。官方表示site plugin有安全性问题，
最近接手其他人做的项目，导致之前的一些幻想破灭了。因为刚工作的时候做项目是php，而php本身的web框架一般只简单区分mvc，稍微麻烦一些的会多个library或者helper之类的。这样分层很少有优点同时也有缺点。当然了，现代的框架一般支持namespace，你也完全可以借鉴其它语言来做自己的内部框架。这里先不说这个。
mvc的优点自然是简单，无论一个新人有没有做过相关的工作，你只要跟他简单说明每一层的职责是什么，马上就可以开始工作。缺点也非常明显，因为太简单，所以代码在累积到一定量以后会变得难以控制复杂度。同时容易让没什么经验的程序员把代码写得难以维护。
所以之前听说java的框架这方面做得好一些，然后对部门的java项目抱有一些幻想。不过在实际接手后，发现理想和现实真是有比较巨大的鸿沟。所以先来总结一下共通的初级程序员比较容易犯的错误吧。如果哪天自己带团队了，面试别人也可以拿这些题作为区分人的一种界限。做项目的时候有思考的人和不思考的人还是会有不小的区别的。
命名太啰嗦，或者不规范
这个问题其实挺普遍的，即使是科班出身的人，工作了很多年的人，写程序也可能冒出来一堆var
