技术总监谈好的程序员如何写代码
转自：风轻扬官方博客要判断一个程序员是不是好的程序员，主要看他写的代码，因为程序员最重要的事是写代码。
即便不去理解代码的意图，只要看一眼，好的程序员写的代码与差的程序员写的代码基本上就可以看出来。好的程序员写的代码，整洁而规范，视觉上自然有一种美感。空白错落有致，注释恰到好处，命名和排版遵守统一的规范。差的程序员写的代码则经常出现过长的函数，前后不一致的命名方式和排版，过深的嵌套结构，非常复杂的表达式，随处可见的数字等毛病。
再去粗粗阅读，对好的程序员还是差的程序员就会更有把握。好的程序员写的代码，有一种精心雕琢而成的一致性。好的程序员一致会遵守统一的命名方式，如camelCase，而差的程序员的变量命名时不时的就会偏离统一规范。好的程序员的代码中拼写错误几乎不可见，而差的程序员的拼写错误要多得多。好的程序员对于同一类动作，不会忽而用这个动词，忽而又用那个同义词，如add/insert混用。好的程序员采用一致的简写规则，差的程序员则时而不简写，时而简写。好的程序员会很注意名称中形容词与名词谁在前谁在后，而差的程序员没有规则，时而在前时而在后。好的程序员很少会写出大段大段的重复代码，差的程序员却经常搞不定重复代码，他们难以将重复的代码抽取出一个统一的概念进行重用。好的程序员对于对外的API会注重注释与代码的一致性，差的程序员经常注释中的参数名称与函数定义都不一致。好的程序员很少会留下被注释掉的或用#if 0括起的垃圾代码，他们意志坚决，代码有用就要，没用就不要，差的程序员则不一样，他们经常不确信一段代码是否真的需要，他们缺乏保持代码整洁的习惯，因此他们让垃圾代码留着。
如上，即便你不懂他所用的语言，不却关心程序的逻辑，对好的程序员还是差的程序员就能做到八九不离十的判断。程序的好坏几乎总是取决于它们是否“漂亮”，不“漂亮”而好的程序，除了C++ STL源码，我再也没见过（如果你稍仔细看，STL的源码虽然不够“漂亮”，但仍然满足这里提出的一致性原则）。而又好又“漂亮”的代码则随处可见，如Linux Kernel，InnoDB，JDK，JUnit等等。
如果再仔细阅读，就能更准确。好的程序员写的代码，好似浑然天成，简单而直白。函数通常较短小，函数的名称准确的反映函数要完成的工作。逻辑简单而自然，让你读的时候由衷的发出“啊，就应该是这样”的感叹，而差的程序员的代码经常让你发出“怎么是这样？这是再干什么呀？”的疑问。好的程序员会在紧要关头加以画龙点睛般的注释，差的程序员要么没注释，要么注释只是代码的重复，纯粹是废话，更差的是注释是错的，是误导。
好的程序员未必是“语言律师”，即那种非常清楚的了解语言的各个细节，在编程时到处使用的家伙。好的程序员也不常“炫技”，在代码中精心构造一些独具匠心的片断，他们偶而会，但大多数时候总是用直白的语言来表述。
从代码也可以看出一个程序员的团队协作精神。注意团队合作的程序员，会严格按照团队规范写代码，而风格与团队规范不一致的程序员则很可能欠缺团队精神。注意团队合作的程序员会注意给模块的对外接口加以重要的说明，如前置条件、后置条件、参数能否是NULL等等，不注意团队合作的程序员懒于处理这些细节。
好的程序员与差的程序员的生产力差别巨大，项目的周期越长，项目越复杂，项目对质量的要求越高，好的程序员的价值就越大。好的程序员与差的程序员，管理成本也差别巨大，好的程序员只需要与他共同确定设计，代码可以不看，差的程序员的代码经常需要经过多次review，且仍有可能达不到理想的质量。
要成为好的程序员，首先要树立要成为好的程序员的志向，再勤加练习，天长日久，就会越来越好，这些人不怕老。没有志向永远成不了好的程序员，这些人若不在老去之前成为经理就会变成废人。
通过两个小时的笔试和半个小时的面试对于判断程序员来说是不够的。通过笔试与面试，你可以判断一个程序员是否具备算法与数据结构等基础知识，可以判断他对编程语言的特性是否掌握，可以判断他对技术是否关注，然而要知道他能否真的能很好的完成工作，不写代码是不够的。
那些显得对技术充满热情的，未必是好的程序员。这些人可能非常乐意从事有新意的工作，但后续的编码、测试、调试、文案工作则可能让他们感到厌烦。他们可能会提出好的创意，但却经常不能够有始有终的将其完成。公司不需要多少这样的人。
因此招聘的方式需要改善。招聘是最重要的，因为进来后就难以出去，即便是试用。转正条件白纸黑字写的很清楚，只要合格就可以转正，要达到合格并不是很困难。今年部门里进了很多新人，并不是人人都很优秀，但确实也都合格，自然也应该转正。
改善招聘的方法，就是让他写程序，可以出两道题，一道让他写程序，一道让他重构一个已有的较长的程序，一天之内完成。假使可以考他半个月，那么重构是不太需要的，但一天的时间太短，通过重构可以考察阅读并理解代码，并通过重构“化腐朽为神奇”的能力。那些不愿意写别人的代码，不愿意接受别人的代码，经常要重来一遍的人是不理想的。
今年有两个人采用了类似的方法。有一位简历很优秀的人，做了两道编程题被拒了，有一位简历及面试一般的人，通过编程测试，录用了。我感觉比单纯的笔试与面试要准确。 从 CSDN 上读到这个帖子，感觉非常不错，所以与大家分享。
最初的标题是《怎么样才是好的程序员》，但大多数网站转载采用了现在的标题，也还算贴切。 学习了，我打算按上面谈到的付诸实践 nice job
csdn上还有很多这种文章
《漫谈程序的效率和水平（一）》（2009/12/26）
Posted on 2009-12-28 08:19 n216 阅读(1856) 评论(38)编辑 收藏 网摘 所属分类: EOM与程序员
程序的效率和水平常常被挂在程序员的嘴边。他们推崇高效的程序，他们把运行快的程序看成水平高的程序。但是很多程序员并不清楚什么是高效的程序，如何才能编制高效的程序。他们把编制高效程序看作一种奢望、一种追求。
程序运行的快和慢是需要比较的，其前提是相比的程序必须是要完成相同的功能，而且程序运行的硬件环境和软件环境必须一样。不同的人因其程序的不同，程序运行的时间就不同。因此，程序就有了差距。即使相同的人，因对程序进行了完善和变更，也同样会导致程序的不同，进而导致了程序运行时间的不同。没有这些前提谈论程序的效率是没有意义的。
我们不能一概而论的认为，程序越快越好。不同程序对效率的要求是不相同的。现在许多程序员只知道程序越快越好；不知道程序效率改进是一个无止境的过程；不知道程序的快慢是有一个度的；不知道人们对效率的追求是需要成本的；不知道程序快慢与用户感受相关的。而这些正是我最为担心的。我认为无论什么程序只要有用户使用才有价值，用户的感受才是程序效率的目标。只有树立这个目标之后，我们改进程序效率才会有动力，我们改进程序效率才有一个尽头。我们可以把程序归为三种情况：
1、 批处理
是指系统业务功能终止后或其它事物终了后，对其终了前的数据进行加工的过程，这个过程可能涉及到多个程序。有的批处理时间很长几小时到十几小时都有，有的批处理需要几分钟到几十分钟。批处理时间主要涉及到数据量的大小、处理结果的大小、处理逻辑和处理逻辑实现。其中处理逻辑的实现就是批处理程序。一般而言，数据量大、处理结果内容多、处理逻辑复杂程序运行时间就长。要特别指出的有的批处理时间会超过24小时，影响企业第二天的业务系统的运行，这样批处理就会对企业业务产生很重大的影响。
不同的批处理程序的编写能使批处理时间延长和缩短。例如，A程序员编写这个批处理程序需要10个小时，B程序员编写这个程序只要5个小时、C程序员可能要20个小时。可见程序的效率是多么的重要，也难怪许多人认为程序效率高就是水平高呢。
2、 联机功能
联机功能是指操作人员使用一个联机的应用系统中运行一个业务功能。例如，信息计算、保存信息、查询信息、打印信息等。
联机功能运行时间应该是有限的，应该是以秒和分钟为单位的，不象批处理是以小时为单位。因为操作人员始终处于等待状态，他们是无法容忍长时间等待的。正因为如此，对于程序员来说虽然缩短时间要求不象批处理那样长，但是总体时间要在限定的几分钟内，这样程序员压力就更大了。
3、 单个程序
单个程序是指为了某种数学运算或数据处理或其它处理编制的一个程序。这种程序的特点是一个人操作；运行到结束就是一个周期。例如：显示hello word程序、进行积分程序、从串口读出数据程序。单个程序的运行时间就很难说了可以用0-无限来表示。
很多单个程序都是由程序员一人来完成的，因此，其运行时间长短只能由其自己的程序的改进来感知。
无论程序在什么情况下我都认为，对程序的效率评判权应该交给使用程序的操作人员，而不是程序员。很多程序员占在自己的角度上认为自己的程序已经编得很好了，没有办法再缩短时间了，这种想法是很错误的。程序员应该提高自己编程能力，使得程序能够在操作人员可容忍的时间内完成。从理论上来说，只有运行时间无限延长的程序，没有运行时间不可缩短的程序
例如，我们在编写批处理的时候，客户的容忍度是4个小时，你编的程序已经达到了1个小时，那你就不必再花时间修改你的程序达到半个小时。（除非你的时间足够多）。
又例如，我们在编制联机处理的时候，客户容忍度是2秒钟，但是你现在的程序要运行1分钟，那你就有必要去修改你的程序，尽量达到客户的要求。
又例如，我们在编制单个程序时候，我们就是为了练习编写程序，重点在程序的功能实现上，而不太关心，程序的效率。那我们就没有必要去花时间修改自己的程序。（等自己会编程序后再来考虑程序效率的问题）
以上就是要帮程序员树立不同程序的容忍度。有了这个容忍度我们再来看看我们如何在这个容忍度之中提高自己的程序效率。
下篇：《漫谈程序的效率和水平（二）》
《漫谈程序的效率和水平（二）》（2009/12/28）
Posted on 2009-12-30 09:00 n216 阅读(1728) 评论(30)编辑 收藏 网摘 所属分类: EOM与程序员
上篇主要谈了提高程序效率要考虑满足用户的容忍度的问题，现在我们言归正传谈谈如何提高程序的效率问题。提高程序的效率涉及到计算机基础知识、涉及到编程经验、涉及到程序硬件环境和软件环境、涉及到资金成本和时间等各个方面。依我的经验提高程序效率要从以下几个方面入手：
一、 程序要简短
程序的效率本质是执行可执行代码（汇编指令）的次数。这一点是关键的关键，程序员一定要牢记心中。程序越简短，其可执行代码就越少，就越有效率（如果程序是串行操作的话）。因此，我们在编写过程化程序的时候，要尽量改进我们的算法，让语句最少，源程序语句减少可以导致可执行代码减少。
1） 不要编写一些不起作用的“废话”：例如，定义了不必要的变量，
2） 不要编写了不起作用的语句（有可能忘记注释掉的）。
3） 不要编写不可能出现各种例外的判断语句。
4） 不要编写能够一条语句能实现的功能非要用3条4条语句来实现。
5） 改进程序算法，改进算法其中最重要的一条，就是减少语句。
但是并不总是是程序短，时间就短。例如，我们可以编制3条导致死循环的语句。程序很短，但是时间确是很长。其根本原因就是虽然可执行代码行数很短，但是执行可执行代码次数是无穷的。
记得在过去，有时候会把各自程序（相同功能）拿出来比一比，看谁的程序最短。那怕有一条语句的减少都是被认为很了不起。所以“惜墨如金”程序员必需时刻牢记。长此过往，程序员就会养成一个良好的习惯。
我发现现在许多程序员，资源意识很淡漠，仿佛程序设计语言中所有资源都可以任意使用，不需付代价，不需要理由。这种挥霍性的编程是一个不好的习惯，它会严重影响程序的效率。
二、减少循环内操作
循环语句是影响程序效率最重要的原因之一，这里循环语句一个是指程序员自己编写的，另一个是指程序调用的函数中使用的循环语句。
1、 程序员编写的循环语句首先要尽可能减少循环次数，减少循环次数，可以减少程序运行时间。第二，尽量减少循环内无用的操作，能在循环外执行的语句，就在循环外执行，第三，尽量减少嵌套循环，因为循环中的循环是两循环次数相乘的关系。若有可能可以变嵌套循环为顺序循环，顺序循环是两循环次数相加。
2、 程序员要能知道自己调用的各种函数中可能出现的循环操作，通过参数，尽量避免循环次数的增加。例如查找子串函数，一定是包含循环操作的。程序员在使用这个函数的时候，一定要尽量减少被查找的字符串的长度，增加查找的字符串的长度。这样循环查找的次数就会减少。
三、充分利用内存
利用内存是提高程序效率的非常有效的方法，通过使用内存，我们可以缓存许多需要再加工的数据，无须进行I/O交换，这样就可以提高程序的效率了。另外，我们可以利用内存建立数据的索引，加快数据查询的速度，从而提高了程序效率。
四、减少I/O操作
很多情况下I/O操作是影响程序效率的最重要的原因，尤其是数据库大数据量操作更是明显。我们可以建立通过建立表分区、表索引的方式来提高数据操作效率，这些方法本质是都是通过减少I/O操作来获取操作效率的。
减少I/O操作有很多技巧和方法，但是无论哪种方法都是要把I/O操作减少到最低。
例如，我们要输出1000万条记录到一个文本文件。一般的做法是形成一条记录写一次文件。如果，我们能形成1000条记录后，写一次文件，那么我们只要写1万次就可以了（其实上写文件还是很复杂的，它跟系统写缓冲区大小和硬盘本身结构有关）。这样程序效率就会有很大的提高。
又例如，我们可以用低级文件打开放式代替流文件打开方式，这样效率会更快些。因为流处理最终还是要调用低级打开的。
五、提高调用效率
在程序中，我们大量地调用系统函数、调用自己写的函数、调用各种引用的函数。这些函数的运行时间我们是无法改变的。因此我们要提高程序效率，我们
1）可以考虑使用功能相同但是运行时间较短的函数。
2）我们还可以自己编写一些函数替代系统函数或引用的函数，因为自己编制的函数所考虑因素比较少，功能比较直接，不需要考虑很多例外情况，程序代码要比其他函数要少的多。
六、使用全程变量
全程变量的使用可以减少参数的传递所花费的时间。参数传递在可执行代码中是需要花上PUSH（压栈）和POP（出栈）时间的。
但是，我不提倡使用全程变量，如果使用全程变量不能大幅度提高效率的话，还不如不用。但是，如果能够大幅度提高效率的话，使用全程变量也不失一种方法。
当以上的努力还不能使得程序效率达到用户容忍度的时候，还可以从更高层面提高程序的效率：
一、提高硬件环境
提高计算机的内存大小、提高CPU性能、提高I/O吞吐能力、提高网络吞吐能力等硬件性能都能够提高程序的运行效率。
二、选择更接近底层的程序设计语言
这个道理是不言而喻的。
三、采用多机分布并行处理
可以把处理内容进行多机、分布、并行处理，这样也可以大大提高程序效率。
以上方法会导致更高的企业成本，关键是企业要评估其性价比。
一般人认为程序效率高，程序的水平就高。但是，我们也看到为了提高效率，我们可能就会更多地使用全程变量，就会申请更多的内存，就有可能破坏程序的结构，这样程序的水平就会降低。一个好的程序不但外在要有好的效率，而且内在要有好的结构，要有最佳的内存效率比。高水平的程序一定是高效率的，但高效率程序并不总是高水平的。
很多人会问还有没有其它提高程序效率的方法，我的回答是肯定的。例如我们可以在可执行程序中嵌入汇编程序，以提高程序的效率。但是，这不是常态的做法，程序员只要了解就行了。
大部分程序员只会使用语言编写程序，但不知道这个源程序究竟是如何变成可执行代码、变成什么可执行代码，这些可执行代码的执行时间是长是短。因此，要从根本上提高程序的效率，需要程序员深懂源程序到可执行程序的过程，深懂编译原理、深懂汇编语言、深懂汇编中的系统调用。对于数据库而言，程序员要深懂数据库原理、深懂数据存放方式和数据查询方式，深懂数据库操作与I/O操作与内存的关系。而这些深懂是需要长时间编程积累的。这就是我为什么说程序效率的提高是无止尽的原因了。
这个话题内容太多，太细，我也无法深入去写，尤其是后半部分，写的匆忙，只能起抛砖引玉的作用了。
下篇：《大项目、小项目都是程序员成熟之道》 囧……
发现我之前贴上来的代码完全不符合要求。
1.变量名和函数名太随意，不符合规范。
2.没有注意重复代码的抽取。
3.没有注意排版。
4.没有注释。
5.没有注意节约内存资源。
以后我会注意的。
页:
[1]