学习spring boot搭建个人简单博客有感

这一次的学习，可以算得上我最开拓视野的学习。

以前也是学过spring和springMVC的，但是就如同猪八戒吞人参果一样，不知道味道，死记硬背了一些概念，学会了一些配置和框架，但实际上自己的理解不是很多，时间太赶，一边复习一边上实践课导致学习的投入不高，另一方面也有当初没有努力学习的缘故。不过，这次的暑期实践，给了完美的学习条件，专心学一种东西，还给了自由自习的时间，在上课学习知识的同时，课后查阅相关的资料进行视野的开拓，这次的实践可谓是天时地利人和全具，学习的效率也是打游提升，体会颇深。

首先是视野的开拓导致的学习效率的提升。之前学习软件工程，一直是把C、java等语言当成编程的基础，努力的去看懂整个程序的运行过程，理解其中使用的方法，但是随着学习的东西慢慢变多，很多导入的包和容器都不是语言中的基础，而是经过技术发展演变出来的实用的技术模板，想要看懂其中的东西着实费力，以至于学习效率低下，甚至学习过了之后却迷茫的发现自己仍然没有懂。这是我很久之前在学习数学的时候的遇过的问题了，就是有板有眼的深究，在没有了解大概的情况下进行盲人摸象的学习，好比只把加法当成加法，而不是一种定义的运算符，把1数到10当成一种理所当然，而不是把它看作一种进制。这种错误的学习方法在刚刚接触spring的注解的时候突然被我意识到了，因为我看不懂注解的原理，没有办法使用java的基础内容解释注解。我这个时候突然意识到自己一直在把学过的java基础当成了定理，而不是一种语言。学习一门技术的时候往往不是先学习它的原理，而是先学会使用它，在有了框架性的认识之后学习原理起来是事半功倍了。在跳出这个坑之后，我的学习意识果然跟上来了，没有想要刨根问底的念头困扰自己了，先学会如何使用，之后用的多了再去了解原理。之后不管是请求的注解（@requestmapper）还是数据的注解（@Data），把他们当成工具来使用，在脑子里对于框架的搭建过程理解也更深刻了，算得上是学会了技术，暂时不明白原理，但是，相信随着我见识的越来越多，这个问题也许在某一天就突然发现自己懂了。

其次是课外的拓展对于学习的帮助。如今已经不是大家都闭门造车的年代了，就如同我想把知识分享给其他人一样，很多人也有着同样的想法，很多前辈早已付诸实践，在查找问题的同时，可以看到很多不仅是细节类的操作小技巧，还有关于框架的整体把控等技术问题，在看到了别人的理解之后，结合自己学习的内容，大多数情况下问题都会迎刃而解。同时，很多时候我们找问题的时候，带着的可能不是问题，而是我不知道我有什么问题，也不知道如何解决。往往这个时候需要查看的东西更为广泛。这次我们小组的合作是在gitee上进行，但是我发现不能进行推送命令，网上给出的解决办法大都是换ssh密匙，我换过了但也无济于事。这个时候的我就是有了问题，但是不知道问题出在哪，该如何解决。但其实这只是一个框架上的意思错误，原因是我没有加入开发者的邀请中，没有权限。也许有不少的人和我犯着同样的错，因为不懂工具，使用的时候查找的却是技术上的问题，而不是使用的问题。没有明确的目的的查询，某种意义上也算是一种浪费时间。所以，先弄明白问题，再去网上找答案，比起找问题之后再找答案要快很多，学习的东西也能更为实际具体。

最后是关于技术上的，也就是CRUD的框架以及服务器的框架。关于程序分层的问题要先进行一定的思考，为什么要有接口和实体类，分层的好处等等要先明白。之后便是CRUD服务的简单思路了。先根据url进行服务方法的判断，然后按照需求运行相应的业务逻辑，最后返回对应的页面，额外的加成是对于查询和页面拦截，这是前后端不分离的情况。关于前后端分离我还没有学懂，目前我的主要方向是后端，对于前端的了解还比较少，但是框架的逻辑部分应该也是一样的。想了一下，其实服务类最开始的servlet类也是用java基础规则编写出来的，然后被大多数人所统一采用，形成了一种封装，然后才有了包的导入，如果去官方网页去把源码给扒下来，里面的颜色和我们学习的基础是一样的。但是有意义的是我们不需要学会源码，我们只要知道方法名、参数、返回值和方法处理的业务逻辑，就可以了，和老师说的一样，一个方法最不重要的就是方法体了，封装之后，就不必管里面的东西了。这或许就是java的强大之处，使用底层的基础实现业务，然后封装，给别人用，省下大把的时间。我们学习的服务类就是对于servlet类的一层层的包装，就好比电脑里的芯片一样，把所有的功能给你封装好了，告诉你哪个是输入的接口（注解），用哪个来输出（model和返回值），先用这东西把服务器搭好，有时间再慢慢了解芯片的内容吧。

总的来说，这次实践的眼界开拓意义要比学到的东西更有价值，意味着我今后的学习可以带着大局的眼光去看待学习的一个个细节，学习进度将要加快了。