理想流

就发原创，写那种有点深度的文章

加了几个图，匆忙做了个PDF，如果不喜欢看网页版大家就看这个吧：http://download.csdn.net/download/leezy_2000/7893513PDF版里面多了几张插图，还有目录什么的。网页版的目录在这里：http://blog.csdn.net/leezy_2000/article/details/29407747

我个人其实有点宅，喜欢闷在屋子里看死了好几百年人写的书，看的多了就想自己写写。那时候一共构思了两本书，一本是想写给做了很多年软件的人看的，一本是写给要入行或者刚入行的人看的。写第一本的时候是比较狂妄的，那时候我觉得《人月神话》有些过时了，有的地方也挖掘的不够深，应该有本书来取代它的位置，所以使了很大力气来尝试把书写的很有价值，写到我认为能够超越《人月神话》的程度，但等书出来我才明白，能不能超越《人

程序员生存定律这系列的目录在这里：程序员生存定律--目录喜欢从头瞄的，可以移步。------------------------------------------------------------------------------- 一个创业者的十年我一直很犹豫要不要在这样一本书里去讲创业的故事，因为我一直相信创业是成功率极低的一项活动，只不过是成功者的光环太盛，才使这项活动吸引了过多的关注

程序员生存定律这系列的目录在这里：程序员生存定律--目录喜欢从头瞄的，可以移步。-------------------------------------------------------------------------------一个关于项目经理的故事1 项目经理的养成日记L在2001年毕业之后加入到了福建实达公司。 在今天这个公司几乎是很少有人听说了，但在当年实达还是在IT这片江湖里有些

程序员生存定律这系列的目录在这里：程序员生存定律--目录喜欢从头瞄的，可以移步。-------------------------------------------------------------------------------此前的章节基本上是在分析并试图建立一种成长的模型，为免这种分析和模型离开现实，下面将考查一些具体的，程序员的故事，看的话最好把这六个故事都看完，否则容易片面。很多

程序员生存定律这系列的目录在这里：程序员生存定律--目录喜欢从头瞄的，可以移步。-------------------------------------------------------------------------------开篇前再补一句，这没考虑创业的情形，只是说最一般的情况。在弄清楚公司的分类方法，以及某些类别公司的长处和短处后，就可以开始考虑如何去选择公司。经常会看到这样一些问

程序员生存定律这系列的目录在这里：程序员生存定律--目录喜欢从头瞄的，可以移步。-------------------------------------------------------------------------------前讲到了自身价值、自身价值上的表达力和稀缺性，这三项更多的讲的的是个人，在职场中无疑的与个人直接关联的是公司。这一章将具体说明与公司相关的、影响个人发展的要素。在

程序员生存定律这系列的目录在这里：程序员生存定律--目录喜欢从头瞄的，可以移步。-------------------------------------------------------------------------------假设说你想在江湖里谋求一定的地位，那么你可以练习独孤九剑成为超一流高手，也可以练习医术，成为绝世神医。这两者在江湖里都是有地位的，也都是稀缺的，一者是因为杀伤力，

程序员生存定律这系列的目录在这里：程序员生存定律--目录喜欢从头瞄的，可以移步。-------------------------------------------------------------------------------武林里往往会有很多利益纠葛，常常是你想成为五岳剑派的盟主，我也想成为五岳剑派的盟主。一旦如此，那么就得各凭道行，做过一场一分高下。有利益纠葛就需要合纵连横，恒山派

程序员生存定律这系列的目录在这里：程序员生存定律--目录喜欢从头瞄的，可以移步。-------------------------------------------------------------------------------取他人、他物所长，为我所用的这一面，始终有着不可忽视的价值。在大约2300年前，荀子对此进行了很好的说明：吾尝终日而思矣，不如须臾之所学也。吾尝跂而望矣，不如登高

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

程序员生存定律这系列的目录在这里：程序员生存定律--目录喜欢从头瞄的，可以移步。-------------------------------------------------------------------------------前面讲的主要是提升一个人自身的价值，对于程序员而言，自身价值几乎与技术能力相等价。对喜欢编程的程序员而言，最简单的生存方式也许是最幸福的，比如说：我只把精力放在提

做个记录，免得日后找不到：

