哈哈，其实刚开始我刚进公司写代码的时候，也发现很多项目里有好多坑。

做的一个后台内容管理系统，因为没有专业的前端所以开发这个系统的界面部分也是后端做的，那 js 代码，，怎么说呢，写的非常乱、杂，一看就是专门写服务端的人写的（虽然我也不是个专业前端的，但是至少 js 还是有专门实践过一段实践的）。写一个小的界面组件，写两 function ，一个 div display:none ，然后包进 jquery ， jsp:include 进来，最让人郁闷的是 http header 里塞了一堆的 js 、 css ，然后所有界面都 include ，导致这个后台体验不算好，也一直想提使用一些 vue.JS 之类轻量级的框架，不过因为以前没啥话语权也就没多说什么了，原先怎么写的，我也就照着写，力求不造坑。但是随着项目的迭代，发现如果继续按照原来那样写，后边就根本没法维护，后来忍不住最近终于提出我的想法了，不过开会的时候其他个别的想法的是学习成本高、项目使用不稳定。。。（其实言下之意就是：能用就行，不想折腾那么多，学新东西太费劲）。如果说服务端上个新框架啥的，这个肯定是需要考量的，但是对于前段界面框架这种把稳定性挂钩在一起我就感觉无力吐槽了，就好比你跟我说 jQuery 上了会不会不稳定一样。。前端框架在易用性、可选择性上来说比什么 mybatis 、 hibernate 、 spring 什么要高多了。又不像换个语言框架把服务器弄蹦了跑不起来。

对于重构这块，就我工作这两年下，体会还是比较深的。我最感叹的一点就是，人与人之间的追求都是不同的，有的人是为了完成功能完成任务，而有的人会尽善尽美，你很难说这两种是对还是错。之前我觉得自己也算是尽量做好一件事的人吧。但是有时候真的，想去做好这件事很难，明明这地方代码写的不好，你又总不好意思动他代码，动了出问题了容易把锅吸到自己头上，所以有时候为了不去碰这个坑，反而往往自己绕着弯搞了另外一堆坑，有时候我都为因为将来接手我代码的人感到自愧。。怕他们说我代码写的烂。。。。因此在一个没有代码规范，没有代码 review ，为了完成功能不去想着程序可扩展性、健壮性的情形下，实在是很头疼，以至于我现在维护原来的代码的时候，也是怎么快点完成就怎么写，因为那堆代码真的有时候自己改着都觉得满满的挫折感，很痛苦写完就不想再看一遍，完全没有自己以前写代码的那种成就感。

有什么是非 rust 不可的吗？
没有？
洗洗睡吧。。。
optional != irreplaceable

var xxx=xxxxx; //写分号

var fx = function(){

} //不写

$(xxx).on('click',function(){

}); //写



。。。。。 java 写惯了。。

当然是 apple music

明显是需求。
只有是需求才会问的这么详细。
如果是简单面试题，才不会让你回答一五一十呢，给个思路就行了。

1.单例模式的单例指的是数据库连接池对象，而不是单个连接对象。多个线程公用一个连接对象肯定会有问题。
2.的确是这样，第 11 个就要等待前边的资源释放。碰到这样的问题，就需要做本地缓存、数据库分库分表分布式集群。
3.可以直接返回 Map ，但是 ORM 的好处在于，如果一个表字段很多， insert 、 update 语句会很长，在表增、改、删字字段的时候，所有的这些 SQL 都要一起修改，如果遗漏这些语句，运行时就会报错。使用 Hibernate 的好处不仅是在于 update 、 insert 、 ORM 这方面方便，一个 JavaBean 做了 @Entity 关联以后，应用程序在启动过程中 hibernate 会去检查相关的 bean 字段是否和数据库中匹配，如果发现不匹配，那么在启动过程中就会直接报错，而不是等线上运行时才报错。另外用 Map 的形式，你获取一个字段的值，肯定用 map.get("columnXX"),get()参数是一个字符串，如果里边对应的字段名改了，那么这段代码只能到运行的时候才能爆出字段错误的异常，而实用 Hibernate ，你改了字段名，在编译器你就能发现这些错误。

每个终端工具都有自己的一套颜色方案。
进 iterm2 配置下颜色就行了。

醉了，越来越搞不懂 js 要干嘛了。。。。

当然是 php ，天生为 web 开发而生，专注 web 开发 30 年

首先你要明白什么是责任链模式，通俗的说就是，如果当前这个请求是需要由我负责的，那么我就处理这个请求，否则我就把请求递交给下一个负责任。

这里需要明确的是，当前所处的“我”这个负责人并不需要关心上一个负责人或者下一个负责人，也就是说“我”这个负责人并不能直接与相邻的负责人进行交互。好比快递员， a 快递给 b 一件货物， a 与 b 并不是直接交接，而是 a 把快递送到物流公司，再由物流公司送到 b'手上， b'收到货物发现不是自己的，然后 b'再把快递送回物流公司，物流公司最终送到 b 手上。

而如果用继承的方式，有两个缺陷：
1.责任人之间有交互了，增加了耦合性，不符合责任链可插拔的特性。
2.责任链传递方向只能从子类到父类（通过 super.xxxChain() 方式）。而往往常见的责任链模式一般都是从头到尾，然后再从尾到头。比如 servlet 里的 filter ， http request 通过 N 层的 filter 到达 servlet 后， servlet 返回的 response 也需要通过这 N 层的 filter 再返回给客户端。 netty 的 channel 、 spring 拦截器也都是这个原理。

还有一个理由也能算是缺陷， java 设计模式里一般比较忌讳继承。特别的，如果你有三个 Filter 分别是 AFilter ， BFilter ， CFilter ， C 继承自 B ， B 继承自 A ，假设中间你需要把 BFilter 给去掉，那么 CFilter 的代码就会报错，此时你就需要手动修改 CFilter extends AFilter ，因为去掉一个责任人而导致其他部分的代码也跟着需要修改，明显是不符合设计模式的初衷的。

我一般养人。