iOS项目中常用的“打补丁”技巧

嗯。。怎么开篇呢

。

。

(一个小时。。搓脚毛苦思中。。)

。

呵呵，你以为博主真的不知道怎么开篇么，这里花了一个小时的时间其实是另有深意的好么，我的套路就是这么湿！！，其实博主是为了阐述一个问题！就是如果只想了一个标题，内容却不知道怎么组织就会是这样的慢性尴尬症。就像我们做项目的时候经常脑袋一热，二话不说上来就撸代码。然后就发现框架不行，不够灵活无法扩展，功能缺失！然后在你准备调整架构的时候，产品经理就跳出来补上一刀——改需求。

产品经理常用必杀：

『用户反应，按钮双击会有错误，所以你把整个项目有交互的控件都设置为不能双击吧，干巴爹』

『这个输入框怎么能输入🐵🐵🐵这个呢，把所有的输入框都禁止输入乱七八糟的东西吧，么么哒』

——这个是emoji，并没有这么乱七八糟。。

『哦之前忘了定义，给所有的输入框都限制大数吧、给所有的页面都加上返回手势吧，给所有的……』

『线上有几个页面暂时不需要了，能屏蔽掉么』

。。。

我能和产品探讨一下引力波的探测与广义相对论的必然联系么？老子弄死你丫的

我想项目新人几乎都遇到过这些坑吧，产品经理不专业在一般的公司里是常态，现在的互联网，一言不合就改需求，也是个常态。

但是强大的猿类们，决不能屈服于这种常态，变态起来！！

只要努力微笑，命运也会惧怕我的獠牙。

回到这次的主题——『打补丁』

什么是打补丁呢，打补丁是使用针线在织物上辅以破布以缝补上，是民间伟大的传统手工艺之一。该技艺严谨精密，讲究施针，针法所达百余种，常见的有滚、铺、盖、戳等等，针脚整齐、掺色轻柔、虚实合度、变化丰富。一千多年来，逐步形成。。。诶，这老毛病就是改不了，总是喜欢一本正经的扯犊子~~

博主要说的『打补丁』必然不是针线活！再次声明这里是技术博客，并非传统技艺授受中心！

我们给一个东西打补丁，原因就两个字！破。

所以我们给项目打补丁也是因为项目破了，就像遇到上面的整改需求，功能不完善了，功能缺失了我们就有了打补丁的必要了。

在iOS中打补丁，我以修补时机为主分为两种打补丁的方式，

• 开发中的打补丁
• 线上的打补丁

开发中修补

早知今日，何必当初。何出此感慨？假如开始项目的时候框架设计好一点，今天还会沦落到打补丁么？？但是耍流氓的敏捷开发、坑爹的开发周期、逆天的用户需求之下何来优秀的框架搭设啊？

看着产品方案，我颤抖的小嘴刚要张开说『一个礼拜框架搭设，两个礼拜编码，应该…』然而老板拍拍你的肩膀『小伙子 这个周末弄出来，我以前也是做开发的，时间很充足哦，不许骗我喔~』，老板你确定你不是以前做PPT的。

这个时候的心情就跟刚看完《小时代》一样憋屈。所以开发中需要打补丁的状况太多了，改结构，重写，时间不够，所以只能打补丁了！

AOP

当初学习JavaEE的时候接触了该理念，反正文邹邹的概念博主也不贴出来了，AOP就是面向切面编程的简称，说白了就是一个打补丁的编程方式！不侵入式地给一个方法添加代码。冠名之『 润物细无声の技能』，嘿嘿，有个片假名的标题，你们都兴奋了起来呢~~

知道什么是学霸么！就是举手投足高分拿下、信手拈来理论来辩、回眸一笑全是败将！不要怀疑！这就是博主，真学霸！

『这样要改一下』。。被吓得都质壁分离了！

总结

这篇文主要是分享了本人在正式项目中遇到时间紧迫但是急需变更需求的时候的一些解决方法与思路，都是拙见，都是野路子，但是我就是喜欢这样，哈哈 （自带BGM_{我就是爱音乐}别叫我停下来~）

但是，预见性的架构设计思想可以让你避免掉很多的野路子，一份代码的优雅以及可靠都是在一些规范的设计原则上建立起来的，所以哦，像一些基本的设计原则比如Don't repeat yourself 原则；封装成类，或者在基类中的封装；众多设计模式有良好的扩展和灵活特性的指导；又或者利用其他编程范式如函数式、响应式来写出更加健壮灵活的代码，可以让你的项目更加健壮、灵活、、高效、优雅。

散了！回家抄党章避避邪去了，又要改需求。。。。