程序员生存定律这系列的目录在这里：程序员生存定律--目录喜欢从头瞄的，可以移步。-------------------------------------------------------------------------------这篇说的是精神，比较务虚，不感兴趣的可以略过。在国内有一个很特别的现象：高中打了鸡血一样使劲学习的人，到了大学往往会放松下来，跑去享受生活了，大学里打游戏、打牌、

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

程序员生存定律这系列的目录在这里：程序员生存定律--目录喜欢从头瞄的，可以移步。-------------------------------------------------------------------------------前面讲到了程序员成为高手需要有一张地图，借助这样一张地图，程序员可以尝试成为架构师、Guru或者纯管理者。但这条路总是不会那么顺畅。升级练功流的网文中总会给修仙的

程序员生存定律这系列的目录在这里：程序员生存定律--目录喜欢从头瞄的，可以移步。-------------------------------------------------------------------------------一旦度过了初始阶段，做过了前面说的那些事情，那么一个人算是基本入行了，接下来的目标就非常简单，要在选定方向上成为高手。高手意味着专业，而在分工无限细化的年代里，专

程序员生存定律这系列的目录在这里：程序员生存定律--目录喜欢从头瞄的，可以移步。-------------------------------------------------------------------------------1 掌握读代码的方法和技巧不管最终想成为什么，刚入行之后，一定离不开的是读代码和写代码。这里将介绍一些读代码的方法和技巧。读代码这事，先要分是精读还是泛读。从学习

程序员生存定律这系列的目录在这里：程序员生存定律--目录喜欢从头瞄的，可以移步。-------------------------------------------------------------------------------从大环境来看，想不写程序直接去做管理工作是很难的。大多时候都要在开发上做出一定成绩，接下来才有选择技术还是管理的机会。因此即使是希望选择管理方向，技术上的基本功还

程序员生存定律这系列的目录在这里：程序员生存定律--目录喜欢从头瞄的，可以移步。-------------------------------------------------------------------------------一个程序员在考虑增值时无法回避的一个根本问题是到底是做技术还是做管理。当然也有些职位会介于两者之间比如架构师，但我们暂时不去做细分，而是用简单的二分法。这种基本方

程序员生存定律这系列的目录在这里：程序员生存定律--目录喜欢从头瞄的，可以移步。------------------------------------------------------------------------------规律是必须顺应而不能改变的，但除此之外现实中还有一些事实也是无法改变的，这两者都很像程序中的常量，想提高人生的高度则需要同时驾驭这两者，而不能试图为两者赋值。下面我

程序员生存定律这系列的目录在这里：程序员生存定律--目录喜欢从头瞄的，可以移步。----------------------------------------------------------------------------------------------定律要素之三：自身价值的稀缺性现实里，体现稀缺性的故事也很多。在东北曾经发生过一场非常惨烈的战争，这场战争之所以惨烈，倒不是因为战斗

程序员生存定律这系列的目录在这里：程序员生存定律--目录喜欢从头瞄的，可以移步。定律要素之一：自身价值在金庸先生构建的武侠世界里，最犀利的杀伐武功应该是《独孤九剑》，但学会了独孤九剑却失了内功的令狐冲一样会被一堆流氓痛殴。

程序员生存定律这书的目录在这里：程序员生存定律--目录喜欢从头瞄的，可以移步。----------------------------------------------------------------------------------------------生存定律总纲如果我们承认交换是职场里一切的根本，那么就可以基于交换的特征推导出生存定律的纲要。假设说一个人的技能所带来的价值是S，实现

程序员生存定律这书的目录在这里：程序员生存定律--目录喜欢从头瞄的，可以移步。支撑职场的基本规则是交换，交换的两端分别是你可创造的价值与你的职场位置（包含收入）。交换就像任督二脉间的通道一样，越是通畅，人生也就越顺风顺水；堵得越死，人也就越寸步难行。

程序员生存定律这书是陆续发的，所以做个目录让想从头读的方便些：前言：解码程序人生

上一篇里主要写了几个可能的人生出口，接下来讲这些出口依赖于什么，这篇有点过渡性质，嫌烦可以不看。。对于一个程序员，大致的结局多是上述五种中的一个。其中转管理的程序员和成就高手的程序员算是稳中有升。创业者算是生死未卜。维持原状的老程序员则是失意的。他的选择权会被收的越来越窄，在工作层面，他需要和毕业生竞争，在家庭支出方面他所要承担的比别人一点不少。人生总是这样，向你索取的一端往往是确定的，而你所能获

