理想流

经常有小同事和我说，这程序的代码写的太垃圾了，什么水平。确实如此，大部分持续存在一段时间的程序代码质量都不怎么样。从圈复杂度的角度看，超过15的代码就很看了会头疼了，但可怕的是圈复杂度到70,、80的也不是没有。谁要摊上改这种代码，估计上吊的心都有：不改不行，改了谁知道出什么问题？ 从这种代码里能看出来什么，很说明的人的心境。说看到技术水平较差的大多是刚毕业的兄弟。说看到利益纠葛，人心世道的大概就

很多大学里是把软件开发相关的专业划入工科的，这给人一种错觉，让人认为软件开发也是一个工程学科，就像土木建筑，动力机械那样。但这从根本上错了，土木建筑，动力机械的背后有确实的科学定律作为支撑，而软件开发的背后基本上什么都没有，远不是一种“科学”。也正因此，“软件工程”的现实意义也就远不如“土木工程”，“动力工程”。每个人对“科学”的定义可能不同，但在这里，我们可以做一个简化版的定义：当有一组在限定条

程序员这个行业里，加班多似乎已经成为一种共识。好多人是抱着即将“水深火热”的心情加入这个行业的。在任何行业中，不加班是一定不可能的，那程序员可能少加班么？答案是有的时候是可能的，但也是艰难的。在看具体手段前，我们先来看一下加班的原因。导致加班的核心原因可以分为三类：人为的行政上的原因。这可以进一步划分为两类场景：一类是，在有的公司里，不加班被等价于工作不努力。所以不管需不需要，那怕磨洋工也先加了再

软件开发是个奇妙的行业。你可以说它复杂，但与此同时，随便有个人，只要接受点培训就可以做软件开发。你也可以说它简单，但据统计世界上一半以上的软件项目会以失败收场。强调软件复杂的最有代表性的观点来自《人月神话》：Brooks认为复杂性是软件的根本特质，而非偶然特质。强调软件简单性的观点则时见于国内某些MIS开发公司以及外包公司：他们大多时候会把需求分析（业务分析）的权重抬的很高，而把设计编码的位置压的

当一个人看到这么一段话时，他会怎么想：尺度的进程并不仅是无穷进展的坏的无限无止境地采取由质过渡到量，由量过渡到质的形式，而是同时又在其对方里与自身结合的真的无限。质与量在尺度里最初是作为某物与别物而处于互相对立的地位。但质潜在地就是量，反之，量潜在地也即是质。所以当两者在尺度的发展过程里互相过渡到对方时，这两个规定的每一个都只是回复到它已经潜在地是那样的东西。于是我们现在便得到其规定被否定了的、一

有时候正工作呢，突然就会听到两个兄弟声音放大，言辞也开始变的激烈。这事儿实在太常见，以至于不需要具体案例大多数人就能想象到是怎么个场景。现在的关键问题是这个时候经理M应该干点什么？我个人感觉，有两种极端的处理方法一定不太行。一是完全置之不理，就是假装没看见，你们吵成什么样算什么样。一是什么事都管，一有争吵就开始调解，消除所有不“和谐”声音。前者比较失职，工作中，人员间矛盾大多与工作有关，完全不处理

在众多软件相关的知识中，软件工程绝对是很特别的一个。很多人很鄙视软件工程，说：我一看到软件工程的书就直接略过；与之相对应，很多人很推崇软件工程，会花很大的心思去研究敏捷、CMMI等。刚入职场的程序员大致上是讨厌软件工程的，因为这东西离自己的实践有点远，并且主要是添加束缚。 但既然更加复杂纷繁的历史都可以总结出规律，软件开发没道理就总结不出可以遵循的规律。也许真的事实是：并不是软件工程没有用，而实在

程序员由于天天和逻辑打交道，所以在世故的人眼里往往显得过于简单。近来看组织行为学，发现其中一节列了很多特别的技能。考虑到也许他们对程序员群体很有启示意义，就追加了一点说明，把它放在博客里。相信这对想成为管理者的程序员是有意义的。我个人的观点很简单：一个人可以拒绝厚黑和莫名其妙的复杂，但也不能被人认为是傻蛋。从这个角度看，把这个记下来是有点意义的，当然把这个的优先级抬到基本技术技能之上就走火入魔了。

