对开发的一些思考

对开发的一些思考:

         如果只是一个小型的项目，那么架构师敢去想的空间有很多，没有很多的束缚，而一个大项目甚至一个系统，必须设计一套合理，高效，清晰的逻辑规则，这样才不至于混乱的找不到事故发生来源，从刚刚开始的项目搭建到下层基础完善，对于后期的开发非常重要，我想这个项目的灵魂是什么，我为什么这样设计，为什么要这样遵循我的规则，有什么好处，能让其他成员信服吗? 万一后期要修改，需要修改很多地方吗？ 

            安卓屏幕适配，各种屏幕，各种长宽，各种碎片，各种机型，这些都是实际的问题，需要一个一个的考虑进去，但是有时候想的太细会导致停滞不前，制定规则，其余事情迎刃而解，就拿现在做的来说，旧项目太过于臃肿，代码到处都是，View和DB层，硬件处理放在一起，后来引进MVP模式，因为项目已经非常大了。所以只能是修改一部分，仅仅将DB层和View层分开，但是还是很臃肿，7，8百行代码还是非常见的，这次项目移到Android Studio上，过程就不说了，但是现在很舒服，重新设计一个项目并改进，我觉得我的能力还不足以让其他成员明白我的想法，我为什么要这样改，因为基础搭建非常耗时，安卓的样式，颜色，dialog的样式设计，新控件的使用，页面跳转设计，权限问题，在做的过程中非常有体会，但是说明白给其他成员明白的能力需要加强，这些东西非常想制定一个规则，无奈制定的时间非常漫长，不过还是慢慢来，一步一步的走。

            按照原来的项目思路来，我发现有时候都不知道该干什么了，虽然说逻辑就摆在那里，但是面对多个类，看着一个又一个的布局文件，总是没个头绪，按照正常的流程，先将设计给的图画出来，然后加载数据，然后响应用户动作。一般就是数据获取，数据刷新，视图切换，对于View我觉得还好，尽量将那些复杂的逻辑给拿开，不要和View混在一起，虽然说标准的做法是面向接口编程，但是对于安卓来说，有点不大现实，一个接口需要很多方法，看起来还不如不写接口，直接引用。DB逻辑就放在A中，硬件逻辑放在B中，其他逻辑放在C中，这样可能在某些逻辑可以互相引用，而且维护相对来说与View隔离，与其他逻辑隔离，耦合的几率较小，逻辑解决了再来想一下数据的问题，数据刷新，用户动作导致数据改变，在碎片化的世界当中，可能activity存了一个变量，然后将变量传给fragment，之后可能又传给Dialog，然后修改数据，刷新，我的规则就是确定一个根容器，当然不是Application，将所有的数据放在大容器中，子View需要什么操作就传值给大容器，然后就等着数据刷新即可，当然这里唯一有技术含量的就是页面刷新了，得细细想好到底有哪些刷新，会影响到哪些子View，哪些不需要改动，这样给定一个总的刷新接口，或者刷新拆分为多个，高内聚的刷新单个，之后再组合使用，尽量使性能达到最优。

                                                                                                                                                                           -----2016-07-05 20:44:36  

I'm fish, I'm on.