陈江川

邮箱:jiangchuanc@gmail.com

Thinking

Zero. 现在

两个月没写blog了,8月中旬开始一直忙着封装公司核心业务的SDK,以及完善之前的封装的Sip静态库。OCLint一直想写第二篇文章,但涉及到一些原理的东西,需要大篇幅讲解,加上又劳心着SDK的封装,所以一直没动手。

想让iOS组开发走上一个正规化的流程,为什么会有这个想法?

  1. 入职公司第一次打开项目的时候,先从AppDelegate入手,第一感觉:无序,杂乱;然后再打开Main.storyboard,我用的Macbook Pro 8G内存 + SSD,加载用了1min,里面竟然有30多个控制器,至此Main.storyboard没打开过;
  2. 随便打开一个ViewController,代码行数随随便便2000+;
  3. 属性命名乱七八糟、注释乱七八糟、逻辑处理乱七八糟...

这个项目大概3年前开始做,中间经过了N个人的手,又没有一套规范,各自按自己的风格来写,最后变成了烂摊子,大家都不想动这个项目,但是有新需求还是得硬着头皮改。

基于上述的问题,先考虑的是如何基于现在的代码进行优化:

  1. 拆分AppDelegate,把无关的一些初始化方法写在AppDelegate的Category里;
  2. 把Sip和音视频代码从项目中剥离出来封装成一个库;

在做完第二点的时候,公司要基于封装一套音视频流程(老版本是电信研究院写的,局限性很大),我在iOS项目开发中组件化的应用有谈到,新的库使用CocoaPods管理,模块化有了雏形。

进而考虑的是code review问题,有几个方案:

  1. 直接使用git,每次push后,进行人工review,通过后在merge到主干;
  2. 使用OCLint,写一套规则,然后生成库文件导入Xcode中,这样在提交代码之前,开发成员就可以知道哪些代码有问题;然后在Jenkins自动化中加入OCLint插件再进行一次review;
  3. 使用Phabricator进行人工review,然后在Jenkins自动化中加入Phabricator插件再进行一次review。

国庆前后已经把Phabricator搭建好,现在SDK的封装在尝试这套流程。有了code review后,就得制定一套代码规范,之前写了一些规范,但没有制定成文,未来会用一至两个月时间来完成初稿。

总结:代码规范 + Code Review + 模块化

最后,再等一个合适的机会重写项目!

First. 感受

昨天同事问我:如何让代码不会随着业务不断的变化、增加而不显得臃肿?
我没有正面回答这个问题,只是简单回了句:经验。

记得高中语文老师讲解作文的时候,让我们多看文章、多记好句子。不会写,先模仿别人;最后把别人的东西消化成自己的,才能写出好的文章。

代码也是这样,首先你得有丰富的代码阅读量,官方文档、优秀的第三方框架、技术类文章;
其次有大量的代码书写量,只看不写那就是纸上谈兵了;
最后:思考!如果你只写代码而不去思考为什么要这么写,或者不去反思能不能用其它更好的方式去实现业务,那你只能徘徊在码农的水平。

身边一些朋友跟我说:觉得自己不适合做技术,沉不下心,不知道在技术这条路上能走多远。
我认为这里的“不合适”应该是“不热爱”,可能很多人选择程序员这个职业,是因为相对其他行业的高工资,而不是热爱它。