最近接手其他人做的项目，导致之前的一些幻想破灭了。因为刚工作的时候做项目是php，而php本身的web框架一般只简单区分mvc，稍微麻烦一些的会多个library或者helper之类的。这样分层很少有优点同时也有缺点。当然了，现代的框架一般支持namespace，你也完全可以借鉴其它语言来做自己的内部框架。这里先不说这个。
mvc的优点自然是简单，无论一个新人有没有做过相关的工作，你只要跟他简单说明每一层的职责是什么，马上就可以开始工作。缺点也非常明显，因为太简单，所以代码在累积到一定量以后会变得难以控制复杂度。同时容易让没什么经验的程序员把代码写得难以维护。
所以之前听说java的框架这方面做得好一些，然后对部门的java项目抱有一些幻想。不过在实际接手后，发现理想和现实真是有比较巨大的鸿沟。所以先来总结一下共通的初级程序员比较容易犯的错误吧。如果哪天自己带团队了，面试别人也可以拿这些题作为区分人的一种界限。做项目的时候有思考的人和不思考的人还是会有不小的区别的。
命名太啰嗦，或者不规范
这个问题其实挺普遍的，即使是科班出身的人，工作了很多年的人，写程序也可能冒出来一堆var
刚毕业的时候在迅雷工作了半年，因为一些特殊原因，还是回北京工作了。中间乱七八糟的东西就不说了。
因为只在这个公司待了半年。。所以可能也不算学到了什么东西，只是大概地对这个公司的业务流程有了一些了解，写下来做个记录吧。
对于一般的用户来说，迅雷就只是个简单的下载工具。当年迅雷能干掉网络蚂蚁和快车成为最流行的下载软件，主要还是因为自身做的比较好(其实上市的时候ceo说是因为快车作者沉迷魔兽世界顾不上维护软件我会跟你讲？
作为一个从共享软件年代一路走到互联网时代的工具，迅雷还是有自己的一些创新点的。里面最重要的大概就是用base64加密磁力链接转成thunder链接了(误)。说正经的，其实是自称的p2sp。P2SP(Peer
to Server &
Peer)，看全称，其实就是在p2p里加入了server来参与用户的下载流程。当然有人会说，一般的bt服务也会有tracker服务参与啊，你这个好像不算创新。那还是不一样的。tracker服务器实际上并不会存储具体的文件内容存储。只会存一些torrent的元信息。但是在迅雷的p2sp里，
es的DSL实在是过于难用，相信使用过的同学都会有这种感受。而sql对于99%的程序员来说没有什么学习成本。
所以在工作需要的情况下，完成了这么一个简单的项目：
> https://github.com/cch123/elasticsql
把sql转换为es的DSL，这样你就不用每次都去写那个痛苦的DSL了。
这个库可以用来做什么呢？嗯，比如你在业务中用到了es，又不想去为了这套es培训所有人学会es的dsl，那么你可以使用它。再比如你想要实现一个支持sql的es的proxy，也可以把它当成你的一个模块来使用。
当然目前项目还在初期阶段，只实现了取数据部分。就是指定where条件，获取数据这种逻辑。count/sum/min之类的聚会还没有做，回头会加上。
不过where条件的话自我感觉支持还算完美，虽然目前还有点纠结sql里的equal应该用match phrase还是用term来做(因为match
phrase要涉及到分词之类的逻辑，
企业内部使用的elasticsearch是提供垂直搜索的一种方案，什么是垂直搜索呢。
先抄个百度百科：
垂直搜索引擎是针对某一个行业的专业搜索引擎，是搜索引擎的细分和延伸，是对网页库中的某类专门的信息进行一次整合，定向分字段抽取出需要的数据进行处理后再以某种形式返回给用户。垂直搜索是相对通用搜索引擎的信息量大、查询不准确、深度不够等提出来的新的搜索引擎服务模式，通过针对某一特定领域、某一特定人群或某一特定需求提供的有一定价值的信息和相关服务。其特点就是“专、精、深”，且具有行业色彩，相比较通用搜索引擎的海量信息无序化，垂直搜索引擎则显得更加专注、具体和深入。
其实说白了就一句话，垂直搜索是在企业内部使用的搜索引擎。这种搜索引擎的特点是，内容可能是一些结构化的数据，而不像大搜索那样都是杂乱的内容。
一般被拿来解决一些什么样的问题：
1.数据库字段太多，查询太慢，索引没有办法再做优化
2.数据库一个count就拖死全表。
3.
几个月前部门内容组织了一次系统设计的议题，分到我们头上的题目是设计一套灰度发布系统。嗯，然后我们就精心设计(参考公司现有系统)了一番，不过鉴于滴滴现在大部分的人都是百度来的(误，所以这种系统大概也都是差不多的思路实现而来的。所以感觉应该算是一种通用系统吧~
为什么要有灰度发布系统？灰度发布是现代互联网公司比较必然的一种需求，像滴滴这种规模的公司，千万级的司机和亿级的用户，如果不经小规模实际业务场景测试(代码本身的测试流程先不算)就对线上流程贸然修改、重构并且上线，必然会造成群体性事件，影响到公司的形象，伤害到终端用户，并最终波及到码农可怜的年终奖。而灰度发布能带来什么样的好处呢？可以让你少伤害一部分用户啊~如果出了问题，回滚或者对影响到的用户进行补偿都很方便(毕竟钱能解决的问题都不是问题，但规模太大的时候补偿手段就不好使了。
实际上在一个系统的灰度策略执行期间，老的逻辑和新的逻辑的代码在线上系统都是存在的。这样说的话可能有些人会提出异议，我们在做代码发布的时候先发布一台机器，然后再发布十台，