很多人以为提高编码质量，需要很多激动人心的创新，需要明显的飞跃，这也许对，但我个人感觉项目中提高编码质量是个水磨功夫，要一步步积累，方法论大多时候帮助不大。这次先从命名说起。当我们看到一份设计图或一份代码时，大多数人会【望文生义】。但使人【望文生义】却正是语言文字的根本使命。因此，如果一个函数被命名为Add()，但内部实际做的是减法，那么这份设计或者这份代码，一定是很难理解的。于是一个非常现实的问

在1992年，Jack W.Reeves发表了一篇名为：Code as Design的文章，这篇文章可以在《敏捷软件开发 原则、模式与实践》一书的附录中找到。这篇文章的核心观点是：编码也是设计，而软件开发中与建筑行业中的施工所对等的工作，已经被编译器代理了。这是几近20年前的文章，但时至今日，类似的争论仍未休止。好像是在《软件架构设计》里，在讨论架构设计时，作者就点了一句：这总不能说是设计就是编码

对于特定的人，在大致时间段里他所能写的、确定质量的代码基本上应该是个确定值。这点似乎显而易见，但事实上大多时候却总是被忽视。如果项目负责人总是认可上面的基本点，那么任何项目的日程就应该以此为前提，而不是以此为变量。假设说一个项目被估计为1万行(SLOC)，团队平均每人每天可以写100行代码，如果团队中有5个人，那么就应该至少为编码保留20整天。 说到这里，为避免误解，要区分一下编码速度和生产率这两

加班不给加班费的公司违背基本的道义，性质上和抢老大爷养老钱并无不同。一旦处在这种公司里，第一要累积力量，第二要赶紧跳槽，没什么好多想的。今天想说的并不是这个，而是另一个话题：加班给加班费就好么？答案是否定的。假如说每个人毕业的时候都还处在刚刚开始成长的阶段，那么过度加班等于扼杀一个人全面成长的机会。这就好比一个人，如果始终生长在生产线上，并且只用右手，那么10年过后右手必然会无比强壮，而左手则会无

性格决定命运，程序员亦莫能外。性格影响机缘有无，影响才情发挥，影响努力深浅，最终影响人生之结局，是人这一生里可以把握，又往往被忽视的因素。在这里，我们来试着对程序员的性格和可能命运做一归结，当可为有心则戒。绵羊型的程序员这类型的程序员每天有点糊涂，也不知道应该干点什么。不是很有上进心，安排干什么都行，但会因为小糊涂或不用心偶尔犯犯错误。除非家境很好，要不然绵羊型的程序员其实有点危险。公司如果严苛，

软件这个行当里历来有个谣言：项目经理不懂技术没关系。有人说这事儿是外国的先进经验，但我怀疑这是杜撰的。这一观点的潜台词是：项目经理是管理者，指挥下属就行了，干嘛要懂技术！这就像说班长不用拿枪上战场一样可笑。持这个观点的可还记得：”将军起于行伍，宰相拔于州郡“这一说。我的观点是，项目经理一定要懂技术，并且还要有比较扎实的功底，虽然在专门领域上不一定是专家。在这篇文章里，我们将列几本用来打根基的书，这

程序员生存定律这系列的目录在这里：程序员生存定律--目录喜欢从头瞄的，可以移步。-------------------------------------------------------------------------------1． “博”与“专”上的迷失假设说一个人的学习已经聚焦，并且学习的内容和自己实际参与的项目也相吻合，那么是不是就没有问题了？很不幸，答案仍然是否定的，在任何一个子

软件自身是一种固化的思维，因此从本质上来看，软件是不可度量的。但这并不意味着软件不需要度量，而只是说软件中的度量大多都有一定限度。应用各种度量数据的时候一旦跨过这种限度，结果就会适得其反。在这篇文章里，我们将考查一下现有的，对软件进行度量的方法(注意：这篇里主要考察别人的方法，不是我自己的)。可能不全面，不足的地方欢迎大家进行补充。对软件“直观可见的质量属性”的度量比较简单，比如：Bug率，性能等

