背景
经过近三个月的开发和调优，新的项目产品包括企业端（B端）和客户端（C端）在App Store正式上线，在项目开发过程中个人负责HTTP对接和相关第三方服务的封装工作，参与了很多实践锻炼，整体回顾和总结了五条iOS项目开发经验。
PS：下述经验的实践有不同的难度需要投入不同量的精力，在实际项目根据实际情况选择合适的方案逐步推进。
1 充分利用开发和调试工具
好的开发工具可以大幅提供工作效率，以下做一些分析和推荐。
- [免费外部程序] 第三方库类依赖管理工具，如
Cocoapods或者Carthage - [免费外部程序] 应用内测发布平台，如苹果的
TestFlight、蒲公英、fir - [收费外部程序] 网络抓包调试工具，如
Charles - [收费外部程序] 界面图层分析工具
Reveal，此外Xcode在左侧导航的调试栏目中也提供图层分析工具，如图：
- [免费SDK] 程序异常崩溃统计和分析工具，如
Crashlytics，友盟错误统计，腾讯的Bugly - [免费SDK] 在应用埋点统计用户的使用习惯统计工具
Flurry，友盟统计 - [开源代码] 在开发阶段同步内存分析和泄漏检查工具，如腾讯微信阅读团队的MLeaksFinder、Facebook的FBMemoryProfiler以及FBAllactionTracker和FBRetainCycleDetector
- [开源代码] 一行代码即可在App启动后快速跳转目标页面的 开发利器：控制器传送门VCPicker
- [开源代码] 在开发阶段进行页面子视图细节调试分析工具，如 Flipboard的FLEX，如图
- [开源代码] 视图位置布局
frame和constrain的简化写法，再也不用写又臭又长的CGRectGetWidth()了，如@Casa老师的HandyAutoLayout - [自行封装] 字体和颜色进行统一管理，在开发中用到字体或者颜色时，用特定的类方法，而不是写死的色值和字体大小（实际编程中尽可能避免甚至杜绝死值出现！），方便以后统一维护和修改实现快速更换皮肤
- 善用注释，Xcode8后不能使用旧的插件，针对方法和属性的注释可以用
///这样可以在编程时生成Xcode的注释提示，对于带有参数的方法，还可以使用组合键option + command + /快速生成注释模板
2 重视第三方库类的封装
在开发的过程中难免会使用到第三方库类，第三方类提供的API可能并非全部使用，而且部分API的不尽友善，进行进一步的封装有诸多好处，典型的场景如网络框架的封装，如AFNetworking、CocoaAsyncSocket等。
- 将相关业务逻辑一并封装处理，降低业务方调用难度
- 避免代码散落在过多文件，降低维护成功
- 第三方库不再维护后也可以替换其他合适或者独立研发的库，而不影响业务层的API调用，无痛切换
3 重视独立研发库的私有pod建设
在公司项目发展到多个项目时，必然会共用一些服务或者类，单纯的复制文件。潜在的问题就是一旦修改了一个类，那么其他工程的类也要一并修改，项目越多维护的难度越大。解决方案很容易想到的是类似Cocoapods的依赖管理，实际上Cocoapods也支持建立私有pod，不论是svn或者git管理代码都可以很方便地维护。
同时，不同的服务其实也需要独立的工程师研发，如果在当前业务项目工程中开发有如下问题
- 因为主工程过大而编译速度慢
- 带来对当前主项目造成不稳定风险
- 多个服务的单元测试依赖主工程的强耦合关系
优雅且可持续的方案是分服务单独建立工程和pod独立研发和进行版本控制。
4 异乎寻常重要的国际化
国际化就是为不同语言的设备提供不同的文案，因为频繁的调用宏和英文key来实现静态字符串的显示，小型项目一般是不会考虑，一次项目实践时的紧急需求变更让我意识到每一个项目都做国际化的重要性，需求的变更内容如下：
工程没有做国际化，需求要求将所有静态文案中的“AA”替换为“BB”，“CC”替换为“DD”，两者加起来将近100处
我首先想到的是定义一个替换的宏嵌套旧的字符串以规避需求再次变更的风险，不赞同在全工程中检索关键字逐个检查后粘贴替换，因为繁琐而可能导致未来可能的回滚问题，直到国际化方案的提出来，可以将所有的字符串放在一个文件内统一管理，让我意识到其重要性。
此外，开发中常用的HTTP请求的hud的loading的文案提示，按钮的确认和取消文案等等，也可以使用国际化字符串的方式进行规范和统一，既能统一静态字符串的管理，也为将来可能的国际化留有余地。
5 遇到问题先找出最可能的错误原因
开发调试时程序抛出异常，处理异常首先要根据报错的信息，找出可能潜在的错误原因，逐个分析可能性后再对症下药，举两个最近的例子
- 新的工程中通过Cocoapods导入ShareSDK编译出现undefined symbols xxxx for architecture arm64，出现问题后是不是这个库没有适配这个设备，各种修改build-setting，后来才发现ShareSDK自身还依赖另外一个库没有引入到podfile中，所以才会报undefined symbols错误
- 一个cell的左滑删除功能，在滑出后会迅速地自动收回去，问题出现后也立刻检查是否tableView的协议方法使用问题，各种修改不同的实现方式也未能修复问题，直到后来想到是因为因为这个tableView刷新导致的，速度去搜索reloadData，reloadIndexPaths:和reloadSection:终于找到原因是有定时器在不断刷新cell的问题
所以，为了少走弯路，更好解决问题的方法是先停下来想一想会有哪些可能性后，逐个对比最有可能的因素，有的放矢地去排查将会事半功倍。
以下还有一些项目管理方面的不成熟看法
1 合理利用团队协作工具
新的需求、发现的新bug、需要调试的新接口和变动等等诸多事项都需要团队的沟通，将这些事件以清单的形式列出来，同事之间可以协同交流、处理和编辑，也便于以后的回顾和管理，在这方面现在涌现出很多工具了，如Teambition、Tower、钉钉等。
2 加强同事以及部门间的沟通
经过这次项目的开发历程后，意识到人与人之间沟通对项目开发的重要性。除了关心iOS开发内部需要一个独当一面的技术做好架构，还需要：
- 一个左右逢源的同学来粘合成员之间的沟通
- 在与产品经理、后台工程师和设计师沟通也需要打好交道
里里外外都需要用心去经营，大家共同在一个团队，目的是技能的成长和事业的成功，本着同心协力的心态去将项目向好的方向推动才是一个好的团队应有的面貌。
我的建议是：
- 同事之间互相鼓励打气
- 收集共同的问题和意见向公司提出并积极跟进问题的反馈
- 技术团队内部做小范围的小主题的分享，激发讨论和研究的氛围
- 与其他产品、后台和设计部门的同事保持来往。
- 遇到确实不乐意合作或者消极合作的同事，只能先礼后兵，该撕逼的要撕逼
3 与生手的合作
需要注意团队内有手比较生的同学时：
- 适合做辅助的页面开发
- 适配做功能的调试和测试
- 心思灵活的可以负责对外部门的协调
- 前期不能分配主要流程和业务工作，避免主体业务踩坑
- 及时对工作成果进行review，并要求重现其他成熟成果的工作，带着共同进步
4 养成记录和总结的习惯
长期的开发虽然有些枯燥，但也必然有很多收获，
- 在开发过程中解决的小bug
- 业余收集的小知识点
- 想到的新问题和解决方案
- 接下来要做的事情
随着工作经验的增长必然会积累很多，好记性不如烂笔头，随手将这些经验都简单地整理成笔记，一方面方便以后查询，再一个就是记录是又一次回顾的过程将加深对这个知识的印象。日积月累后定期做一些总结，就会有沉甸甸的收获，把这些收获拿出来和身边的同学一起分享，互相促进，开发就有更意思，也更轻松。
5 了解产品现状以面对将来的变化
除了留给外人看工程师闷头敲代码之外，其实我们也应该深入去了解我们自身开发的产品，当然它可能不能令你满意，但我们仍然可以看到好的那些方面，闲暇时也可以像大佬一样思考产品的出路，如果没有这样的准备，下一次机会来临的时候可能因为对产品认知的浅薄而失去晋升上一级管理梯队的机会，抱怨问题每个人都会，更难得的是解决问题的人。
鸣谢
感谢一路上一起学习交流的Ace、Luffy、Alan...
加我微信沟通。