程序员的人生出口很多人非常想知道自己的未来是什么样子的，迫切到一定程度甚至会找算命先生。如果并不是想得到一个精确结果，这事儿其实并没有想的那么难。程序员的人生看起来五花八门，可以是Windows系，可以是Android系，可以是iPhone系等等，但如果为之做点抽象，那就会发现人生出口的类别其实不多，接下来我们就结合例子来看看程序员的人生中最可能的几个出口。这些出口里有大部分人的未来景象。1 成就

#本来这些陆续累积下来的文章是要汇集成一本书的，和侠少同学也谈过，但弄V众投实在太忙了，没空管精调细作它了，所以把这些章节陆续整理下放出来，希望对刚入行的小朋友们有些帮助。有些事真是入行很久后才明白，感觉上如果能预先明白了，应该挺有帮助的。下面故事开始。-------------------------------------------------------------------------

起因写完《完美软件开发：方法与逻辑》这书后，原本想继续写书的，可出来参加了些社区活动后，我发现我写的书大家评价还行，但其实不太理解。而接下来想写的书更加抽象点，准备叫《管理的解析》，我一琢磨以我的影响力，写这样一本高度抽象的书，估计会彻底仆街，于是相当犹豫。为了写这书，当时准备了很庞大的读书计划，准备把彼得德鲁克的所有的书，精神现象学，康德三大批判都读下，前者用来系统完善对管理的概念，后两者用来提

很多人谈设计模式,但就我观察和软件相关的模式中最牛的一个却被忽略了。这个模式不一定能用GoF的那类表述方式来描述，但却几乎可以在大多的成功产品中看到影子。 这个模式可以表述成：软件的架构要支持数据的开放，提供API让别人可以编程定制或扩展你的程序。 有人一听说这不就是插件么？但把这个等同于插件是把它看小了，插件只是它的一个子集。 那么那些足够牛的产品中用过这个模式？真不好一一列举，立刻能想到的

好久没发博客，来个狠的，我不信挨踢界有人比我更蛋疼来研究这个。 在马克思提出共产主义100多百年后，软件开发领域中出现了一种特别的生产方式：开源(FLOSS：Free/Libre and Open Source Software)，并爆发出了惊人的生产力。作为结果，以这种生产方式开发出来的软件覆盖了几乎所有软件类别，并获得广泛应用。从本质来看，这种生产方式植根于资本主义生产关系之上，但又与资本主义

如果以Turbo C为起点回看这10几年的IT世界，就会发现每当新技术（C++,Java,OO,泛型,RAD,组件...）出来的时候，通常它会被认为是通解，而后在应用过程中才会逐渐发现它的限度。在这样一种过程中，我个人就逐渐形成了这样一种认知：对新技术而言，只有在不只知道它适合做什么，也知道它不适合做什么的时候，才算是真的掌握了它。在此之后才可能人驾驭技术，否则很容易出现技术驾驭人的情形。技术驾驭

近来看了2篇和读书有关的文章，一篇提到Joel讲现在程序员不太读书了，主要靠在网上找各种参考资料；一篇则是马总说的：成功与情商有关 与读书多少关系不大。一定程度上这两个观点都有点道理，可以靠StackOverflow.com和搜索引擎找到各种问题的答案和例子，刘邦项羽不太读书一样闹革命，还成功了，但如果得出一个“读书无用”的结论来就错了。人类获取知识的手段无非就两个要么靠实践直接获取，要么间接获取

近来在侠少（@永恒的侠少）的微博上看到一件吊诡的事情。《WCF技术内幕》的译者指斥《WCF全面解析》的作者抄袭，而指斥的理由是：还有一个原因我要告诉你，为什么是抄袭。因为《Inside WCF》是世界上第一本从内部机制剖析WCF框架的书！为什么这本书只有Justin Smith可以写出来，因为他是微软美国WCF团队的技术经理！他才是真正了解架构的人。2007年就写出来了。。。国内有人写出这种书，根

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

