前言： 很多人都说——程序一门艺术，对于这个说法，以前我是很难理解的，程序就是一个工具，一门学问，怎么会是一门艺术呢，后来工作越深入，考虑的东西越多，发现程序的确是一门艺术。什么是艺术呢？通过捕捉与挖掘、感受与分析、整合与运用，通过感受得到的形式展示出来的阶段性结果。程序不只是你写出来，运行起来就成功了，而是需要感受和分析、需要整合运用，需要最终变成成果。显然，程序是符合艺术的标准。 艺术的展现除了术，还需要道。程序的术是大家都能得到的共识，各种各样提升自己技术的文章到处都是，这里我们说说程序的道，也就是方法。这也是大家经常忽略或者不重视的地方。
作为一名艺术工作者（哈哈，自己也笑了。），工作中的确有太多需要注意的地方，特别是工作方法，这个东西在开发中一般是很少有人来培训自己，或者花时间来教自己，这个需要自己去学习、总结。我自己越到后面越总是这方面的学习，这里我也来说说自己工作中自己爬过的坑以及身边的同伴趟过的路。
关于开发
注释以及代码规范——程序是写给人看的，其次才是给机器用的
- 代码规范的困难点不是制定代码规范，而是执行代码规范。执行代码规范无外乎就两种方式：
- 通过代码检查。其实一般都是通过IDE的插件去检查，常用的有适用于javascript的jsHint,适用于java的checkstyle,适用于 .net 的StyleCop。自动的代码检查能检测到的问题还是比较有限的，主要是针对格式、注释、命名等，但是效率高，能把一些低级的错误扼杀，如果熟悉二次开发，还是值得多花时间去研究定制的。
- 通过人工代码审查。这个是纯人工的方式，有些坑是工具检测不出来的。如循环里访问数据库，循环里访问网络等，这些都需要去人工判断的。我一般的方式就是在CVS工具获取代码的时候进行对比，大概的浏览一遍，就能发现一些低级的错误。这样效率相对会高一点。
- 别说注释影响性能，浪费时间。注释的前提是一定要能让人看得懂，别人能看懂你的代码，就能节省很多时间，不要怕注释文字多，太长。现代的语言和编译器，对注释产生的性能影响完全可以忽略不计。
异常的处理——程序的错误存在，就在你身边
异常处理是我们开发过程中必须要面临的问题，但是经常会有一些异常处理的方式，被错误的使用了：
- 不抛出异常，让大家都懵逼了。
try
{
}
catch (Exception ex)
{
return null；
}如果测试不出这样的问题，在生产环境绝对懵B，没有错误提示、没有写入日志，根本无法找到任何错误信息，这个看起来很低级的错误，在身边的确是有人这么处理的，我见过好多了。 测试和开发环境有错误一定要将详细的错误抛出来。 生产环境有错误也要适当的给与提示，告知错误，并且日志记录详细的错误。
- 忽略警告信息
现代编译器产生错误是无法编译通过的，但是警告默认是可以忽略的。如果条件允许，大家最好把警告全部处理掉，不处理就是在给自己埋坑，很有可能在后面会爆发。 我经历过一个的一个事件就是.net调用redis的一次事故，使用的是官方推荐的驱动类库为Service.Stack.Redis,但是使用的时候忽略警告信息，导致后期版本兼容性的问题在生产环境爆发，幸好已经有其他人躺过坑，所以问题立马就处理掉了。 条件允许，请解决所有的警告，如果条件有限，经常查看警告信息，重视新出现的警告信息。
代码洁癖——代码一定要追求完美
很多人都经历过接手别人的代码，而且程序员最害怕的就是阅读别人的代码。不管是别人的代码还是自己的代码，都要习惯性去重构，代码这门艺术不是一蹴而就的，是需要慢慢雕琢出来的。如果在开发过程中，不管是自己的代码还是别人的代码，发现问题，一定要去解决这些脏东西。代码是积累的过程，不合适的代码应该在初期就优化掉，如果越积越多，到最后只有可能是“没时间优化”和“不敢优化”。 在重构的过程中，总是会有很多理由让自己放弃这一操作，最多的两个理由就是：“没时间”和“风险太大”，持续衍生下下去，最后唯一的结果就是系统重新开发。这就是很多公司业务只是停滞不前或者稳步提升的，但是系统使用不到2年就要重做的原因。
代码的最终结果是变成成果——一定要定义deadline
工作是永远做不完的，但是项目必须定义deadline，即使在没有明确考核的情况下，自己也需要给自己定义deadline，一个项目耗的太久，会让项目的弱势越来越严重，会让成本越来越高，会让开发人员的编码效率低下，所有的开发任务一定要定义deadline。 定义deadline还有一个好处，就是能有成果展现，这个对于企业来说，是非常重要的。技术、知识、能力一定要变现成成果，即使是做技术研究，也需要有成果的展示，而不能一直处理进行中的状态，这种意识是非常重要的。
关于集成
测试代码是节省时间，而不是影响进度
一定要写测试用例。测试用例绝对不会浪费你的时间，测试用例觉得不会拖慢项目的进度，而且能加快项目的进度，进度不是开发完了，就完成，你要协助测试，保证项目上线。项目的进度才是真正的进度。测试用例实施起来困难的地方就是无法坚持下来。即使，自己对自己写出来的代码负责，即使公司没有要求，自己也要习惯写测试用例。大家可以看看那些好的开源代码，都是会有自己编写的测试用例的。
现在的开发方式基本都是前后端分离，不管是web还是app，都是通过api进行数据对接，对于测试用例也更加容易测试，所有的接口都需要有对应的测试用例，如果不愿意写代码，测试工具也是有可以替代代码编程的。对于开发人员，其实写代码测试可能体验会更好，速度更加快，测试工具更多的是面向测试工程师。
自动化测试是增强自信的最佳方式
- 自动化测试是必要的 随着时间的推移，系统的功能越来越多，功能越多其实意味着风险越大，出问题的可能性越来越大。随着系统的变大，人工覆盖的范围有限，自动化测试是必须要做的。
- 自动化测试应该提前规划 初期，通过人工基本可以覆盖所有的测试，但是后期功能越来越多，不仅要测试新功能，每个功能的开发都要进行全系统的回归测试。前文提到测试用例，这个是自动化测试的基础。有了强大的测试用例的积累，自动化测试的搭建就会更加容易。测试用例不是等到有时间，或者系统变大以后才做的，而是应该一开始就准备，不要等到系统变得非常庞大臃肿的时候才开始做，那时候你还需要重新会想当初的业务场景，得不偿失。
代码也随时处于能被发布的状态
现在的开发方式都倾向于敏捷开发，敏捷开发的优势这里就不多说了，但是敏捷开发有一个特点就是高频率的发布，所以代码应该是需要随时都处于能被发布的状态，其实这并不是很难，只要合理的使用CVS工具即可。
- 永远有一个和线上代码一直的版本。 不要一个版本走到黑啊，一定要熟悉分支的作用。
- fix bug采用独立版本合并发布。采用最小发布的方式，也就是需要哪几个文件就合并哪几个文件。
- 建立一个灰度发布的环境，作为发布前验证的环境，和生产的环境一样，只是地址只有内部人员知道。当然，如果可以通过Nginx或者网关控制灰度发布，就最好了。
关于协作
代码是共享的，你的代码大家应该都能修改
作为公司代码的贡献者，不管你是总监、经理、架构还是程序员，不要认为自己的代码是别人不能修改，代码应该是共享的，只要在公司授权的范围内，我们应该是可以互相修改别人的模块。
- 互相修改代码其实是代码审查的一个过程。
- 互相修改代码便于互相熟悉业务。
在代码面前人人平等，谁写的代码都会有问题，有重构的空间，不能因为你的职位高或者经验足，就不让别人碰你的代码。 当然，有的人可能会改坏你的代码，但是这个可以通过沟通解决这个问题。
有时，我们过多的关注了技术知识体系本身，却忽略了把自己的技术知识更好的运用到工作中，运用到自己的系统中，因为这些东西除了学习相关的技能，更多的是需要自己总结，随时趟过的坑越多，可能总结的东西越多，罗马不是一天建造的，系统也是不是一次就完美的，我们自己的知识体系也需要时间去积累。
