理想流

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

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

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

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

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

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

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

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

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

#2003年写过一篇同名的文章，今日再看却是浅薄了，重写一篇，算是2.0版吧。#以此作为理想流的第一篇文章    软件是一种固化的思维。其根本组成是概念和逻辑。软件世界中的一切的故事始于一个机器模型，而这个基本的机器模型并不复杂，甚至可以用三个关键概念来概括：指令，数据以及栈。其逻辑也比较简单，即按照指定的顺序，逐步执行各条指令。但也就是这样一个简单的模型，支撑起了整个软件的世界。软件构建的过程就

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

如果不是以占卜的方式来预测未来，那么就必须分析现实，并进行逻辑推演。对于软件而言，决定其未来的主要因素有三个：软件的外部要求，内在特征，人员状况。除此之外，法律法规，经济环境等也会对软件的未来产生影响，但如果把时间尺度放的比较大的话，那么这些方面的影响则具有一定的偶然性，因此我们忽略这些相对比较次要的因素。软件的外部要求又可以分为两个部分：一为用户的真实需要，一为软件的商业

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

开源至少值得向往即使是许多开源阵营中的人自己，也未必认识到自己所做所为隐含的含义。西方社会的基础是几条非常基本的原则：自由交易，平等交换，多数优胜。平等交换即以价值相等之物进行交换，这条基本原则几乎体现在任何一个角落里，虽然价格与价值经常发生背离。在这样的基本原则下，因为社会生产的需要，又产生了公司这样的组织。公司对内向员工支付工资以购买劳动，对外则以交换为手段获取利润。利润之于公司，便如血液于人

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

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

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

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

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

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

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

CMMI这个模型的根本问题不在于模型本身是否成熟，而在于这一模型所牵连到的诸多困难通常很难克服，最终导致这一模型在实际应用中，大多时候的结局只能是形式大于内容。CMMI批判之二CMMI的边界CMMI起源于美国国防部，这一出身直接决定CMMI是为了解决大型项目中所遇到的问题来到这世上的，并最终导致CMMI成为一个庞大且复杂的方法论。大方法论意味着其复杂度偏高，复杂度偏高也就意味着推行成本以及ROI（

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

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