也不知道这个标题中的原则一词用的对不对，我姑且叫他原则吧。对于写代码的我们来说，其实我后面会叫他规范，但是想了想，对于其他方面来说，又或许是原则，好啦，不纠结，直接进入正题。
来新公司一个多月了，从我刚到公司那天刚好是一个迭代的开始，直到昨天，后台版本已经同步到公网，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，而不是产品。