软件开发这个行业无疑的是有快乐的，但这篇文章里，我们先不关注他，而是要来看看那些让人痛苦的地方。有时候想想，人作为一种生物还是挺有意思的。快乐的东西快乐过了，也就忘了，记的牢的的反倒是些让人不快乐的东西。 第一重：垃圾代码佛家总讲成住坏空，软件亦莫能外。唯一有点特别的是，软件“住”的阶段短，“坏”的阶段来的快。要想软件保持不“腐败”，其实要花的精力远比想的多，这导致在商业利益比较强势的世界里，大多

人格可以理解为情绪，思维方式，习惯的复合体，具体左右一个人对周围人事所作出的反应。在组织行为学里有好多对人格特质进行描述的模型，其中比较有名的一个是大五模型（五维度人格模型）。在大五模型里用五个因素来考察人格特质： 外倾性（extroversion):外倾者者倾向于喜欢群居，善于社交和自我决断。内倾者则比较内向，胆小害羞，安静少语。 随和性（agreeableness）:高随和性的人是合作的，热情

在MBA的课程中有一门是组织行为学，就我个人感觉项目管理者别的科目不看也罢，组织行为学这门还是看看比较好。组织行为学被定义为这样一种研究领域：探讨个体、群体以及结构对组织内部行为的影响。通俗的讲就是研究一个人的行为规则，比如人的需求层次会如何影响动机，又会如何影响人的行为。饿的要死的人，是不适合总谈理想的。研究一个群体的行为规则，比如从众心理如何产生以及如何预防。研究组织结构对个人行为的影响，比如

虽然Code Review经常被提及，但就我个人感觉（一半从别人的博客，一半个人经历），Code Review的实际境况大多时候还是比较难看的。更多时候，Code Review很像被存起来的酒，用的时候拿出来看看，证明有这东西，但大多时候是不用来喝的。 细究成因可能是来源于两个方面：一是时间压力太大。软件开发里可以安全打折扣的地方其实不多，文档不写很容易被看出来，代码不写程序就动都不动了。没办法下

如果让每个人选一个管理（包括项目管理和部门管理）中最可怕的事，答案想必不尽相同。有的人会老生常谈的选沟通不畅，有的人会选文化冲突，有的人会选资源不足等等。但就我个人感受，第一可怕的事是说了不做，流行点的词可能叫执行力。典型的场景是规则流程定义了一大堆，一到做的时候这些东西就都放在一边了。每个人都按自己的习惯来，各行其是。这很可怕，会导致无政府状态，做的人因为看不到改善而抱怨，管理者会因为看不到未来

众所周知，领导与管理意义不同，领导者要决定的是未来的走向和基本的原则策略。管理者则要使用具体的手段，达成既定的目标。但现实中的管理上的问题往往并不只类似于数学，只需要计算和推理，而更类似于社会学，需要许多判断，这也就意味着做管理的时候最终会涉及导向性的问题。 软件项目的管理尤其如此。 建造一栋房屋和构建一个软件，其不同在于建造房屋的工人需要的是按照设计图纸严格执行，因此纪律要比文化重要。但在软件开

自从《赢》，《基业长青》这些书出了之后，只要是个人，只要他还做管理都会关注文化这个事。这是对的，但关键是在这个事上不能走形式，不能在管理中做虚情假意的文化建设。不知道提到文化这事，每个人会对应到什么？可能有的人会想到宣讲，有的人会想到集体活动（喝酒，唱歌，旅游，培训等），有的人会想到挂图，历史展示等。但事实上这些手段更类似一种枝节，如果没有一个核心支撑，那就很容易变成虚情假意。这个核心支撑就是：你

#成为项目经理是需要积累的，如果你想快，但不想付出，那求神拜佛比较好。#这系列文章是写给想成为项目经理，但又愿意努力的人的。当我们开发软件的时候，很多人知道要为目标软件建模，好开发需求。而成为项目经理自身也是一种需求，为进一步开发其关键点，事实上也需要建模---为软件开发自身建模。项目经理更类似帅才，单项未必是最优的，但在开发软件时必须统筹全局。而统筹全局的前提则是对软件开发自身形成了自己的想法，

引言在项目管理这样的领域中有一种很不好的趋势，那就是许多局中人逐渐的迷失自我。而在偏向社会学的领域中，一旦我们相信理论多于相信自己，也就意味着我们开始犯错。项目管理是与数学等自然科学完全不同的学科。数学上，一旦有人证明了1+1=2，那么这条规律可以放之四海而皆准。但项目管理不行，A说他用了某方法做指导取得了巨大成功，B却可能说他也用了，基本没什么帮助，而他们却可能同时都是对的。项目管理虽然本身