因为看的书相对比较多，最近又写了一本，感觉多少有点发言权，因此把自己的经过和感受写出来，供想写书的做些参考。现在浮躁的人比较多，所以我先说写书不能达成什么目标。最关键的一点是程序员写书基本不能让你发财，这里有篇文章叫《写一本书作者到底能拿到多少稿酬？》   里面把版税计算的计算方法写的比较详细，大家可以仔细读下。一般来讲技术书籍很可能销售不了一万册，即使以一万册来计算，收入大概在5万上下，这是笔收

我是如何写作一本软件+哲学式的书籍的（上）做好这个决定后，就面临一个很棘手的问题：怎么不把这样一本书写成散文，这类书很容易想到那写到那，针对各种东西，发一堆感触，而后被命名为经验分享。看到的一些书就是这个状况，这未必没意义，但这违背初衷，我是想写本讲本质，把事儿讲透的书。而上面的写法很像有把锤子就把什么都当钉子。做播放器的有益经验给做驱动很可能就是毒药。就好比说，单纯从现象来看，世界各个角落发生的

近来，陆陆续续写了快十年的书《完美软件开发：方法与逻辑》终于上市了，这书非常另类，更像是软件+哲学的作品，很可能卖不好，也很多人不喜欢，但一路写来实在是比较坎坷，因此把大致的过程写下来，供想写书的各位参考。另一个自己很想说下的话题是，每个程序员都应该给自己写本书，虽然不太赚钱，下一篇写这个。 非要给IT书分个类的话，我感觉可以分两大类：一类是解决具体问题的书，比如：《C#高级编程》，《Hadoop

首先说下什么叫“完美软件开发”，想象一下，完美的圆在现实中是不存在的，现实中的圆只能是对完美的圆的回归，但完美的圆描述了圆的构成规则，完美软件开发意义与此相同，它试图描述软件开发的规则和铁律。但既然现实中不存在，探讨完美状态又有神马意思？好，那我们再来看一个完美状态：牛顿第一定律说：任何一个物体在不受任何外力或受到的力平衡时，总保持匀速直线运动或静止状态，直到有作用在它上面的外力迫使它改变这种状态

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

按国别来区分企业，误杀的几率很大。但毕竟同一国家的企业还是有些共通的特征，因此这里择取两个视角做一个简单的分析。一个视角是透明天花板的高低；一个则是规范程度。什么叫透明天花板？职业路径被封死在某个高度以下，但这种封锁在可见制度层面又不存在，这就是透明天花板，往往是做到一定高度的人对此感受的更为清晰。平心而论，透明天花板在那里都有，本身倒不一定就具有贬义。但不同企业中其高度确实不同。如果要排个次序，

平庸是程序员的最大忌讳。大家可以看看最近出来的软件开发者薪资调查报告（http://www.programmer.com.cn/14918/）。读过之后每个人的认知可能不同，有的人感觉我怎么赚这么少得跳槽，有的人感觉自己还可以，我个人的感觉就是上面那句话：平庸是程序员的大忌。在一个还不算老的行业里，在一个相对较高收入占比在20%~30%的行业中，没有什么比平庸更可怕的了。反倒是编程语言，数据库这类

说软件行业技术更迭快的人很多，认同的也很多，我个人也是认同的，但大致有多快这事儿老是没有一个真切的概念。为了有一个直观的印象，我们来用一个简单的办法。就是选一本比较有代表性的，系统介绍某一类技术的书籍。接下来看一下10年里，这本书里究竟有多少知识被更迭掉了。这里选的是袁峰先生所著的《Windows图形编程》，这书只要看过的就知道它可以很好的代表Windows图形编程这一领域（不含3D)。下面是这本

读代码这事，先要分是精读还是泛读。从学习的目的来看，一定要精读一定量的经典代码。而精读是指每行都读懂，不看代码脑子里就能勾画出程序的基本结构。这里有个很形象的状态，精读代码时会满脑子都是代码，放不下，甚至睡觉前脑子里也是代码。但这一篇里主要不是关注如何精读代码的，而是关于如何在工作中掌握既有代码的，等价于泛读。 现存的很多系统往往很大，几十万行的可能也只算普通。这时候一旦加入了这样一个项目，那么如

