App架构？
架构很多时候，是个很玄的词。
软件开发中，架构真实的存在并影响着软件研发、运行与维护时的质量。
好的架构，明眼人一看就知道。比如Linux内核，又比如一些优质的开源软件。
而其他架构的质量，则往往难以判断。
嗯，关于这次iNCU App的架构，自己虽然觉得有些地方仍有不足，但是已经是自己尽全力的作品了。
这次分享出来，也是想分享自己在App架构上的实践与思考，如果有不足的地方，还希望各位多多指正。
思考🤔
App在正式开发之前，自己思考了两周，内容是 App的分层，文件的结构与技术选型等。
App的分层，在我看来是个非常重要的部分，假使View, Model, Router等层级杂糅在一起，在代码达到一定规模时，开发将会变的非常痛苦。容易出现耦合性高，BUG多，修改难等诸多问题，牵一发而动全身，从而陷入无边际的重构或者修改BUG的过程。
为了不陷入这种“地狱”状态，所以宁可多花时间在前期的思考与尝试中。
React Native
React Native是一个很特殊的框架。跨平台、复用性高、热更新等特性听起来很美好，但实际开发中会发现限制和BUG也很多。
很多功能，想要实现，只能靠原生拓展，但是这边能写原生的人只有一个……所以大部分原生拓展只能依赖开源的RN模块去实现。
团队
种种限制之下，对App的任何功能的开发与拓展，与我而言都不亚于一场战争。
毕竟，我也大概只能在家园工作室呆几个月不到的时间了，而这个App在一两年的时间内，还是需要做一个维护与拓展的，如何平衡这个问题，也需要自己耗费诸多脑力去思考。
如果只是为了自己开心，上一堆花式炫技的技术或者选用一堆不稳定的模块，其实只是顾着自己一时爽快，对于整个团队而言是弊大于利了。
另外自己写代码也快有两年时间了，直到今年年初，通过看书才悟出了“程序的第一要义是明确”的这个道理。而这个项目，也希望给学弟学妹们留一个好的例子，写代码很多时候真的不需要花式炫技，代码可读性高，可维护性好，健壮性强才是真正值得去追求的。
启动工作
与之前相比，在写这个App的功能或者模块时，自己会先画个思维导图或者流程图，确保逻辑是通畅的、可实现的。而不是边写边想边重构。
因为大概自己也很清楚，难点和问题从来就不在实现的具体方式和技术上，而是逻辑和流程上。有了具体的逻辑，写东西那是唰唰的快。
比如说关于网络层的思考：
自己画了详细的思维导图，考虑了可能会出现的所有情况，所以在开始写代码的时候，便显得有把握的多，后续的开发过程中也证明了这种思路的可行性，没有大修大改的情况，只是在这个基础上做一个修修补补。
设计模式
嗯，其实也算不上设计模式，但是之所以还是取了这个标题，是因为自己觉得整个App的研发过程中，充满着设计模式的思想。就是:
把变与不变的地方分开
基于这点，在开发过程中，更多的考虑了变与不变，从而在此基础上实现了文件结构，模块划分等。
至于后续的开发体验，只能说爽~~~
即使改了需求，也只需要改动一小块地方，耦合性低，再配合自己写的单元测试，可以说是效率极高。
测试
测试，是iNCU在开发中的核心环节，也是iNCU顺利开发的保护伞。也就是从这个项目开始，真正理解了测试的作用。
在这里的测试，包括 单元测试、Api接口测试、snapshot测试三种。
其中单元测试针对一些函数和功能，确保正确运行。
Api接口测试则是因为这儿接入了五六个后端，需要确保后端的接口运行正确与返回的数据正确。
Snapshot则是为了保证基础组件的正常运行，防止出现版本升级突然挂掉，或者修改属性也不知道的问题。
三种测试一起使用，保证了项目在修改，升级的稳定性。
文件结构
首先放上项目的文件结构：
.
├── __tests__ # 全局测试文件
├── common # 通用工具
│ ├── __tests__
│ └── analytics # 数据分析
├── components # 基础组件
│ └── __tests__
├── constants # 常量
├── containers # container
├── networks # 网络层
│ ├── __tests__
│ ├── api # api
│ ├── interceptors # 拦截器，用于对网络请求做一些拦截处理
│ │ ├── request
│ │ └── response_error
│ └── interfaces # 接口定义文件
├── pages # 具体页面 View层
│ ├── __tests__
├── redux # Redux
│ ├── modules # 具体的Redux 模块
│ └── sagas # sagas
└── typings # 自定义的接口文件
文件结构在我看来，一直是个很重要的内容，因为在项目发展的过程中，一个设计不佳的文件结构会给人带来很大的困扰，比如开发新功能或修改老功能。
上面放的就是iNCU项目的文件的结构，做了一个分层的处理，从而保证开发有序。
而在Redux的处理上，按官方推荐的那种结构来，在项目扩大化时，将会遇到繁琐的问题。
因此对于Redux中模块的处理，参照了 dva 和 vuex 的实现，聚合在一起，从而避免一些不必要的操作。
结语：
这篇博客是2017-04-17开的坑，因为自己在忙一些别的事情，所以今天（2017年05月06日）才补完后半部分。
无论如何，也算是写出了自己一直想说的一些事情吧~
前端路漫漫，且行且歌~