发表于: 2017-12-01 23:28:02
3 694
今天完成的任务:
一、写了一个分页简单的demo
先是model
public class Page <E>{
private int pageNumber;
private int numPerPage;
private int totalCount;
private int totalPageNum;private List<E> list;
}
然后是Service里面一个方法。
public Page<Article> list(int NumPerPage,int pageNum){
Page<Article> page=new Page<Article>();
int start=(pageNum-1)*NumPerPage;
List<Article> l=articleDao.list(start,NumPerPage);
page.setList(l);
page.setNumPerPage(NumPerPage);
return page;
}
sql
这样的话输入的是页数,每页显示多少数据。
然后查出来需要的内容。
二、听老大讲代码整洁
听老大讲了以后收获还是很多的。了解到了很多之前没听过的东西。
.忘掉继承
继承的好处:可以复用,需要添加共同的方法或者属性的时候只需要在父类汇总添加,子类可以继承。
继承的坏处:多层继承会使代码的可读性变得很低很低,并且多层的继承会让代码变得很乱,并且继承和重载一起使用的时候,更加不能判断父类里面的方法是不是被重写过了。想想就难受,所以在能不用继承的时候都别用继承。
不用继承的话,可以使用组合。组合用的最多的是接口和实现类的方法,比如把Service当做一个属性注入到Controller里面,这样就可以直接去调用,而且也不会产生耦合。
.合适的场景使用合适的语言和工具
作为一个后端的程序员,不能被某一种语言限制了自己的思路,现在学习的是java,但不代表我只能使用java去解决问题,而是去找解决问题最方便的方法,这样才是一个正常的思路。在解决问题的时候不能只是通过自己会的内容去思考怎么做,而是去找找不同的解决办法,那个最快最方便就用哪个,不会就去学习,不能被现在掌握的java语言限制了自己的思路。
比如:在登录的时候需要去获取输入错误用户的输入错误次数,时间,错误内容。
两个办法,一个是使用java做一个后台管理,在代码里面添加记录错误信息的内容,保存数据库,然后显示。
第二个,记录日志,使用脚本语言来抓取,统计到文本中。
明显后面一个是更适用的,那我们不能因为自己不会写脚本,就去选择用java来化两三天完成这个任务。而是应该去学习新知识,用简便的方法来实现。
.消息队列拯救世界
假设一种情景:在登录的时候,首先需要验证输入是否正确,然后获取用户的登录日期,发送登录奖励,发送优惠券,发送优惠券提醒,发送手机短信,判断用户登录ip是否异常。。。。很多事情。
这个时候如果在Controller里面一个一个的顺序写功能,那么登录接口要处理太多的事情,这肯定是不现实的,登录一次需要等30s,那用户早就没有耐心了。。所以需要有个办法来解决。
办法就是使用消息队列:
实现就是登录的接口做两件事:1.登录验证 2.发送消息到公告。做完这两件事情就可以返回结果。
剩下所有的事情都有公告板上来处理,当检测到公告上收到了用户已经登录的信息,那么就开始执行剩余的功能,发送奖励,验证码,判断ip等等。这样一来登录需要完成的功能也有,登录的时间也不会变长。这叫做消息。
队列就是指不止一个用户在登录,有很多用户同时登录的时候,就将需要做的事情排好顺序,然后按顺序去完成。
上面说的消息队列是一种很好的思想,但是也是存在缺点的,使用消息队列相当于使用了一个第三方的代理,本来可以Controller直接去调用Service,变成了Controller调用消息,再去调用具体的功能,这样中间查了一腿,就会产生很多错误。所以,在世界毁灭的时候才需要消息队列拯救,比如代码已经不能支持去完成这种功能的时候。在没毁灭的时候,就好好该干啥干啥。。。
.永恒重构
bed smell 很多情况下都需要重构代码,是否需要重构,可以抽象成自己感觉代码需要重构了,那就是要去重构,而且重构三个重要的部分是:时间,质量,功能。
在这三个里面一定是质量第一的,不能为了赶时间而提交一个功能齐全的烂代码。
但是在开发的过程中,时间和功能是最直观能看到的,所以这两个也是很重要的衡量因素,所以如何兼顾也是需要考虑的问题。
比如:某个代码块太长50行以上,写某个方法需要用复制粘贴,等等。。
明天计划:
早上开一个讨论方案的会。
下午请假、
遇到问题:
暂时没有。
收获:
收获了很多东西。老大讲课干货很多。自己吸收的还是不多,有时间看视频回放。
评论