近来在CSDN结识了贺利坚老师，并仔细的读了一下贺老师的博客，感觉贺老师是非常负责的一个大学老师，在他的博客中看到了很多他和大学生的交流。这就促使我开始思考，如果大学再来一遍，我也还是想做软件，那我应该在大学里学点什么？最终我决定把想到的东西写下来，希望能对在校的人有点帮助。 首先我们得知道这问题的答案是个变量，他依赖于你的目标和天资能力，绝不唯一。当然大学的课程设置往往是唯一的，所以会有点矛盾。

下面的文字，有的来自自己微博上的记录，有的来自散写的文章，但总的来看都是自身这些年来的一些思考。也许对喜欢思考的人有点意思，所以汇总下。但也正因为时间跨度和来源比较杂，就没什么体系性了。 关于编程1.和世界格局一样，软件开发里也是多维力量（商业、公司政治、技术等）在冲突，单纯地斗争和避让其实都不太行。 2.很多时候人们争论是因为都不清楚问题自身。比如：软件工厂可能么？软件和工厂都是巨大且模糊的概念

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

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

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

老实讲大部分程序员的岗位并非是纯技术岗位，所以做纯技术导向的程序员隐含着风险。我们身处的这个世界是这样的：最外面一层叫中国特色的社会主义，往里面一层就是各种公司，公司里面有一定层级，程序员处在层级中某个位置。 中国特色的社会主义和公司机制决定了什么呢？他决定了公司需要不断的把人力、技术、材料、服务等等转化为现金流。 程序员干的事情是这一转换过程的一环。 在这里技术是创生现金流的一环，千万不能把这个

要想做好管理先要理解相应群体的动机，所以管理者要大致知道一点动机理论，要不然就只能呼唤狼性了。 《组织行为学》这本书很有意思，说动机理论前，先攻击金胖子。说尊敬的领导（即刚去世不久的金胖子）通常被认为有点疯狂，比如他会绑架韩国电影导演或者日本人，可这是为什么呢？作者认为首先是享乐主义。金胖子喜欢所有最新的玩具和小玩意，让厨师去东京学习世界上最好吃的寿司的做法，到伊朗学习鱼子酱的做法，到新加坡学习番

引子这两天读了李彦宏先生给内部员工的内部邮件，感觉应该是真的，所以稍微做点评价。邮件有三个要点，并不复杂：提倡面对变化、反对小资呼唤狼性、减少管理层级。 这三者间应该是因果关系，因为要面对变化，所以反对小资，小资没有战斗力。因为要激发狼性，所以要减少管理层级，提升效率。 简评单纯从逻辑上来分析，这封邮件提倡的东西是会失败的，李彦宏先生发现了问题但解题思路很可能偏了。什么是狼性，狼性也许表现为敏锐的

刚毕业不久的程序员往往非常期望成为项目经理，主要原因应该是感觉项目经理收入等会远好于码农。所以很多人会去总结如何成为项目经理，看起来点击率也还不错。这大致上没错，相信在未来相当一段长时间里也不会有什么改变，相当于程序员群体里的“官本位”。本质上看，这是软件层次所限制的，很微妙，这次不谈。但这里面有一个陷阱，有志于成为项目经理的人要预先知道。一旦你成为项目经理，相比与程序员，你的工作角色会发生巨大的

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

近来同时看到了两篇文章：一是关于工作满意度的。     书里说：对于贫穷的人（比如在贫困线下面），薪酬对工作满意度和整体幸福感有决定性影响。但是一旦达到比较舒适的生活水平（在美国，大约为每年40000美元，当然这与所处的地区和家庭人口数相关）,这一关系就不存在了。--见人大版《组织行为学》77页。一是关于坚持理想的。《地缘大战略》这本书的作者丁力先生写第一册的时候，前后花了6年时间，而这段时间作者

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

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

我个人的经历略有一点特别，本身学的专业并不是软件，但在当年软件热的背景下，加入了这个行业。由于很多同学仍在原来的行业，时不时的沟通让我反思软件开发究竟和机械制造这类行业有啥区别。老实讲，对于毕业生而言，10年前做软件收入要比做机械制造有明显优势，但10年后的今天这种优势就不明显了。这也是触发我考虑这种问题的一个原因。软件行业与机械制造比一个很不同的特质：知识更迭频度较快。在考虑如何使自己升值时，这

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

