谈谈编程修养

      那么编程修养是什么？

     举一个反例，就拿我最近接手的一个企业级的后台网络服务程序来说，这个程序承载了整个公司核心产品的核心技术，但是当我拿到源代码时，我却有不尽的失望，甚至有些愤怒，也觉得对公司来说是一种幸运。是的，不可否认的，你给大家展示的是你可以承受得起10万级的访问量，可以正常的运转公司的业务。但是内在的呈现上，给人的第一感觉就是杂乱和缺乏专业性。

      我对此程序看法如下：

    1.各种文档一无所有；

    2.上万行代码就在两个cpp文件中完成，其中的main方法甚是可怕,四个重要功能逻辑的实现几乎全在其中，多达2000多行；

    3.很多逻辑并未考虑到执行不成功的情况就继续执行下面的逻辑；

    4.大量使用全局变量，并且有些并未在全局使用；

   

    5.作为一个庞大重要的后台服务程序，没有一套完善的日志系统；

    6.对于多达几十个上百个的功能逻辑竟然没有一套完善的测试系统；

    7.“don't repeat yourself"这个金率在程序中未任何体现；

    8.既然用c++来编写程序，几乎未面向对象的使用，甚至连STl都很少见；

    9.代码注释风格，命名风格杂乱，未使用的代码逻辑还有一堆；

    这些就是我对这个程序的感悟，我认为以我的观点来看以上都是没有编程修养的体现。固然，可以拿这个程序已经很稳定的跑了多久多久，而且没有出过业务上的差错或者当时时间有多么紧来对上述问题开脱。但是作为一个程序员的我们仅仅是为了完成产品的需求功能？从商业上来分析这种观点没错，一个程序代码写得多么好，配套设施多么完善，体现的多么专业，但是不能创造市场价值等于这程序就是堆”垃圾“，但是我们也不能写出”垃圾“一样的程序。我认为，但凡垃圾的程序产生的效益都是短暂的，而且是运气的；

    我下面以我的观点的分析一下可能对产品造成的不良影响：

   1.从维护上来看，如果维护人员是这个程序的始创者，好办些，毕竟这程序即使再乱。维护者毕竟了解它，可以相对比较快的完成维护工作，但是大家不知道有没有这种经历，小时候为了记全笔记有时候会写草字，但是下次自己再看时却很费劲，即使程序始创者维护这样的程序也会费些时间吧。那对一个起初对程序一无所知的人呢，我想一定会多花很多不该花费的时间去消化这个程序的逻辑和业务。这显然已经影响到了维护成本。

   2.从定位问题上看，大家都知道的，对于一个服务端的程序，一旦出问题会影响到千千万万的客户端，既然这样，我们就要能快速准确的定位出问题所在，然后迅速解决它，使其损失达到最小。对于不便于现场调试的情况，最有效的方式就是在程序运行时有一个稳定，高效，完善的日志系统。这样大部分情况下我们可以通过日志记录的一些数据或者信息提示再结合自身的代码定位到问题。

   3.从功能上看，最严重的我认为就是很多逻辑没有考虑到执行失败的情况就继续执行下面有依赖的逻辑，是的，肯定你会反驳我“他肯定是成功的，为什么会失败呢，我是按照指定的路径读的文件，我就没发现过这个API调用失败过“，我不得不得奉劝这种人一句，你该看看《代码大全》了，其中有一章防御式编程会教育你的。

   4.从作为一个程序员的职业道德上来看，你写出这样的代码只是为了给机器读？你要记住，对于机器来说你的代码只是二进制，你写的再烂机器只看到0和1，而你写的代码是要给别的程序员看的，去维护，去改进，去移植的，所以请你有些职业道德，别给别人增加不必要的负担。

    说到这里，我想肯定有些人会觉得委屈，因为”我们是新手“。这个原因我放在下面谈，因为我觉得新手写出这样的程序很正常，我也曾经写过让现在的自己觉得很垃圾的程序。另一个原因就是“公司给的时间太紧，我只好匆匆写完”，我觉得这只是一个方面，我必须要吐槽一下现在的很多IT公司，不再注重一个人是不是能写出优秀的代码和维护一套科学的产品流程，也不再注重产出的代码的质量和产品的高标准，而是把衡量一个人和产品的标准完全放在了实现的功能和创造的市场效益上，我也知道这是市场规则，但是请尊重那些把代码和产品不仅仅当做赚钱工具的人，因为他们在写代码做产品时更想把他当做一个艺术品，会仔细设计雕磨，会让他尽量完美。还有，对于新手，允许他们犯错，但是请不要把他们犯的错用在公司的核心产品和技术上，因为这种成本有些大了。

    所以我想对广大和我一样热爱技术的程序员说，我们不仅仅要做一个能实现功能做出产品的程序员，还要做有编程修养的程序员。也建议大家读读我对开展一个项目的薄见， 你们的团队是怎样组织开展大型项目的？

本文转自永远的朋友博客51CTO博客，原文链接http://blog.51cto.com/yaocoder/886393如需转载请自行联系原作者

yaocoder