事先声明：想对微软这样一个庞大的公司做出周到客观的评价其实很难，我只评价我看到的，也只保证逻辑通畅。 微软近来重组了，有人看好，有人看衰，我这里用一般管理原则看一下这次重组，目标不是说微软，而是说管理原则，借下微软的势而已。 管理中第一原则当是实事求是，形象讲就是采取的措施和待解决的问题要有直接关联。而本次重组显然违背这一原则。从外部看，微软的主要问题不是现有领域不巩固，而是开辟新领域不利，而把开

我们必须承认技术和管理所面临的问题、所需要的性格和能力皆是不同。虽然有的时候管理也被认为是一种技术，但我们更愿意把直接贡献于软件产品的工作称之为技术，而把通过协调沟通等手段间接贡献于软件产品的工作称之为管理。 从先天性格来看，有的人天生适合做管理多一点，有的人天生适合做技术多一点。 比如说：有的程序员天生有点被动，不喜欢主动学习很多东西，不喜欢与人沟通，但对工作所直接关联的领域研究较深，做事情兢兢

一点说明：作为程序员，通常心里是讨厌软件工厂的，但很多时候问题自身皆有其内在理性，并不以个人的偏好而改变其发展的轨迹。所以程序员一旦谈及和自身喜好相关的问题时，尤其要摒绝个人好恶，否则就会离问题的真相越来越远，而只有一腔情绪。就我个人观察软件工厂大致处在这样一种地位：经营管理者迫于成本的压力，总是潜在的期望其可能实现；而程序员群体自身则总是对其嗤之以鼻。为什么在经营层面软件工厂有如此大的诱惑力？这

在《与熊共舞》中，作者列出了5项核心风险，它们分别是： 进度安排的先天错误 需求膨胀 人员流失 规约崩溃 低生产率在这里，人员流动被列为第三号核心风险。在国内也许上述排名会有所变化，但不管怎样从短期视点来看，人员流失一定仍然是核心风险。从长期视点来看，人员流失的重要性则一定会排在第一位。在COCOMOII中，人员流动被认为会对生产效能产生1.59倍的影响。虽然没有统计数据，但我估计这个值被低估了，

在实际软件开发过程中，在中国，可能很多项目管理人员第一头痛的事就是，团队成员工作热情不高，投入程度不够。 这个问题成因可能有很多，比如： 可能原因之一，在于人。 假设每个人都自觉遵守职场里的规则，那管理难度要相对较低。但很多时候团队成员有可能缺乏一些基本的共识。对于很多人来讲，可能基本思路是：打工不过是谋生的一种手段，明天我还不知道在那里？这也就导致了，团队成员对公司没有归属感，进而责任感及主动性

恰如标题，第二定律表示为：在思维可以精确量化前，量化管理在程序员身上永无可能。这次估计会有争议，所以这里给出具体的逻辑链以及对应的分析。逻辑链：软件是一种固化的思维 →思维的本质是概念和逻辑 → 概念和逻辑无法直接度量和精确度量 → 度量过程中需要很多的主观判断 → 以目标为导向的，个人中心的量化管理（相关的激励和惩罚）将崩溃 具体分析：公平公正是管理的基石，为达成这一目的很多人会想到量化管理，但

（接前一篇，继续）第五重：技术变化快，积累上不去设想一下，一个10年前的高手，这10年他什么也不学，那他今天会是什么样的一个状况。我个人估计是快被淘汰了。这是个极端的例子，但回顾一下软件的发展历程你会发现，新技术的出现是爆炸式的。在DOS的时代里，软硬件的距离非常近，你只要会一种语言，了解基本算法和数据结构，再了解计算机硬件的知识，你就可以写大部分的程序。接下来软件和硬件间的层次越来越多，Wind

程序员生存定律这系列的目录在这里：程序员生存定律--目录喜欢从头瞄的，可以移步。-------------------------------------------------------------------------------去除性格和习惯中的致命缺陷性格决定人缘，而人缘影响沟通成效，最终影响一个人的表达力。想成为一个道德完美的人是非常困难的，但只要稍微注意，去除一些谁都厌烦的性格缺陷