前几天同一个朋友闲聊，他说了个很有意思的观点：我们不招北大清华的。 因为大家都经过高考的折磨，所以心里对考上北大清华的都还是有点敬畏的，因此就追问了下原因。他的回答很简单：我们得承认这两所学校的人非常优秀，但跑到二线城市来的大部分都不能踏实做事，招了也不能用。 他说的踏实做事这点比较能引起我的共鸣，可能也有一定的代表性。 学校本身提供了一个起点，证明的也是过去，毕业后想证明自己还是得用事实说话。但

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

经济形势一路走低，公司裁员的消息也偶尔听闻，其中闹的比较醒目的则是摩托罗拉移动的裁员。从报道来看，南京摩托罗拉移动的各位对这个公司还是很有些恋恋不舍的，甚至提出了希望再为公司工作一年的期望。具体情形其实不太了解，不妄发评论了，但这事再次提醒我们一个很本质的事情：职场如市场，本质上就是一场交换。员工可以跳槽，公司可以裁员，都是非常的正常。很多公司都会强调企业文化，希望能营造一种归属感，这没错，文化确

我一直的观点是要对“难”做一点分解。好比说航空母舰的弹射器，我们造不出来，很“难”与一台机器有一千个螺丝要拧，保证3年中所有螺丝都拧对了，很“难”，这两种场景下“难”的含义是不同的。软件开发的难度更多的类似于后者，表现为繁杂，而不是类似于前者表现为“搞不定”或“做不出来”。总是有人喜欢把问题绝对化，所以这里补充一句，软件涵盖的范畴可以很广，因此确实有很难搞定的，类似于弹射器的领域，但应该不是主流。

软件架构师的定义乃至所需要的特质历来众说纷纭。下面从一些另类的角度来做点分析。 从产生根源来看，程序规模越大，参与人员越多，越需要架构师；程序越小，参与人员越精英化，架构师存在价值越小。 这不难理解，大军团作战，总不好一窝蜂就上去了，总要有些规则，总要有人把我全局。架构师就是在比较高的层面上把握全局的这个人。 从这个角度来看，对架构师而言选择最重要，因为站的高，所以选择具有非常大的价值。注意不是U

假设说一个人是个项目经理或部门经理，并一下子扎到了一个执行力不好的环境中，那么这个人能干点什么或者说应该干点什么？大多时候中层的人并不能左右高层的性格乃至种种选择，所以如果真有让人绝望的事情，又没有忍耐的的能力那就只能换个地方。这很简单，并不值得多谈，我们主要要关注的是事情积极的一面，即如何扭转这种局面。为了有所改善，第一关键的事情是要足够真诚。工程师组成的团队中其实并不需要很多政治，大多时候，大

在考虑如何解决执行力问题之前，很有必要考察一下执行力为什么会败坏。现实中很本质的东西往往会被繁杂的细节所掩盖，因此我们来抽象出一个虚拟的公司，来看看执行力出问题的各种可能性。我们假设有一个小公司刚刚建立，其中高层2人，中层3人，一般员工30人。我们假设在公司营业的第一天，执行力是没有问题的。那么如果执行力最终出了问题，变成说了不做的状态，那么要么主要是高层问题，要么主要是中层问题，要么主要是一般员

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

近来，我发现有这么样一个现象：在某类特定环境下，越是年纪小工作年限短的，越容易流动；越是年纪大的，越稳定，但相应的会焦虑。同周围的人做了些交流后，感觉这也不能算是一种个案，还是有一定的代表性，因此就想做一点分析。个人感觉上述这一现象可以用软件开发技能的可流动性来解释。从可流动性的角度看，越是通用的知识，可流动性越好，越是专门的知识可流动性越差。比如说：开发语言，在当前市场环境下，任何一门主流开发语

不知道多少人有这样一种经历：明明从技术上看是不对的或者说是不可能的，但还是要按照一种不对的方向做下去。至少我个人是有这种经历的。销售的和企划的定好了规格和日期，把他们都作为不可更改的目标发配给程序员。程序员明明知道不应该走捷径去赶进度，但给日程压的没办法，就只能赶啊赶。在限定场景下，一个人所能完成的工作其实是个确定值，因此这时候能采取的手段其实不多：一个是加班，一个是降低代码质量。最终产品仓促上市

