在慕课网授课后关于学习模式的实践和思考

之前有幸应邀参与了慕课网的免费课程《Android依赖管理与私服搭建》和实战电视连续剧《Android通用框架设计与完整电商App开发》，在早先录制关于依赖管理的课程时，就有一部分同学因为很少接触Linux或类Unix操作系统而感到力不从心（力不从心别多想……），但是因为毕竟就一个小时不到的课程，给大家排排难也就可以了。但是在之后的实战课程里，大家不断实践不断延续性的学习的需求越来越欲求不满（欲求不满也别多想……）。

实战课一般是几十个小时的大课，里面的代码量已经非常巨大了，再加上录课阶段边侃边敲，很多细节的地方写的时候基本属于断片状态，多多少少会出些BUG，很多细心的同学在学习的过程中，会发现问题，或者可以优化的点，这样就会不可避免的出现各种探讨和小版本的迭代，那么之前原始的通过社交软件的沟通方式就显得特别的低效了和不及时了。并且，当大家集思广益的时候，会出现信息的丢失和忽略。

这个课程分两个大的部分。一个部分是带着大家从第一行代码开始高度封装一个自己的快速开发框架。毕竟，天下私活唯快不破（你们懂的），以最快的速度完成一个项目，并且把BUG都限制在框架层，是最大产出效益的方式，同时将通用的功能以最傻瓜式的方式提供接口，不管是给自己的接班人也好，还是给未来几个月断片的自己，都是最快速和最稳妥完成项目的方法。并且，当我们写代码的时候，写功能，就不应该思考业务，写业务，就不应该纠结功能，这种分离，也是对自己架构的一种提升。

但是这部分内容是一个循序渐进不断完善的过程。录制课程的时候，这个框架顶多算是alpha中的alpha版，需要完善的内容非常之多。比如性能，比如更详细的讲解，比如更多设计模式的使用。

说到设计模式，虽然我一直主张，设计模式这种东西是无招胜有招的，课程和框架里并没有特别强调设计模式，一般都是把设计模式融合到课程中，然后再转化成合适自己的模式。但是这是个课程呀，对不对（有点学院派的赶脚），所以需要有这么一个平台，能够让大家能够专门的来探讨他们觉得理解起来有点困难的部分，贴贴代码，发发心得，提提改进意见，包括性能的提升，以及更优雅的封装（不要说博客或者论坛，咋说也是人家的课程，不能完全公开出来的……只能是各位土豪买课的富帅和富美们了）。

还有就是，写框架的过程，往往和实现功能是不一样的。写框架是一个不断验证，不断思考，不断重构，不断优化和极致化的过程，这需要很长很长很长一段时间的时间，验证，精简，完善和集思广益，所以需要有一个机制，让学习的学生和自己能够不断的交流代码，不断的优化个吸取别人的信息。之前有想过通过Github创建个私有项目，或者coding，大家提交代码然后进行审核合并。不过小白鼠我和几个小白鼠同学实验之后，效果并不理想，正在思考一种方便交流信息和代码的方式。

当然啦，框架起了个非常惬意的名字Latte（拿铁），我也希望它能够像拿铁一样回味悠长，想一有时间就慢慢的去扩展和完善这个框架，让它让我们的开发更加的轻松惬意。比如说，现在的架构是单Activity架构，那么之后多Activity架构的扩展包就会加进来，并且讲解。现在是多module的模式管理依赖，那么以后，就会慢慢编程插件化的方式去管理依赖，利用small或者tinker这些热门的技术。当然，像dagger2这样的技术，看机会，和之前的补充一起，慢慢的一点一点加进去。

关于电商的话，其实个人感觉功能是有了，但算不上完善，很多电商里比较好的业务逻辑，也是可以和大家侃侃的，并且和上面一样补充进课程的新章节里，所以也需要有一个可以共享逻辑图的地方。之前研究过百度脑图，并且修改过源码，做成了自己的一个工具，但是总感觉太重，processon是一个不错的方案，不知道效果怎样。

之后呢，封装成能够快速处理某一类业务逻辑的module或者插件，一个能快速处理业务逻辑的框架，绝对是纯技术框架所不能比拟的。

总之呢，我坚持写框架和完善业务框架的封装，以及视频教学，都是一个持续的过程，不存在一次性讲完就真的学完了，我觉得那也是不负责任的，就像健身一样，为了活的一个好的身材，我坚持以年为单位举铁。那么完善代码和不断丰富教学视频，以及以文章或更多的方式探索更高效的学习和教学方式，就是大家和我的责任和义务。

至于这种模式怎么定，确实没想好，真心希望有一个比较完满的方案。

至于课程嘛。代码会不断的进步，更新和完善。一有空也会努力的加录视频，讲解新完善的内容和功能，以及修复BUG，争取让更多的人学到真东西

课程骚浪贱，学坏后果自负……

嗯，先这样

相关文章

《单Activity架构，丝滑般享受》

《关于Android高性能Restful请求的通用封装(单Retrofit和Retrofit+RxJava)》