技术知识和稳定的系统之间,可能还差这些?

96
IT米粉
2017.09.20 21:55* 字数 3047

前言:
很多人都说——程序一门艺术,对于这个说法,以前我是很难理解的,程序就是一个工具,一门学问,怎么会是一门艺术呢,后来工作越深入,考虑的东西越多,发现程序的确是一门艺术。什么是艺术呢?通过捕捉与挖掘、感受与分析、整合与运用,通过感受得到的形式展示出来的阶段性结果。程序不只是你写出来,运行起来就成功了,而是需要感受和分析、需要整合运用,需要最终变成成果。显然,程序是符合艺术的标准。
艺术的展现除了术,还需要道。程序的术是大家都能得到的共识,各种各样提升自己技术的文章到处都是,这里我们说说程序的道,也就是方法。这也是大家经常忽略或者不重视的地方。

作为一名艺术工作者(哈哈,自己也笑了。),工作中的确有太多需要注意的地方,特别是工作方法,这个东西在开发中一般是很少有人来培训自己,或者花时间来教自己,这个需要自己去学习、总结。我自己越到后面越总是这方面的学习,这里我也来说说自己工作中自己爬过的坑以及身边的同伴趟过的路。

关于开发

注释以及代码规范——程序是写给人看的,其次才是给机器用的

  1. 代码规范的困难点不是制定代码规范,而是执行代码规范。执行代码规范无外乎就两种方式:
  • 通过代码检查。其实一般都是通过IDE的插件去检查,常用的有适用于javascript的jsHint,适用于java的checkstyle,适用于 .net 的StyleCop。自动的代码检查能检测到的问题还是比较有限的,主要是针对格式、注释、命名等,但是效率高,能把一些低级的错误扼杀,如果熟悉二次开发,还是值得多花时间去研究定制的。
  • 通过人工代码审查。这个是纯人工的方式,有些坑是工具检测不出来的。如循环里访问数据库,循环里访问网络等,这些都需要去人工判断的。我一般的方式就是在CVS工具获取代码的时候进行对比,大概的浏览一遍,就能发现一些低级的错误。这样效率相对会高一点。
  1. 别说注释影响性能,浪费时间。注释的前提是一定要能让人看得懂,别人能看懂你的代码,就能节省很多时间,不要怕注释文字多,太长。现代的语言和编译器,对注释产生的性能影响完全可以忽略不计。

异常的处理——程序的错误存在,就在你身边

异常处理是我们开发过程中必须要面临的问题,但是经常会有一些异常处理的方式,被错误的使用了:

  1. 不抛出异常,让大家都懵逼了。
try
{
    
} 
catch (Exception ex)
{
 return null;
}

如果测试不出这样的问题,在生产环境绝对懵B,没有错误提示、没有写入日志,根本无法找到任何错误信息,这个看起来很低级的错误,在身边的确是有人这么处理的,我见过好多了。
测试和开发环境有错误一定要将详细的错误抛出来。
生产环境有错误也要适当的给与提示,告知错误,并且日志记录详细的错误。

  1. 忽略警告信息

现代编译器产生错误是无法编译通过的,但是警告默认是可以忽略的。如果条件允许,大家最好把警告全部处理掉,不处理就是在给自己埋坑,很有可能在后面会爆发。
我经历过一个的一个事件就是.net调用redis的一次事故,使用的是官方推荐的驱动类库为Service.Stack.Redis,但是使用的时候忽略警告信息,导致后期版本兼容性的问题在生产环境爆发,幸好已经有其他人躺过坑,所以问题立马就处理掉了。
条件允许,请解决所有的警告,如果条件有限,经常查看警告信息,重视新出现的警告信息。

代码洁癖——代码一定要追求完美

很多人都经历过接手别人的代码,而且程序员最害怕的就是阅读别人的代码。不管是别人的代码还是自己的代码,都要习惯性去重构,代码这门艺术不是一蹴而就的,是需要慢慢雕琢出来的。如果在开发过程中,不管是自己的代码还是别人的代码,发现问题,一定要去解决这些脏东西。代码是积累的过程,不合适的代码应该在初期就优化掉,如果越积越多,到最后只有可能是“没时间优化”和“不敢优化”。
在重构的过程中,总是会有很多理由让自己放弃这一操作,最多的两个理由就是:“没时间”和“风险太大”,持续衍生下下去,最后唯一的结果就是系统重新开发。这就是很多公司业务只是停滞不前或者稳步提升的,但是系统使用不到2年就要重做的原因。

