首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >技术知识和稳定的系统之间,可能还差这些?

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

原创
作者头像
itmifen
修改2018-04-16 11:48:07
8187
修改2018-04-16 11:48:07
举报
文章被收录于专栏:IT米粉IT米粉

前言:undefined很多人都说——程序一门艺术,对于这个说法,以前我是很难理解的,程序就是一个工具,一门学问,怎么会是一门艺术呢,后来工作越深入,考虑的东西越多,发现程序的确是一门艺术。什么是艺术呢?通过捕捉与挖掘、感受与分析、整合与运用,通过感受得到的形式展示出来的阶段性结果。程序不只是你写出来,运行起来就成功了,而是需要感受和分析、需要整合运用,需要最终变成成果。显然,程序是符合艺术的标准。

艺术的展现除了术,还需要道。程序的术是大家都能得到的共识,各种各样提升自己技术的文章到处都是,这里我们说说程序的道,也就是方法。这也是大家经常忽略或者不重视的地方。

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

关于开发

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

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

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

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

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

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

  1. 忽略警告信息

现代编译器产生错误是无法编译通过的,但是警告默认是可以忽略的。如果条件允许,大家最好把警告全部处理掉,不处理就是在给自己埋坑,很有可能在后面会爆发。

我经历过一个的一个事件就是.net调用redis的一次事故,使用的是官方推荐的驱动类库为Service.Stack.Redis,但是使用的时候忽略警告信息,导致后期版本兼容性的问题在生产环境爆发,幸好已经有其他人躺过坑,所以问题立马就处理掉了。

条件允许,请解决所有的警告,如果条件有限,经常查看警告信息,重视新出现的警告信息。

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

很多人都经历过接手别人的代码,而且程序员最害怕的就是阅读别人的代码。不管是别人的代码还是自己的代码,都要习惯性去重构,代码这门艺术不是一蹴而就的,是需要慢慢雕琢出来的。如果在开发过程中,不管是自己的代码还是别人的代码,发现问题,一定要去解决这些脏东西。代码是积累的过程,不合适的代码应该在初期就优化掉,如果越积越多,到最后只有可能是“没时间优化”和“不敢优化”。

在重构的过程中,总是会有很多理由让自己放弃这一操作,最多的两个理由就是:“没时间”和“风险太大”,持续衍生下下去,最后唯一的结果就是系统重新开发。这就是很多公司业务只是停滞不前或者稳步提升的,但是系统使用不到2年就要重做的原因。

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

工作是永远做不完的,但是项目必须定义deadline,即使在没有明确考核的情况下,自己也需要给自己定义deadline,一个项目耗的太久,会让项目的弱势越来越严重,会让成本越来越高,会让开发人员的编码效率低下,所有的开发任务一定要定义deadline。

定义deadline还有一个好处,就是能有成果展现,这个对于企业来说,是非常重要的。技术、知识、能力一定要变现成成果,即使是做技术研究,也需要有成果的展示,而不能一直处理进行中的状态,这种意识是非常重要的。

关于集成

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

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

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

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

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

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

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

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

关于协作

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

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

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

在代码面前人人平等,谁写的代码都会有问题,有重构的空间,不能因为你的职位高或者经验足,就不让别人碰你的代码。

当然,有的人可能会改坏你的代码,但是这个可以通过沟通解决这个问题。

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

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 关于开发
    • 注释以及代码规范——程序是写给人看的,其次才是给机器用的
      • 异常的处理——程序的错误存在,就在你身边
        • 代码洁癖——代码一定要追求完美
          • 代码的最终结果是变成成果——一定要定义deadline
          • 关于集成
            • 测试代码是节省时间,而不是影响进度
              • 自动化测试是增强自信的最佳方式
                • 代码也随时处于能被发布的状态
                • 关于协作
                  • 代码是共享的,你的代码大家应该都能修改
                  相关产品与服务
                  项目管理
                  CODING 项目管理(CODING Project Management,CODING-PM)工具包含迭代管理、需求管理、任务管理、缺陷管理、文件/wiki 等功能,适用于研发团队进行项目管理或敏捷开发实践。结合敏捷研发理念,帮助您对产品进行迭代规划,让每个迭代中的需求、任务、缺陷无障碍沟通流转, 让项目开发过程风险可控,达到可持续性快速迭代。
                  领券
                  问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档