丢什么别丢原则

 也不知道这个标题中的原则一词用的对不对,我姑且叫他原则吧。对于写代码的我们来说,其实我后面会叫他规范,但是想了想,对于其他方面来说,又或许是原则,好啦,不纠结,直接进入正题。

 来新公司一个多月了,从我刚到公司那天刚好是一个迭代的开始,直到昨天,后台版本已经同步到公网,APP因为需要审核稍微延迟了点,但是内部测试也正紧锣密鼓的进行中。刚换了一个环境,对新环境里的开发模式,代码规范,代码提交模式等都是新的,感受最深的自然就是代码提交的方式。习惯了以前的code review方式,来这里之后目前是没有这个强制的机制,所以有所放纵,也正因如此,我自己松懈了。

 松懈的代价有点惨烈,直到版本上线前夕也就是昨天,才真正理解很多事情是需要原则,需要规矩,需要规范的,没有规矩不成方圆,代码没有规范,就不能称为好的产品,我是Android开发,那自然就是出不了好的APP。先从我的角度说说规范的事。从编程规范来说,尤其是Java编程规范,空指针是最容易出现的问题之一,如果后台加了个字段,但是APP版本如果想先对接旧后台对比下前后的功能,此时没有做过入参判断,那是什么结果可想而知,APP崩溃啊。倘若做了判断,那OK至少从用户体验来说,APP没有出现致命的问题。不过入参判断只是其中一步,没有判断null的前提下,也可以让他不崩溃,也就是网上也会出的技巧,让常量作为判断前提方可。其实写这段话的时候,看的同学肯定也觉得,这么简单的事情,还是轻轻松松的嘛,那很好,说明这个小错误我很傻呗。这也是我昨天到家之后,第一个深刻感受,并不是你不会或者你不懂,而是你没注意,一个小小的细节引发的血案。

 非空判断,还有数组的越界异常,这些无论是在Java还是c都是很容易出现的问题。记得在以前的项目组里,还有Java和c的军规呢,把这些低级错误都需要杜绝。杜绝的一个很好的方式就是code review,Google那么牛的公司都需要做,何况是我们呢。记得刚到杭州公司的时候,同事让我去review,一时间没反应过来,后来渐渐的熟悉了这一流程,把一些平时容易错的都列出为review必备条件。网上看过很多鸡汤文,提到很多次的也是review的重要性,多看看别人的代码,也是提高能力的方式。Code review,以前是项目组必备,现在因为没有强制执行,所以我松懈了,代码就是新版本上线出问题了。其实我也可以推卸责任的,版本上线后台也出了差错,回滚了3次才弄好,但是还有参数没有配置,导致配置不对,APP获取参数不正确。按理来说,APP和后台强相关的情境下,其实我之前是和后台确认过的,但是原因不可抗拒,所以也并不是说后台同事告诉你肯定没问题,你就得百分之百确信,这也是一种自我判断的能力,需要严格遵守自己内心的编程规范原则,无论何时何处,都需要做好APP的万全之策,而且保证用户体验。

 第一次参与新公司的版本上线,客户端就是遇到了入参未进行非空判断,未进行数组长度的判断引起的崩溃,实在是心有愧疚,其实这个以前都是必备的操作,这次完全是因为我没有严格遵守导致的问题,还好只是预上线,在内部消化了问题。后台的问题我不大清楚,但是就知道回滚了几次,好在在可控范围之内,有惊无险。据我所知,后台的问题大部分还是因为配置未同步、代码未同步到线上。忽然发现了一个共通的问题,我遇到的版本上线当天,开发都是严阵以待,总会出现大的小的问题,不是部署就是APP忽然测出来的问题,不知道大家有没有经历过,哈哈。

 有过第一次经历了,我也知道套路了,我还想说说自己另一个感受,做产品是一件很严肃的事情。还记得以前和几个新同事一起开发的时候,因为其中一位的懈怠,组内老大在开早会当着众人的面说:我们做产品的,再也不会像是学校做毕业设计那样了,每个人需要有产品意识。从那以后,我便把这句话铭记在心,但是很遗憾,我自己也没好好做到,尤其是对待写代码这件事情上,在自我懈怠中失去了产品的意识。做一款产品,写代码只是其中一件事,还有需求分析,需求评估,甚至流程图等等,我会把我这三年学到的东西发挥最大的作用,让产品做的更好。也借第一次发版本的经历,告诫自己,丢什么别丢原则,否则你做的永远只是APP,而不是产品。

展开阅读全文

没有更多推荐了,返回首页