谈谈自己对框架的理解吧

发现最近竞争确实非常的激烈, 现在就业想万人过独木桥的大环境下, 如何在众多竞争者中脱颖而出, 还是需要不断增强自己的实力才是, 我承认我也是培训出来的, 但是我感觉并没有什么, 追求自己想要的生活没有什么错, 但是需要不断的学习, 充实自己, 武装自己才行, 毕竟和科班出身的同学差了4年的大学授课呢, 这不是用短时间可以弥补的, 因为在培训班学到的基本知识局限的一小部分, 计算机最基础的就是数据结构+算法, 完全是一窍不通呢, 想进阶挤进真正的程序员, 想吃这碗饭一会那么一点OC是远远不足的...

但是人不能好高骛远, 才是从眼前的事情做起才好, 今天想总结一下我眼中的项目框架, 可能有点浅, 只是为了今后自己Review用.

自己研究的项目的源码:https://github.com/mhqamx/MXKit

框架目录

如上图, 工程里面有这样的一些文件夹

1.constant目录, 里边放的类一般是系统宏观的量, 比如申请的一些第三方的key, 秘钥等, 可以放在里面用全局常量或者macro来管理就好, 还有项目中的一些UI规范也要加在这个类中, 比如什么时候用什么字体, 字号, 字体颜色, App主题颜色等, 还有就是一些全局都通用的类, 总言之只要是常量就放在这个目录下就好.

2.CoreEngine目录, 字面意思就是核心引擎, 里面放置的是工程的一些主要业务逻辑在里边, 使用延展来管理不同需求的逻辑, 说起来有点不是很白上一张图片看一下好了, 利用延展将用户的一些操作的逻辑单独抽取出来, 有效的避免了代码的冗余, 也有利于在之上在做拓展, 从名字看也知道core嘛.

CoreEngine

3.Support目录, 这个用的比较的多, 每个人的习惯不同, 往里面放的东西也不相同, 但是基本方的都是一些资源类文件了, 一些icon或者假数据的plist, markdown的Jason数据等.

4.UI/Classes目录, 在一开始的时候以为应该根据tabbar来分模块来建立文件,  但是在实际的项目中发现有一些类和model是全局需要复用的, 用tabbar来划分不是很合适, 所以索性打破这个界限, 根据业务模块来划分就好了, 比如登录模块, 注册模块, 主页都单独拎出来单独一个目录, 这样查找起来也能简单明了, 不用一层一层的查找某个特定的文件了.

5.Utils目录, 里面放置一些工具类, 比如自定义的DDLog, 分享功能, 收藏功能等, 这些工具类基本使用单例来管理, 来控制线程的安全性, 这里面就先带过了.

6.NetWork目录, 不用说网络层肯定是每一个项目最关键的了, 依据公司的后台请求逻辑不通, 网络请求也会有一些小的变动, 比如据我所知的, 有的公司使用TK来作为标示来请求网络, TK是通过设备的UUID再通过后台获得的, 设备换了或是应用删除再重新安装UUID都会动态变.另一种就是根据用户标识客户端本地生成类似TK, 利用本地的TK来请求网络, 防止hack拦截网络获取数据包. 但是这基础建立在服务器还是使用http协议, 只要升级到https之后应该就会简单很多.

7.Vender目录, 基本就是存放第三方框架的目录, 不适用cocoapods管理的三方框架存放在这里, 直接调用或者是修改一些源码再使用就可.

综上, 这些就是我现在理解下的通用框架的目录创建, 当然光是目录是没有什么卵用的, 框架最值钱的东西就是里面接口的设计和一些逻辑的处理, 可惜学业不精, 没能研究再神的框架, 框架可以想成分层管理的, 每个模块都是独立的, 之间不许有别依赖才行.

今天就先写这么多, 还是那句话, 计算机的脊柱还是 数据结构+算法, 一个人想立于世还是需要一技之长的, 当然要是那种有用的一技之长, 乐之者不如好之者, T型, 广度和深度.