对不起，稍微有点标题党。下面先酝酿下正题。
随着做程序员的时间越来越久，经历过快速跑业务堆需求，经历过做基础做框架搞平台搞提效，越来越觉得代码的可维护性不是个非好即坏的状态。有复杂的各种输入影响代码的最终状态（指可维护性、后略），代码的状态又进一步影响项目，最终在当前项目这个整个大的研发系统下达到一定的平衡。这个平衡状态可能不是大家想要的状态，但是一般这种平衡却其实是较符合项目现状的稳定状态。如果没有较大的外力来影响系统，这个平衡是比较难打破和改变的。只要不出现项目无法维护的情况，那它有可能会一直持续下去。
今天我想就这一些状态、影响和平衡，过去这些年产生的技术、框架解决的一些问题等，聊聊我的思考。
沉寂了一年的博客又来诈尸了。
这一年一如既往的很多不如意，时间依然不足，也依然没有回本。
2021年过去得很快，成年人的生活就是如此千篇一律，让人感觉时光飞逝。其实我个人已经不喜欢这种节奏了，留给自己的自由时间还是太少了。不过上班总归还是要上的，毕竟……
这一年失去了很多，感慨下终归还是没有办法调节好生活中所有的平衡。当然也和大部分中概人一样：
不过这一年也学会了很多，有所付出终归有所收获。时间越来越不够用，原定的计划做了不少调整，不过总体来说还可以接受。
随着app size的日渐增加，大家都可能会有裁剪app size的需要。当然整块的砍掉使用率低的功能模块是最彻底也最简单的，但这会因为面临各种压力而难以执行……那么主要采用的就是一些常用技术方案：压缩图片、资源后下发、优化代码还有二进制重排列等。
还有一个重要的方向，就是删除无用的代码。不过这个方向在技术上还是有些难度的，因为OC这门语言的特殊性，很难使用静态检查的方法找出无用代码。那么就要借助在运行时实时分析的方案来做，分析的粒度大小主要分为函数粒度和类粒度。按照函数的粒度来分析，要么是在runtime里hook msg_send相关的入口，这样做对性能的影响蛮大；要么是深入了解底层原理后，在编译期做好插桩工作，这样做需要对相应底层技术有十分深入的理解。总之，要么很废，要么很难。所以我们这次利用runtime自带的特性，从类的粒度来分析一下类有没有被初始化过即可。
时隔两年苹果又坑了，还是那个熟悉的CoreTelephony库，还是那个熟悉的CTTelephonyNetworkInfo.h，还是那个熟悉的available标错导致的崩溃。
之前聊的一些内容都倾向于某个方向，不够普遍适用。所以今天就聊一聊在技术生涯中的一些经验和思路，可以应用在各种方案设计和选型中。
无论做什么事情，都是始于学习的。技术这个行业更是要求很强的学习能力，每天都在更新各种各样的新技术，每一项技术也都可以研究得很深入。
上一章词法分析的内容里我们介绍了解析数字的方法，当时还提到了对ID的解析，但是因为当时还用不到ID类型，所以就没有做对应的解析，这一章我们将会讲解下ID类型的解析方法。
ID类型通常用在变量名和函数名上，变量要应用的话至少还得实现赋值表达式，所以我们先用ID类型来尝试实现函数调用功能。注意是调用我们在计算器里内置的函数，暂时还没有办法动态定义新的函数。
之前为了快速进入主题，我们约定了表达式里只会出现个位数的数字。现在是时候打破这个规则，支持多位数的数字了。为了支持这点，我们就需要接触一个新的步骤——词法分析。
词法分析就是把一个完整的语句拆分成一个个词（token），方便之后进行进一步的语法分析。
举个简单的例子：今天真热，将会被拆分成<今天>, <真>, <热>。当然拆分成<今>, <天真>, <热>也是一种可能，但是这样的分词方式不符合汉语的语法。
我们的解析器已经可以处理基本的加减乘除运算并支持括号了。但是随着功能越来越多，可能出现的错误也越来越多。不重视错误处理的话，碰到非法的表达式时会出现什么结果，我们完全是无法预料的。所以本章就打个岔，给解析器加上一套错误处理逻辑。这知识和编译原理关系不大，不感兴趣的朋友可以略过。
本章还会顺带聊一聊负数的解析，用递归的方式处理负数可以做的很简单，想复杂点也可以做的很复杂。如果是用调度场算法处理表达式中的负数的话，推荐看看这一篇文章（英文），我就不深入分析了。负数解析不涉及到编译原理相关的新知识，不感兴趣也可以略过。
今天要给我们的“计算器”加上乘、除和取模三种运算，并且加上对括号的优先级处理。
如果不是采用递归方式解析表达式的话，可以参考下调度场算法，这是一个利用队列和堆栈来解决计算优先级的经典算法。
用递归方式解析的话，只要深刻理解了上一章的知识，这一章的都是小意思，那么我们开始。