在软件这个行业里，怕是没有任何一个其话题域像开发语言这样引起争议了。对开发语言是非的争论，不单旷日持久，且深度亦是与时俱进。实现要强调下的是，在这里我们要专注的是开发语言的选择而非开发语言的优劣。从不同的视角对开发语言进行选择，其结论可能大相径庭。从项目的角度看，语言自身特性的多少，强弱往往并不成为一个关键选择因素。好比说某语言支持多重继承，而某语言不支持多重继承，但对大多项目而言多重继承这一语言

年青的时候最大的资产就是时间，所以最关键的理财就是如何投资自己，这点毫无疑问。但在此之外，倒也不能说是什么事也不用做。为了收益最大化，还是要有一点点理财知识。了解这些知识不用花什么时间，但多少会有点收益。因此，我在这里做一点总结，以供参考，但绝对不为任何因此而产生的结果负任何责任。l 算算买第一套房子的收益率很多地方房价高的离谱，如果说彻底让人绝望了，那就彻底不用理它。但是如果可能买的起，还有点犹

写面向对象设计原则的文章很多，但在我看来面向对象的一些原则是虽然是对的，但不够精练。大多面向原则其实可以用三个支撑点推导出来：确保正交，控制层次，信息隐藏。这一篇里谈一下确保正交性。抽象是设计工作的起点，而抽象的结果可以是一个具体的概念，也可以是一段逻辑。正交性则与抽象的结果有关联。为了理解正交性，我们先来看一下这个词的几何解释：当两根直线互相垂直的时候，我们认为这两根直线是正交的，否则的话这两根

假设说一个人最终可以到达的高度和努力，能力，机缘都有关系，那么选择了那个公司则是机缘中一个很关键的影响因子。也即是说在同等努力程度下，选了那个公司，大致决定了可以达到的高度。选公司就和买股票一样，你也可以闭着眼睛瞎选，未必就不能找一个还算合适的公司，但从几率上讲，分析了基本面，选好的可能性就更高一点。选公司前，要先给公司做个分类，这很关键。有的公司是成长型的，有的公司则是稳定发展型的，有的公司则是

如果非让我找一个最能说明现在的软件开发和10年前的软件开发相异的地方的话，我想应该是知识在量上的爆炸。在软件行业里，制造知识的速度远超可能的学习速度。夸张点讲，今天在软件世界里应该没有全才了。如果不信，可以看看下面从Wiki以及TIOBE上拷贝的列表。在当下，你很难即做内核驱动也精通css，即精通后端也精通前端，即开发数据库也开发数据库应用。当然终究是有些东西共通于各种技术之间，比如设计原则，模式

注：十年是凑个整，讨个口彩，实际算来却是10多年了。这篇是口水文章，感兴趣的瞄瞄，不喜欢的莫踩。另，这里也不包含开源的各种发展。《不差钱》里的鸭蛋说，长江后浪推前浪，坚决要把他爹拍在沙滩上。我无意间一回想，软件开发上还真有点这个味道，十几年间，已是三代程序员。第一代程序员大致上是基于DOS来做开发，常用的开发环境叫Turbo C。这个时候还没那么多API和类库，也没那么多层次，你要想干什么很容易直

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

假使说我们认同软件的构造是一个复杂的过程，那么管理这种复杂度必然需要一些技巧。而为了找出这些技巧，则需要先瞄一眼这种复杂度的基本构成。软件的构造过程牵涉了两个最为基本的要素：一是软件，一是构造软件的人。假设说存在着一个标准的人，这个人智力水平恒定，创新能力恒定，技能水平恒定。那么软件的复杂度只决定于其自身，比如软件所需要面对的业务规则，所需要的计算水平等。应对这类复杂度的有效手段是优化方法，好比说

很多人谈学习和发展的时候，往往忽略人的先天自然条件，在这里我们从这个视角切入，来探讨一下程序员一生的可能轨迹。如果把程序员的人生分为三个阶段，那么他们是：毕业~30岁：这个时间段里，大多数人无牵无挂，家里面父亲母亲不用太操心，也没娃，可能会犯愁找不到老婆或老公，但基本上自由时间较为充沛，身体比较健康。算是上升时期。30~45岁：这个时间段大多数人处在上有老，下有小。父亲母亲可能需要较多照顾，倒霉的

