最近公司开始着手项目的重构，准确来说，公司半年前就已经开始准备重构。除了客观因素外，只是有很多工作都是嘴皮子工作，或者写文档，画蓝图去了。没有真真正正地去做一些切实的事情。分析和设计固然重要，没有落实，就像是很多零前面没有1。
我本人是非常注重项目架构的，好的项目架构，无形中，凝聚了很多智慧，经得起段时间变迁和洗礼。可是，时常也会感觉到，这项目重构这样的事情中，不同的项目情况，不同的公司团队，总是会带来不同的问题。这就带来了技术思考之外的，我称之为理念思考。技术思考解决技术问题，理念思考解决人的思想问题。
我的从业经验慢慢地告诉我，有的时候，理念思考上的烦恼和工作量，往往都非常非常，大于n多倍的技术思考。这里面的原因很多。可能是好高骛远，可能是追求形式，华丽的彩衣，也可能是设计过度，思考过度。有的时候，要是想着怎么对接5年后的技术和业务。不如想着，先把手里落后的3年的项目改到今年。一口吃个胖子，不光是难受，更加是不被接受的工作付出。
我听说过，一些开发者说，这个项目是我一个人重构完成的，语气当中充满着自豪和骄傲。这是这的肯定的。反过来说，如果有几个人和你合作，你能重构好吗？要知道，想法过多，在IT开发中，往往都是一个阻碍。。人，尤其是程序员，是非常偏执的，不愿意在主观上接收别人的想法。而实际上，每个人，对于项目结构优化的思路，都不可能是百分之百完善的。
这个东西，先说到这里吧。
今天要分享一个东西，这个东西应该很早就被移动开发圈子知道。
点击链接：微信Android模块化架构重构实践
文章很长，讲的很细，值的说到事，真的非常值的仔细看看。。我在这里，提出来一些我个人感觉不错的句子。也算是我的总结了。当然，我在意的这些句子。都是和技术无关的。
1，“君有疾在腠理，不治将恐深”
2，模块边界破坏、基础工程中心化，都是代码持续劣化的帮凶。
3，目前Android端App整体架设计上，除了聚焦在“大前端”之外，基本上都在“插件化/应用沙盒”上面下功夫。
4，不被监管的权利一定会发生腐败” 。如果放到软件开发的行当来说，就是“不被监管的代码也一定会发生劣化”。所以代码应该要接受“监管”。
5，在一个长期没有改进的框架下，开发者的习惯可能会逐步变成跟随式、保守式的开发。这大概可以被描述成“只要别人这样做，我也这样做，哪怕这么样的设计不好，但也不会错”。经常能听到有同学吐槽一些代码，却更少看到代码在被改进。
6，让他们可以放心参考。
7，代码的边界就像一堵墙，架构的劣化都是从这堵墙的瓦解开始的。
8，因为代码解耦从来不是问题，纠结的只是解耦行为能不能让人理解。我们要尽力避免的，应该是随意拼凑和单纯为了类型解耦而解耦的情况。
9，用纯粹的模块化保持后续架构的灵活性和健壮性，重新强调依赖、强调应用状态和生命周期、强化代码的边界。
最近也有看到另外一个东西。原文来自携程的一个产品，这么说的(当然，我是摘录)。
... ...
当然，任何框架模式都不是全能的，MVCPI也存在它不足，如果有好的意见和建议，欢迎加入，一起讨论推进框架模式的发展。
设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构。
这些东西相信都是非常有益的。。如果看到这里，你想着，"我们现在的项目，也要朝着这个方向去"... ... 。。。what's the fuck !! shit !!! 你们的项目是你一个人说的算吗？你的项目有三四十五六十人的直接业务团队吗？你的项目有上亿人的使用量吗？你的项目会和哪怕微信这样发展6年了吗，也许，你的公司都不一定会生存6年，你的项目会向腾讯一下，一直被支持吗？你的团队会有年轻积极的正能量吗？
so,如果你看了壮的，就想使劲吃，太没脑子了。很多东西是可以学习的，不是让你套用。
