我对今天谈话的思考

今天和dalao谈了一些问题,感觉获益良多。所以回来之后又思考了一下。

现在感觉要学的东西太多了,时间不够用。要好好为自己将来的学习打算啦。

 

一、关于项目的结构

1.分层

因为之前使用ssm,这次的项目我还是按照习惯分了层:

pojo,dao,service,controller

谈话之后才感觉到,这样似乎是没有必要的。以前使用mybatis,需要mapper,dao,pojo三个层配合,才能对数据库操作进行映射。既然现在没有使用这种架构了,反正就是路径->接口这种模式而已嘛,为什么一定要分那么多层嘛?感觉首先可以把dao和service层合并

pojo,service,controller

剩下三层我就觉得已经足够精简了。分这三层主要是为了项目结构的规范,相同性质的代码放在同一目录下,感觉会比较有条理,更好地管理和维护。

2.是否需要写接口?

这几个方法都是不需要频繁更变实现类的方法,是不是可以不用写接口了?

比如说我有一个用户服务,我可能会写一个接口,再写一个实现类

userService,userServiceImpl

关键是这里的接口能不能省掉,为什么不直接写一个实现类呢?我个人认为省不省掉接口都可以,主要是我的个人习惯问题,觉得写个接口比较直观。原因可以看:

java中接口有什么作用?

二、项目的一些问题

之前我在jersey中配置了swagger,在开发环境中,所有开发人员运行服务端都没有报错。但是在生产环境中,虽然服务端可以正常启动,但是所有接口都不能访问了。

查看日志,虽然有很多报错信息,但是根本找不到具体原因。因为同tomcat下存在两个项目,所以认为是项目之间发生冲突所致。移除了之前的项目,错误依然未能解决。因为生产环境无法更换环境变量,所以只能从项目本身查找原因了。

最后dalao把swagger的组件移除了,项目才能正常启动。后来通过控制变量尝试移除各种包,才确定是swagger组件下的jsr330依赖导致了这个错误。我个人认为应该是线上环境版本较低,导致swagger的依赖出现问题,导致项目在生产环境出现错误。

这件事我和dalao谈了一下,说说我的想法吧。

1.慎用框架的问题

这个问题可以等价于:为什么公司不让我使用新技术?

如果开发人员只是会使用框架,但是对框架的实现原理缺乏了解(比如说我),万一框架本身出现问题,那么就意味着解决方案本身出现问题,解决起来成本实在是太高了。很多时候工作是为了追求效率最大化,倾向于使用成熟稳定的解决方案。也有很多开明的公司(比如我司)敢于使用新技术,这当然也要看情况,如果紧急,还是使用现有解决方案比较靠谱。

如果开发人员对框架有一定的了解,是不是就可以使用框架了呢?假如只有我一个人能解决这个框架的bug,而其他的开发人员难以胜任,这就表示解决问题的能力集中在了我的身上,变相提高了风险。万一出现问题是我不能解决的,那么所有的开发人员就遭重了。万一我带着技术溜了,那么公司就遭重了。

所以最好慎用框架。

其实并不是说完全不能使用框架。因为使用新事物往往会有风险问题,所以要进行风险控制。这个框架真的能带来便利吗?比起原来的解决方案,优势在哪里?劣势在哪里?框架的学习成本高吗?如果使用的框架出现了问题,要怎么去解决?你能独立解决错误吗?有没有准备替代的方案?换用解决方案成本如何?这些问题在开发前都是要想好的,多多问自己为什么,才能做到有备无患。

最后,我还是要努力提高自己对框架原理的掌握程度,多去想想为什么,才能提高自己,有更多的机会去使用新事物。

2.项目分层问题

首先项目结构是分层的,再加上使用的依赖也是分层的,可能导致一个普通项目都有很多层出现。

比如说:我习惯于把基础项目分为service,dao,pojo,controller层,现在要加一个接口频率限制功能,可能要加多一层注解。如果又要加一个权限控制,可能又要多加一层注解…只要需求变多了,再加上使用各种框架,层次很可能会越来越多,整个项目的结构就会变臃肿。

这样会有什么问题呢?在找bug上会有问题。不像c直接报堆栈上的错误,java中的报错机制是一层一层报的,会在每一层报出出现问题代码的位置。如果层次多了,就有可能报出海量日志,对查找错误非常不利。

实际上,框架也是分了很多层的。如果盲目使用框架,这样项目的层次就会更多,最终导致bug难定位,难解决。

其实并不是说项目一定不能分层,只是在分层前,一定要想好为什么,做个利弊权衡,才加以实践。

三、学习的方法

1.多问自己为什么

在项目的问题中,可以见到我总是在强调多问自己为什么。

在使用新框架之前,问问自己:这个框架真的能带来便利吗?比起原来的解决方案,优势在哪里?劣势在哪里?

在使用接口之前,问问自己:为什么要使用接口?比起直接使用实现类,优势在哪里?劣势在哪里?

在使用jackson解析json之前,问问自己:为什么要用jackson呢?使用java原生解析json不行吗?jackson是怎么实现的?如果让你去实现一个jackson,你有怎样的思路呢?

其实这应该算是一种生活态度,要保持自己旺盛的求知欲和好奇心。多问自己为什么,才能对自己要做的事情有更深的理解,使用起来更有把握。

2.尝试自己去造轮子

怎么加深自己对框架的理解?

看到别人的轮子这么酷炫,有没有想自己造一个的想法?光是看别人的源码,算不上是真正的理解。如果是你去写这个功能,你要怎么去实现?

如果你已经能用原生方法实现了,那么能不能用上设计模式呢?如果你写的没有别人效率高,这是为什么?如果你模仿别人的轮子,可以造的比别人更科学合理吗?

其实这是一种学习方法。多看源码,多造轮子,才能加深自己对原理的理解。

3.多看经典

以前我一直强调“实践”才是最重要的,一旦遇到新需求,可以马上尝试实现,遇到问题再去尝试解决,这样提升很快。原理这些东西,可以在使用熟练之后再去了解。

现在,使用是会使用了,但是你现在了解原理了吗?

现在看来,我以前这样做并不是没有道理,但是这样做会导致一些问题:

(1)你根本不知道这样写会出问题

如果别人不给你指出来/你亲自碰上了这个坑,那么就很有可能养成错误的习惯。这样你写的代码就会一直有问题。等真正出现问题了,问题就麻烦了。

(2)遇到的基本上都是使用上的问题

不从底层去解决,可能会忽视原理。

尝试解决问题的时候,往往停留在代码表面,对原理没有太多的涉及。这样解决问题其实意义并不大,只是表面上知道怎么去解决这样一个问题而已。要是懂得原理,往往能解决这样一系列的问题。

所以我推荐看一些经典来补完。会对整个知识体系有新的认识。

四、总结

总之,一定要多想想为什么,多去写代码,造轮子,看经典,才会有提高。

发表评论

电子邮件地址不会被公开。 必填项已用*标注