如何做好程序员
漫谈程序员
《编程之道》[James] 是一本在全世界流传的关于程序员的寓言，讲的是早期程序员的故事，风趣而富有哲理。好笑的是书中很多观点现在看来明显是错误的甚至是荒唐的。但这毕竟是赞美程序员的书啊，怎么看都觉得错得有理，傻得可爱。于是大家心照不宣，乐呵呵地传阅，智者一笑了之，稚者信以为真。
早期的程序员干活能从软件直通硬件，个个生猛无比。又因他们的作息时间、言行举止与常人不太一样，久而久之就给人们留下了“神秘”、“孤僻”的印象。
如今软件行业被炒得热火朝天，有能耐的程序员即便躲在大山岙的军工厂里也能被挖出来。而更多原本不会编程的人操起几本“速成”、“二十一天通”等书籍也加入了这个行业。现在国内号称有上百万程序员，这支大军鱼龙混杂，已搞不清哪些是正规军，哪些是游击队了。
真正的程序员有如下秉性：
（1）诚实
程序员在学习与工作期间几乎天天与机器打交道，压根就没有受欺骗或欺骗人的机会。勤奋的程序员在调试无穷多的Bug时，已经深深地接受了“诚实”的教育。不诚实的人，他肯定不想做、也做不好程序员。
有一名市场营销员和一名程序员都在新闻发布会上发言，将一项新技术的消息公布于众。
市场营销员说：“这项技术比电话、晶体管和原子弹三项发明加起来对世界文明的影响都要大。”
程序员说：“这项技术在有限的领域内，在有限的程度上，解决了一些技术性的问题。”
看来为了让我们的民族更加诚实，学电脑真的要从娃娃抓起。
（2）信奉简单实用主义
有人问一个数学家、一个物理学家和一名程序员：“一个盒子有几个面？”
数学家回答说：“有6个面，因为盒子是长方体。”
物理学家回答说：“有12个面，分为6个外表面和6个内表面 。”
程序员回答说：“只有两个面，里面放电路板和硬盘，外面放显示器和键盘。”
程序员的基本工作就是把复杂的问题转化为计算机能处理的一些简单的程序。如果一个问题复杂到连程序员自己都不能理解，他就无法编写出程序让更笨的计算机来处理。
也有不少做计算机“学问”的人颠倒行事。本来几句话、几行程序就能说明白的事，非得要抬高到理论创新的程度，写成玄乎的文章去评职称或混学位。幸好在第一线工作的程序员大多是实干的。
（3）喜欢技术挑战
程序员大都喜欢技术挑战，不喜欢搞测试与维护。高水平的程序员喜欢与高水平的程序员一起工作，因为他们怕“与臭棋佬下棋，棋越下越臭”。
“喜欢技术挑战”听起来是好事，但实际上未必都是好事。有时候这种喜好常常导致程序员干活偏离项目真正的需求。
（4）工作单调但不乏味
有人问编程大师：“程序设计的真正含义是什么 ？”
大师回答说：“饿了的时候就吃，困的时候就睡，只要时机恰当就进行程序设计。”
其实程序员的生活和编程已融为一体，尽管单调却不乏味，还能独享孤独。有诗为证：
我编程三日
两耳不闻人声
只有硬盘在歌唱
程序员小结：“编程”是程序员的基本任务但不是惟一的任务。水平高的程序员通常从事分析、设计、编程等技术难度较高的工作。而水平较“臭”的程序员将“沦落”到只干测试、维护等工作。优秀的程序员没有理由不让人喜欢，他们远比怪僻来得可爱。
职 业 道 德
美国电气电子工程师协会（IEEE）和美国计算机协会（ACM）于1994年联合制定了软件行业职业道德准则：“Software Engineering Code of Ethic and Professional Practice”，将此作为工业决策、职业认证和教学工作的参考。
本节不讲太多道貌岸然的话。化繁为简，作者自己总结了关于程序员职业道德的“三不”准则，按从轻至重的顺序论述。
上班时间不干与工作无关的事情
老板给程序员发工资，并不是让他们来享受的，而是希望他们创造比工资多得多的效益。所以要求程序员“在上班时间不干与工作无关的事情”是合情合理的。
争议在于什么算是“与工作无关”的事情。
从哲学角度讲世间万物都是相关的，怎么可以说我干的事“与工作无关”呢。由于对相关或无关的“度”不好把握，上述“准则”难以得到理想的贯彻，还得靠人们的自觉性。
上班时收发私人电子邮件或者打私人电话，行不行？按规定是不允许的。但万一有重要的私事，总不能不处理吧，于是就有了违反规定的理由。可是谁会觉得自己的私事不重要呢？
鉴于此，很多公司会对电子邮件和电话的使用设置权限，高级别的员工自由度大，低级别的员工自由度小。有一些公司对员工的电子邮件进行监视，但这样做会侵犯隐私，可能会引起纠纷。
也有人在上班时学英语，准备考这考那。这比收发私人电子邮件要严重，若被管理人员发现是要挨训的。这类事情不少见，建议从两个方面看问题：
（1）如果员工有意不干正经活，应按怠工处理。
（2）在人浮于事的大公司里，有不少员工的确很清闲，与其让他荒废时间还不如让他多学点知识。我从来不反对学习新东西，对那些无“正事”可干、只好偷着学其他知识的同事深表理解，于是我就睁只眼闭只眼。我认为发生这类事情的原因在于领导的失职，而不是“犯规”者的错。
如果有人在上班时间玩游戏，不要让他找借口，一定要及时制止甚至做出处罚，因为影响太坏。除非他的工作就是开发或者推销游戏软件。
下班后呆在公司里干与工作无关的事情行不行？
这个问题不好回答。我所在的公司比较“客气”，只要你不干坏事，那是允许的。
我曾看到某个大公司有这样的规定：在公司里每天24小时不得干与工作无关的事情。
这个规定不但冷酷而且荒谬，正常人在每天24小时之内总得大小便吧！
不损害集体利益
从小学开始，学生守则里头就有“不损害集体利益”的条文。
出于嫉妒或者仇恨而有意去破坏集体利益的，这类人的心理不太正常，不在本书讨论之列。
在IT企业里，损害集体利益的常见行为有两类：一是泄密，二是盗卖成果。
泄密有两种：一是无意的，二是有意的。
无意的泄密比较常见，主要原因有：
（1）不同的人在判断某东西“是否属于机密”时的看法不尽相同。不少工作成果具有实用价值但没有创新意义，商业人士认为它应当被保密，而在技术人员眼里它可能算不上是机密而被随意处置。
（2）IT行业人士需要经常与外界交流，“闭门造车”很难做出好产品。“交流”自然会涉及有价值的东西，老谈些众所周知的事情不能算“交流”，那叫“唠叨”。同行之间交流时显然不会捧着教科书朗读，有意义的交流通常聚焦在“如何解决企业面临的实际问题”上，难免会泄漏公司机密。
说来惭愧，我自己都无法避免无意识泄密。我经常做讲座，写技术性文章和书籍，在很多场合有人向我要电子文档，人们向我要东西是看得起我，我怎么可以不把东西给他们呢？
减少无意泄密的措施有：
（1）对新员工进行入公司培训时，灌输保密意识。
（2）加强保密管理，堵住通信漏洞。
在IT企业里，如果有人存心泄密或者盗卖成果，一般是防不住的。如果发生这类事件，应当诉诸法律，使肇事者得到应有的惩罚。
我不建议企业为了保密而制定非常严格的管理制度，因为这样做会给大部分守法的员工造成不便，而事实上却又防不住那小部分“家贼”。
不干危害社会的事情
软件病毒防不胜防，常令受害者“无缘无故”地遭受损失。由于病毒对社会的危害极大。制造病毒被认为是犯罪行为。
黑客的行为通常是有针对性的，不像病毒那样“六亲不认”，对社会的危害比病毒轻些。但不论黑客是在搞恶作剧还是在犯罪，其快乐是建立在别人的痛苦之上的。正直的程序员不该去造病毒或者当黑客。
黑客有些时候也干一些正义的恶作剧，所以不可一概而论地谴责他们。
不少人当黑客并不是想获取经济利益，而是为了寻求技术刺激。有些大学生把黑客当成技术天才来崇拜，争相模仿，这种念头会令更多的人误入歧途。
尽管找不出堂皇的理由，我还是要规劝程序员不要去当黑客。且不论黑客性质好坏，每个人总得考虑自己的前途吧？人不能一辈子当黑客，当他有了家小后，他总该设法找个好职业挣钱养家吧？
大部分黑客的致命缺点是综合才能不够强。由于天天想着搞破坏，他们很少有机会、有耐心去开发大型的软件系统，因此系统分析、系统设计的才能比较差，更别谈项目管理和企业管理了。但是如果综合才能不够强，他怎么能够获得很好的职位呢？前途岂不黯淡？
黑客们原本智力不错，很有发展潜力，但是心用歪了，自己断绝了提高综合才能的道路。不少年轻人之所以崇拜黑客，是因为他们还太幼稚，体会不到干事业的艰辛，尚不能分辨“狗熊”和“英雄”。为了防止人们误入歧途，以及挽救已入歧途的人们，软件业界有责任在任何场合消灭“黑客光荣”的邪念。
有位小姐找了一名技术不错的程序员做男朋友，她常对大伙说：“要是我男朋友是一名黑客，我会更加自豪的。”
后来她结婚了还在感叹：“要是我老公能成为一名黑客那该多好啊！”
这事情发生在我家里，真是个讽刺！
┅┅
命名规则
比较著名的命名规则当推Microsoft公司的“匈牙利”法，该命名规则的主要思想是“在变量和函数名中加入前缀以增进人们对程序的理解”。例如所有的字符变量均以ch为前缀，若是指针变量则追加前缀p。如果一个变量由ppch开头，则表明它是指向字符指针的指针。
“匈牙利”法最大的缺点是烦琐，例如
int i, j, k;
float x, y, z;
倘若采用“匈牙利”命名规则，则应当写成
int iI, iJ, ik; // 前缀 i表示int类型
float fX, fY, fZ; // 前缀 f表示float类型
如此烦琐的程序会让绝大多数程序员无法忍受。
本节论述的共性规则是被大多数程序员采纳的，我们应当在遵循这些共性规则的前提下，再扩充特定的规则（参见7.2节）。
共 性 规 则
本节论述的共性规则是被大多数程序员采纳的，我们应当在遵循这些共性规则的前提下，再扩充特定的规则（参见7.2节）。
规则1：直观且可以拼读，可望文知义，不必进行“解码”。标识符最好采用英文单词或其组合，便于记忆和阅读。切忌使用汉语拼音来命名。程序中的英文单词一般不会太复杂，用词应当准确。例如不要把CurrentValue写成NowValue。
规则2： 标识符的长度应当符合“min-length && max-information”原则。几十年前老ANSI C规定名字不准超过6个字符，现今的C++/C不再有此限制。一般来说，长名字能更好地表达含义，所以函数名、变量名、类名长达十几个字符不足为怪。那么名字是否越长越好？不见得！例如变量名maxval就比maxValueUntilOverflow好用。单字符的名字也是有用的，常见的如i,j,k,m,n,x,y,z等，它们通常可用做函数内的局部变量。
规则3：命名规则尽量与所采用的操作系统或开发工具的风格保持一致。例如Windows应用程序的标识符通常采用“大小写”混排的方式，如AddChild。而UNIX应用程序的标识符通常采用“小写加下划线”的方式，如add_child。别把这两类风格混在一起用。
规则4：程序中不要出现仅靠大小写区分的相似的标识符。例如：
int x, X; // 变量x 与 X 容易混淆
void foo(int x); // 函数foo 与FOO容易混淆
void FOO(float x);
规则5：程序中不要出现标识符完全相同的局部变量和全局变量，尽管两者的作用域不同而不会发生语法错误，但会使人误解。
规则6：变量的名字应当使用“名词”或者“形容词＋名词”。例如：
float value;
float oldValue;
float newValue;
规则7：全局函数的名字应当使用“动词”或者“动词＋名词”（动宾词组）。类的成员函数应当只使用“动词”，被省略掉的名词就是对象本身。例如：
DrawBox(); // 全局函数
box－>Draw(); // 类的成员函数
规则8：用正确的反义词组命名具有互斥意义的变量或相反动作的函数等。例如：
int minValue;
int maxValue;
int SetValue(…);
int GetValue(…);
建议1：尽量避免名字中出现数字编号，如Value1,Value2等，除非逻辑上的确需要编号。这是为了防止程序员偷懒，不肯为命名动脑筋而导致产生无意义的名字（因为用数字编号最省事）。就像没有人会把子女的名字叫做张三或李四一样。
┅┅
[ 本帖最后由 王法印 于 2011-10-01 02:53 编辑 ] |
收藏
淘帖
踩