代码的最终结果是变成成果——一定要定义deadline

工作是永远做不完的,但是项目必须定义deadline,即使在没有明确考核的情况下,自己也需要给自己定义deadline,一个项目耗的太久,会让项目的弱势越来越严重,会让成本越来越高,会让开发人员的编码效率低下,所有的开发任务一定要定义deadline。
定义deadline还有一个好处,就是能有成果展现,这个对于企业来说,是非常重要的。技术、知识、能力一定要变现成成果,即使是做技术研究,也需要有成果的展示,而不能一直处理进行中的状态,这种意识是非常重要的。

关于集成

测试代码是节省时间,而不是影响进度

一定要写测试用例。测试用例绝对不会浪费你的时间,测试用例觉得不会拖慢项目的进度,而且能加快项目的进度,进度不是开发完了,就完成,你要协助测试,保证项目上线。项目的进度才是真正的进度。测试用例实施起来困难的地方就是无法坚持下来。即使,自己对自己写出来的代码负责,即使公司没有要求,自己也要习惯写测试用例。大家可以看看那些好的开源代码,都是会有自己编写的测试用例的。

现在的开发方式基本都是前后端分离,不管是web还是app,都是通过api进行数据对接,对于测试用例也更加容易测试,所有的接口都需要有对应的测试用例,如果不愿意写代码,测试工具也是有可以替代代码编程的。对于开发人员,其实写代码测试可能体验会更好,速度更加快,测试工具更多的是面向测试工程师。

自动化测试是增强自信的最佳方式

  • 自动化测试是必要的
    随着时间的推移,系统的功能越来越多,功能越多其实意味着风险越大,出问题的可能性越来越大。随着系统的变大,人工覆盖的范围有限,自动化测试是必须要做的。

  • 自动化测试应该提前规划
    初期,通过人工基本可以覆盖所有的测试,但是后期功能越来越多,不仅要测试新功能,每个功能的开发都要进行全系统的回归测试。前文提到测试用例,这个是自动化测试的基础。有了强大的测试用例的积累,自动化测试的搭建就会更加容易。测试用例不是等到有时间,或者系统变大以后才做的,而是应该一开始就准备,不要等到系统变得非常庞大臃肿的时候才开始做,那时候你还需要重新会想当初的业务场景,得不偿失。

代码也随时处于能被发布的状态

现在的开发方式都倾向于敏捷开发,敏捷开发的优势这里就不多说了,但是敏捷开发有一个特点就是高频率的发布,所以代码应该是需要随时都处于能被发布的状态,其实这并不是很难,只要合理的使用CVS工具即可。

  • 永远有一个和线上代码一直的版本。 不要一个版本走到黑啊,一定要熟悉分支的作用。
  • fix bug采用独立版本合并发布。采用最小发布的方式,也就是需要哪几个文件就合并哪几个文件。
  • 建立一个灰度发布的环境,作为发布前验证的环境,和生产的环境一样,只是地址只有内部人员知道。当然,如果可以通过Nginx或者网关控制灰度发布,就最好了。

关于协作

代码是共享的,你的代码大家应该都能修改

作为公司代码的贡献者,不管你是总监、经理、架构还是程序员,不要认为自己的代码是别人不能修改,代码应该是共享的,只要在公司授权的范围内,我们应该是可以互相修改别人的模块。

  • 互相修改代码其实是代码审查的一个过程。
  • 互相修改代码便于互相熟悉业务。

在代码面前人人平等,谁写的代码都会有问题,有重构的空间,不能因为你的职位高或者经验足,就不让别人碰你的代码。
当然,有的人可能会改坏你的代码,但是这个可以通过沟通解决这个问题。

有时,我们过多的关注了技术知识体系本身,却忽略了把自己的技术知识更好的运用到工作中,运用到自己的系统中,因为这些东西除了学习相关的技能,更多的是需要自己总结,随时趟过的坑越多,可能总结的东西越多,罗马不是一天建造的,系统也是不是一次就完美的,我们自己的知识体系也需要时间去积累。

技术随笔