程序员这个群体有一个典型的特征：那就是【技术能力】大多时候和【以自我为中心的程度】成正比。具体表现形式可能是目中无人，也可能是特立独行，诸如此类。但实质上，以当前的情势而论，大多时候一旦你选择打工，而非创业，大致上也就失去了目中无人或特立独行的资格。毕业生首先需要的是适应环境，而非是指望环境来适应你。这里的环境就包含了身边可能有点落伍的技术，可能有点繁杂的“人”“事”，可能有点愚蠢的规章制度，可能

对于软件而言，层次是让人又爱又恨的东西。很多问题是通过增加层次解决的，但另外一部分问题也是因为层次而导入的。我们来分别看几个例子。例1：很多时候我们并不希望最终的应用绑定于某个指定平台，比如:Windows。为了达成这种跨平台的目的，就需要在OS和应用之间加入一个中间层，这个中间层负责屏蔽不同OS的差异。实际上，Java虚拟机等走的都是这样一条路线。例2：当使用XML文件保存配置信息的时候，我们并

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

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

--愿与勇于正视现实的人共勉在开始任何其他文字之前，首先有必要正视一个根本现实：国内外软件开发的水平是有差距的。这一结论的最直接证据是每一轮新技术的发起者基本上都是国外的人或公司：从方法论（CMMI，敏捷等）到各种框架（近来很热的Hadoop等）再到新的编程语言都是如此。总的来看这类差距似乎可以概括为“原创的缺失”，大多时候，我们只是处在一种“跟随者”的角色上。RUP出来后我们跟谁RUP，敏捷出来

很多年来始终有一种声音：编码自身会逐渐消亡，软件开发会越来越像一种组装工作。也就是说，程序员会越来越像IT工程师，他们很少自己从头做什么，而是靠搭配来达成各种目标。我身边就有持这种观点的人。而在《代码整洁之道》一书中，Robert C Martin在开篇处加了这样一段文字：有人也许会以为，关于代码的书将有点落后于时代---代码不再是问题；我们应当关注的是模型和需求。确实有人说过我们正在临近代码的终

大多情况下，并行对复杂度影响过大，并间接导致测试困难---多线程或多进程导致的问题往往是有时发生，有时不发生，一般的测试手段并不足以发现这类问题。所以原则上应该尽可能不用，除非收益足够大。或则说在满足需求的前提下，线程数和进程数应该尽可能少。 以多线程和多进程而论，确定“什么时候适合使用这种技术”是比“怎么使用这项技术”困难的多的事情。现实中人们往往对事件，信号灯等同步处理手段关注过多，而对究竟应

复用可以说是任何一个软件企业都不能漠视的课题，因为复用可能对软件的开发效能产生绝大影响，而开发效能直接影响利润，甚至生存。 但复用本身将增加当前项目的成本，是一种以当前投入来换取远期收益的行为。与此同时远非所有代码都可以复用，复用本身也有自己内在的一些规律，让我们来试做一些分析。 从结论上来说，只有满足下面两条原则的程序，才可能真正的被复用，否则的话只能采用代码级别的复用。 第一条原则是，程序本身

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

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

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

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

在软件这个行业里有些规则是很有杀伤力的，比如很有名的摩尔定律。总结出这些规则的意义在于可以大致的照明方向，免得努力来努力去却走到了阴沟里。现实中种种利益纷争、观点之争看似纷繁，但在大时间尺度下来看却都是规则的实现手段。这就好比下围棋，每一手都要为谋得利益而计算，但结局却只有三种：赢、输或和，这就是规则的力量。 民以食为天，所以第一定律从收入开始。 程序员第一定律可以表述为：程序员的收入是技能复杂度

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

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

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

无意间发现，腾讯和360又开始PK。第一次PK应该是在2010年11月，当时对抗十分激烈，腾讯发表声明：将在有360的电脑上停止运行QQ，最终结局是在有关部门的协调下，握手言和。这一次似乎又重复了昨天的故事，腾讯再次发表声明：建议只使用360或腾讯的电脑管家。这事情在没有进一步信息的情形下，很难明断其间是非曲直，但如果我们做一点抽象，有些结论却是显而易见的。为回避不必要的争议，我们来打个比方。假使