由于时间较晚了，自己又是那种可以熬夜，但不想熬夜的假程序员，因此这里只是写一个自己后面将要写的文章的一个提纲。
关于开发这个很大的话题，我很早接触，但是感觉真正入门实在一次跟大三学长的合作中，自己负责前端部分。 当然遇到很多困难，也认识到自己的不足，于是狂补，当然现在看来还是有些不够。
就网页开发而言，现在的前端可以说是热的不要不要的，连我这个小菜鸟都嗅到了腐臭味哈哈哈。 但是就单纯网页开发而言，能够经历近30年发展的检验，其涉及的内容还是很多的。
无论是前端开发还是后端开发，其目的无非就是完成我们想要的效果。其实质就是改变数据库。
后端开发java而言，比较热门的框架，ssm（或者说springMvc吧）,springboot。 目前很多大佬都比较看好springboot，原因很简单，即使它使用简单。 但是缺点也很明显，甚至是硬伤，那就是它封装了太多东西，一旦出现了问题我们得花些精力处理。 但是不管怎样它们都是经历了时间检验的，必然有它的正确性。
经历了一些实践，我的做法是这样，并且将来也想这样。 不知道有经验的开发者老师们都是怎样做开发工作的。 根据软件开发流程，明确需求，原型设计，数据库设计------> 之后我就打算用 mybatis-generator反向工程自动生成映射文件，以及它所提供的六个基本的操作。 然后，我想采用的是根据对象去进行数据库的一些操作，因此需要将反向工程生成的实体类略作修改，将那种一对一，或者一对多等关系的，并且经过分析它们有必要进行关联的，可以改造下pojo对象，这个对数据库是没有任何影响的，所有的操作都是基于orm中的o。 之后进行Mapper的相关映射的修改，这里有个技巧就是： 针对于assosiaction 和collection 其中的映射可以不用自己写，采用继承或者 引用一个resultMap。 之后花一定的将所有的属性以可选的字段给实现了，如增删改查各自都搞一份，那种具有控制性的。 之后对mapper层中的这些方法都测试了之后，可以象征性的再service中做一下简单的转发。但是注意不做逻辑控制，或者说只做一些十分简单，并且是必须的逻辑控制，因为之后所有的service开发都是增对这几个基本的接口，即增删改查的一个包装，也就是说之后所有的操作都不再进入到mapper层。
采用该方法的好处： 几乎将复杂的mapper，任务量大，枯燥无聊的sql开发都给丢开，专注于业务层的开发。 缺点就是一定程度可能会影响性能。 但是这个影响是及其有限的，因为很多的操作是orm帮我们做，并不是数据库做。 另外，使用面向对象的设计方法上来近乎变态的要求性能这是很矛盾的。
这里对于开发中出现了需要重新更改需求的问题的话，也是十分的简单，只需改两处，一个是想要的pojo对象，另一个是与之相关联的Mapper中的相应属性。 就可以方便的进行开发了，当然，数据库的属性不用说也知道是必须改的。
之后是service层与controller层的解耦，通过代理模式，抽象出一个BaseExecution，并提供泛型，可以很好的扩展，并且很好的控制，这一点在使用中可谓让我喜笑颜开啊。 真的很爽，代码少整洁，逻辑清晰。 后端的开发基本就这些，但是实际上我会发现这个中途有很多重复的部分，有一些是逻辑的重复，有一些是代码的重复。 但是自己一直没有找到一个好的方法来将这其中核心的东西给提炼出来。 一方面是因为它中间涉及到了很多的一些逻辑代码，另一方面是因为它并不是一些普通的Java对象，不好使用Oop思想进行类比。
然后是前端的开发：
说说angular吧，接触了有个小半年左右，一直比较纠结的是它的功能定位，到底想要做插件，还是想要做语言。。 不知道大家有过这样的迷惑没有。 但是今天总算可以将长期迷惑的问题处理下了： angular1.x 和 angular2.x angular4.x是两个几乎完全不同的东西。 angular1.x 用作脚本使用，angular2之后用做一个生态了。 其中优劣不去评述，但是它所带来的好处是很直观的。
再说说前端框架： MVC框架，MVP框架，MVVM也就是最近很火的东西，它的实现主要有： vue.js,React.js,Angular.js。 虽然我对他们也比较感兴趣，但是我考虑到自己将来可能主要还是想学后端，因此便只用angular1.x已经够了。 尽管这样，这种数据驱动的方式实在是对交互来说是一个大大的解耦，用起来真的是神清气爽的感觉，可扩展性大大提高了。 门槛又低真可谓神器也。 以后要开发自己的什么东西，自己一个人也可以轻松完成了，打不了借用一套ECS模板，就可以快速的实现一个自己的，可使用的，高扩展性的前后端生态体系。
就这样吧。。 晚安，好梦！