浏览代码

首先，我们先从浏览代码开始。有时候，我们需要看多个文件，所以，传统的做法是，我们开多个tty终端，每个tty里用Vim打开一个文件，然后来回切换。这很没有什么效率。我们希望在一个Vim里打开多个文件，甚至浏览程序目录。

浏览目录的命令很简单：（你也可以直接vim一个目录）

:E

注意，是大写。于是，你会看到下面这样的界面：

这个界面中，你可以用 j, k 键上下移动，然后回车，进入一个目录，或是找开一个文件。你可以看到上面有一堆命令：

• 【 – 】 到上级目录
• 【D】删除文件（大写）
• 【R】改文件名（大写）
• 【s】对文件排序（小写）
• 【x】执行文件

当然，打开的文件会把现有已打开的文件给冲掉——也就是说你只看到了一个文件。

如果你要改变当前浏览的目录，或是查看当前浏览的目录，你可以使用和shell一样的命令：

:cd <dir> – 改变当前目录

:pwd  - 查看当前目录

缓冲区

其实，你用:E 浏览打开的文件都没有被关闭，这些文件都在缓冲区中。你可以用下面的命令来查看缓冲区：

:ls

于是，在你的Vim下，你会看到如下界面：

你可以看到Vim打开了四个文件，编号是4，5，6，7，如果你要切换打开的文件，这个时候，你不要按回车（按了也没事，只不过按了就看不到:ls输出的buffer列表了），你可以使用下面的命令切换文件（buffer后面的4表示切到4号文件也就是src/http/ngx_http.c）：

:buffer 4

或是：

:buffer src/http/ngx_http.c

注意，

• 你可以像在Shell中输入命令按Tab键补全一样补全Vim的命令。
• 也可以用像gdb一样用最前面的几个字符，只要没有冲突。如：buff

你还可以动用如下命令，快速切换：

:bnext      缩写 :bn
:bprevious   缩写 :bp
:blast  缩写 :bl
:bfirst 缩写 :bf

上图中，我们还可以看到5有一个%a，这表示当前文件，相关的标记如下：

- （非活动的缓冲区）
a （当前被激活缓冲区）
h （隐藏的缓冲区）
% （当前的缓冲区）
# （交换缓冲区）
= （只读缓冲区）
+ （已经更改的缓冲区）

窗口分屏浏览

相信你在《Vim的窗口分屏》一文中，你已经知道了怎么拆分窗口了。其实，我更多的不是用拆分窗口的命令，而是用浏览文件的命令来分隔窗口。如：

把当前窗口上下分屏，并在下面进行目录浏览：

:He   全称为 :Hexplore  （在下边分屏浏览目录）

如果你要在上面，你就在 :He后面加个 !，

:He!  （在上分屏浏览目录）

如果你要左右分屏的话，你可以这样：

:Ve 全称为 :Vexplore （在左边分屏间浏览目录，要在右边则是 :Ve!）

下图是分别用:He 和 :Ve搞出来的同时看三个文件：

在分屏间的跳转和切换在《Vim的窗口分屏》一文中提过了：先按Ctrl + W，然后按方向键：h j k l

分屏同步移动

要让两个分屏中的文件同步移动，很简单，你需要到需要同步移动的两个屏中都输入如下命令（相当于使用“铁锁连环”）：

:set scb

如果你需要解开，那么就输入下面的命令：

:set scb!

注：set scb 是 set scrollbind 的简写。

Tab页浏览目录

分屏可能会让你不爽，你可能更喜欢像Chrome这样的分页式的浏览，那么你可以用下面的命令：

:Te  全称是 :Texplorer

下图中，你可以看到我用Te命令打开了三页，就在顶端我们可以可以看到有三页，其中第一页Tab上的数字3表示那一页有3个文件。

我们要在多个Tabe页中切换，在normal模式下，你可以使用下面三个按键（注意没有冒号）：

gt   – 到下一个页

gT  - 到前一个页

{i} gt   – i是数字，到指定页，比如：5 gt 就是到第5页

你可以以使用 【:tabm {n}】来切换Tab页。

gvim应该是：Ctrl+PgDn 和 Ctrl+PgUp 来在各个页中切换。

如果你想看看你现在打开的窗口和Tab的情况，你可以使用下面的命令：

:tabs

于是你可以看到：

使用如下命令可以关闭tab：（当然，我更喜欢使用传统的:q, :wq来关闭）

:tabclose [i] – 如果后面指定了数字，那就关闭指定页，如果没有就关闭当前页

最后提一下，如果你在Shell命令行下，你可以使用 vim 的 -p 参数来用Tab页的方式打开多个文件，比如：

vim -p cool.cpp shell.cpp haoel.cpp
vim -p *.cpp

保存会话

如果你用Tab或Window打开了好些文件的文件，还设置了各种滚屏同步，或是行号……，那么，你可以用下面的命令来保存会话：（你有兴趣你可以看看你的 mysession.vim文件内容，也就是一个批处理文件）

:mksession ~/.mysession.vim

如果文件重复，vim默认会报错，如果你想强行写入的话，你可以在mksession后加! ：

:mksession! ~/.mysession.vim

于是下次，你可以这样打开这个会话：

vim -S ~/.mysession.vim

保存完会话后，你也没有必要一个一个Tab/Windows的去Close。你可以简单地使用：

:qa   – 退出全部 

:wqa  -保存全部并退出全部

Quickfix

假如我们有一个hello.cpp文件和一个makefile，于是我们可以直接在vim下输入 :make ， 于是就可以make这个hello.cpp文件，如果出错了，我们需要按回车返回，这个时候，我们可以使用下面的命令来把出错显到在vim的分屏中：

:cw

于是，就会出现下面右边的那个样子：（是不是看上去和我一样很帅？）

上图中左边是我的makefile，右边是我的错误百出的源代码，右边下面是quickfix窗屏。你可以看到quickfix窗屏指向的第一个错误已经定位到我们相就错误的文件行上了。

你可以使用像浏览文件那样用j, k在quckfix窗屏中上下移动到相应的错误上然后按回车，然后就可以在上面的窗屏里定位到相应的源文件的代码行。但是，如果是这样的话， 你要定位下一条错误还得用Ctrl +W 回到quickfix屏中来然后重复来过。

你可以使用下面的命令而不用回到quickfix中来：

:cp 跳到上一个错误

:cn 跳到下一个错误

:cl 列出所有错误

:cc 显示错误详细信息

下面我们来看另一个quickfix的功能。

如果你用过vim的cscope插件，你就知道cscope可以用来查找相当的代码，但cscope需要事先生成一个数据库，对一些简单的查找，其实，我们用vim的grep命令就可以了，不需要专门为之生成数据库。vim的grep命令和shell的几乎一样。

我们来看个例子：

比如我们正在浏览nginx的代码，这时，我想看看哪里用到了nginx的NGX_HTTP_VAR_INDEXED宏。于是，我可以在vim里输入如下的命令：

:grep -r –include=”*.[ch]” NGX_HTTP_VAR_INDEXED src/

上面这个命令意思是递归查询src目录下所有的.c和.h文件，其中包括NGX_HTTP_VAR_INDEXED宏。然后，你就会看到vim到shell里去执行并找到了相关的文件，按回车返回vim后，别忘了用 【:cw 】把grep的输出取回来，于是我们就有下面的样子：

然后同上面一样，你可以用 j，k 键移动quickfix里的光标到相应的行，然后按回车定位文件，或是使用【:cn】或【:cp】来移动到定位。（这样，你会把多个文件打开到缓冲区，别忘了【:ls】来查看缓冲区）

你看，到这里，一个小小的IDE就这样产生了，而且，最帅的时，我们连一点插件都没有装，也没有在.vimrc文件中配置过什么。

关键字补全

我们还是坚持不用任何插件。我们来看看是怎么个自动补全的。

在insert模式下，我们可以按如下快捷键：

【Ctrl +N】  - 当你按下这它时，你会发现Vim就开始搜索你这个目录下的代码，搜索完成了就会出现一个下拉列表（居然是粉紫色的，真是丑死了）

下图是我输入了ngx_http_然后按ctrl+n出现的样子，它已经帮我补全了一个，但是我不想要这个。然后，在Vim的下方我们可以看到状态变成了“关键字补全”，然后后面有^N^P的提示，意思就是告诉你还有一个Ctrl+P.

【Ctrl + P】 – 接下来你可以按这个键，于是回到原点，然后你可以按上下光标键来选择相应的Word。

对于上面那个例子，我们按下了Ctrl+P后出现下面的这个样子。我们可以看到，光标回到了一开始我输入的位置，然后你可以干两件事，一个是继续输入（这可以帮助过滤关键词），另一个是用“光标键”上移或下移来选择下拉列表中的关键字，选好后回车，就补全了。

与此类似的，还有更多的补齐，都在Ctrl +X下面：

• Ctrl + X 和 Ctrl + D 宏定义补齐
• Ctrl + X 和 Ctrl + ] 是Tag 补齐
• Ctrl + X 和 Ctrl + F 是文件名 补齐
• Ctrl + X 和 Ctrl + I 也是关键词补齐，但是关键后会有个文件名，告诉你这个关键词在哪个文件中
• Ctrl + X 和 Ctrl +V 是表达式补齐
• Ctrl + X 和 Ctrl +L 这可以对整个行补齐，变态吧。

其它技巧

字符相关

【guu 】 – 把一行的文字变成全小写。或是【Vu】

【gUU】 – 把一行的文件变成全大写。或是【VU】

按【v】键进入选择模式，然后移动光标选择你要的文本，按【u】转小写，按【U】转大写

【ga】 –  查看光标处字符的ascii码

【g8】 – 查看光标处字符的utf-8编码

【gf】  - 打开光标处所指的文件 （这个命令在打到#include头文件时挺好用的，当然，仅限于有路径的）

【*】或【#】在当前文件中搜索当前光标的单词

缩进相关

【>>】向右给它进当前行 【<<】向左缩进当前行

【=】  - 缩进当前行 （和上面不一样的是，它会对齐缩进）

【=%】 – 把光标位置移到语句块的括号上，然后按=%，缩进整个语句块（%是括号匹配）

【G=gg】 或是 【gg=G】  - 缩进整个文件（G是到文件结尾，gg是到文件开头）

复制粘贴相关

按【v】 键进入选择模式，然后按h,j,k,l移动光标，选择文本，然后按 【y】 进行复制，按 【p】 进行粘贴。

【dd】剪切一行（前面加个数字可以剪切n行），【p】粘贴

【yy】复制一行（前面加个数字可以复制n行），【p】粘贴

光标移动相关

【Ctrl + O】向后回退你的光标移动

【Ctrl + I 】向前追赶你的光标移动

这两个快捷键很有用，可以在Tab页和Windows中向前和向后trace你的光标键，这也方便你跳转光标。

读取Shell命令相关

【:r!date】 插入日期

上面这个命令，:r 是:read的缩写，!是表明要运行一个shell命令，意思是我要把shell命令的输出读到vim里来。

vim的终级插件

CentOS下：yum erase emacs

Ubuntu下：apt-get remove emacs

对了，以前本站也有一篇小短文《如何在vim中得到你最喜爱的IDE特性》你也可以看看。

（:wq）

（这篇文章缘由我的微博，我想多说一些，有些杂乱，想到哪写到哪）

这两天，在微博上表达了一下Code Review的重要性。因为翻看了阿里内部的Review Board上的记录，从上面发现Code Review做得好的是一些比较偏技术的团队，而偏业务的技术团队基本上没有看到Code Review的记录。当然，这并不能说没有记录他们就没有做Code Review，于是，我就问了一下以前在业务团队做过的同事有没有Code Review，他告诉我不但没有Code Review，而且他认为Code Review没用，因为：

1）工期压得太紧，时间连coding都不够，以上线为目的，

2）需求老变，代码的生命周期太短。所以，写好的代码没有任何意义，烂就烂吧，反正与绩效无关。

我心里非常不认同这样的观点，我觉得我是程序员，我是工程师，就像医生一样，不是把病人医好就好了，还要对病人的长期健康负责。对于常见病，要很快地医好病人很简单，下猛药，大量使用抗生素，好得飞快。但大家都知道，这明显是“饮鸩止渴”、“竭泽而渔”的做法。医生需要有责任心和医德，我也觉得程序员工程师也要有相应的责任心和相应的修养。东西交给我我必需要负责，我觉得这种负责和修养不是”做出来“就了事了，而是要到“做漂亮”这个级别，这就是“山寨”和“工业”的差别。而只以“做出来”为目的标准，我只能以为，这样的做法只不过是“按部就班”的堆砌代码罢了，和劳动密集型的“装配生产线”和“砌砖头”没有什么差别，在这种环境里呆着还不如离开。

老实说，因为去年我在业务团队的时候，我的团队也没有做Code Review，原因是多样的。其中一个重要原因是，我刚来阿里，所以，需要做的是在适应阿里的文化，任何公司都有自己的风格和特点，任何公司的做法都有他的理由和成因，对于我这样的一个初来者，首要的是要适应和观察，不要对团队做太多的改动，跟从、理解和信任是融入的关键。（注：在建北京团队和不要专职的测试人员上我都受到了一些阻力），所以跟着团队走没有玩Code Review。干了一年后，觉得我妥协了很多我以前所坚持的东西，觉得自己的标准在降低，想一想后背拔凉拔凉的，所以我决定坚持，而且还要坚持高标准。

对于Code Review很重要的这个观点，在微博上抛出来后，被一些阿里的工程师，架构师/专家，甚至资深架构师批评，我在和他们回复和讨论的过程中，居然发现有个“因为对方用户的设置”我无法回复了（我被拉黑了，还有一些直接就是冷讽和骂人了，微博中我就直接删除了）。这些批评我的阿里工程师/架构师的观点总结一下如下：（顺便说一下，阿里内还是有很多团队坚持做Code Review的）

1）到业务团队体会一下，倒逼工期的项目有多少？订好交付日期后再要求提前1个月的有多少？现在是做到已经不容易，更不谈做得漂亮！。

2）Code Review是一种教条，意义不大，有测试，只要不出错，就可以了。

3）目标都是改进质量，有限的投入总希望能有最大的产出，不同沉湎改进质量的方式不一样，业务应用开发忙的跟狗一样，而且业务逻辑变化快，通用性差，codereviw的成本要比底层高。

4）现在的主要矛盾是倒排出来的工期和不靠谱的程序员之间的矛盾，我认为cr不是解决这个问题的银弹。不从实际情况出发光打正义的嘴炮实在太过于自慰了 。

我们可以看到，上面观点其实和Code Review没有太多关系，其实是在抱怨另外的问题。这些观点其实是技术团队和业务团队的矛盾，但不知道为什么强加给了我的“Code Review很重要”的这个观点，然后这些观点反过来冲击“Code Reivew”，并说“Code Review无用”。这种讨论问题的方式在很常见，你说A，我说B，本来A、B是两件事，但就是要混为一谈，然后似是而非的用B来证明你的A观点是错的。（也许，这些工程师/架构师心存怨气，需要一个发泄的通道）

我觉得，很多时候，人思考问题思考不清楚，很大一部分原因是因为把很多问题混为一谈，连我自己有些时候都会这样。引以为戒。

即然被混为一谈，那我就来拆分一下，也是下面这三个问题：

• Code Review有没有用的问题。
• Code Review做不起来的问题。
• 业务变化快，速度快的问题，技术疲于跟命。

Code Review

你Google一下Code Reivew这个关键词，你就会发现Code Review的好处基本上是不存在争议的，有很多很多的文章和博文都在说Code Review的重要性，怎么做会更好，而且很多公司在面试过程中会加入“Code Review”的问题。打开Wikipedia的词条你会看到这样的描述——

卡珀斯·琼斯（Capers Jones）分析了超过12,000个软件开发项目，其中使用正式代码审查的项目，发现潜在缺陷率约在60-65%之间，若是非正式的代码审查，发现潜在缺陷率不到50%。大部份的测试，发现的潜在缺陷率会在30%左右。

对于一些关键的软件（例如安全关键系统的嵌入式软件），一般的代码审查速度约是一小时150行程序码，一小时审查数百行程序码的审查速度太快，可能无法找到程序中的问题。代码审查一般可以找到及移除约65%的错误，最高可以到85%。

也有研究针对代码审查找到的缺陷类型进行分析。代码审查找到的缺陷中，有75%是和计算机安全隐患有关。对于产品生命周期很长的软件公司而言，代码审查是很有效的工具。

Code Review的好处我觉得不用多说了，主要是让你的代码可以更好的组织起来，有更易读，有更高的维护性，同时可以达到知识共享，找到bug只是其中的副产品。这个东西已经不新鲜了，你上网可以找到很多文章，我就不多说了。就像你写程序要判断错误一样，Code Review也是最基本的常识性的东西。

我从2002年开始就浸泡在严格的Code Review中，我的个人成长和Code Review有很大的关系，如果我的成长过程中没有经历过Code Review这个事，我完全不敢想像。

我个人认为代码有这几种级别：1）可编译，2）可运行，3）可测试，4）可读，5）可维护，6）可重用。通过自动化测试的代码只能达到第3）级，而通过Code Review的代码少会在第4）级甚至更高。关于Code Review，你可以参看本站的《Code Review中的几个提示》

可见，Code Review直接关系到了你的工程能力！

Code Review 的问题

有下面几个情况会让你的Code Review没有效果。

首当其冲的是——“人员能力不足”，我经历过这样的情况，Code Review的过程中，大家大眼瞪小眼，没有什么好的想法，不知道什么是好的代码，什么是不好的代码。导致Code Review大多数都在代码风格上。今天，我告诉你，代码风格这种事，是每个程序员自查的事情，不应该浪费大家的时间。对此，我有两个建议：1）你团队的人招错了，该换血了。2）让你团队的人花时候阅读一下《代码大全》这本书（当然，还要读很多基础知识的书）。

次当其冲的是——“结果更重要”，也就是说，做出来更重要，做漂亮不重要。因为我的KPI和年终奖based on how many works I’ve done！而不是How perfect they are ! 这让我想到那些天天在用Spring MVC 做CRUD网页的工程师，我承认，他们很熟练。大量的重复劳动。其实，仔细想一下好多东西是可以框架化，模板化，或是自动生成的。所以，为了堆出这么多网页就停地去堆，做的东西是很多，但是没有任何成长。急功近利，也许，你做得多，拿到了不错的年终奖，但是你失去的也多，失去了成为一个卓越工程师的机会。你本来可以让你的月薪在1-2年后翻1-2倍的，但一年后你只拿到了为数不多的年终奖。

然后是——“人员的态度问题”，一方面就是懒，不想精益求精，只要干完活交差了事。对此，你更要大力开展Code Review了，让这种人写出来的代码曝光在更多人面前，让他为质量不好的代码蒙羞。另一方面，有人会觉得那是别人的模块，我不懂，也没时间 去懂，不懂他的业务怎么做Code Review? 我只想说，如果你的团队里这样的“各个自扫门前雪”的事越多，那么这个团队也就越没主动性，没有主动性也就越不可能是个好团队，做的东西也不可能好。而对于个人来说，也就越不可能有成长。

接下来是——“需求变化的问题”，有人认识，需求变得快，代码的生存周期比较短，不需要好的代码，反正过两天这些代码就会被废弃了。如果是一次性的东西，的确质量不需要太高，反正用了就扔。但是，我觉得多多少少要Review一下这个一次性的烂代码不会影响那些长期在用的代码吧，如果你的项目全部都是临时代码，那么你团队是不是也是一个临时团队？关于如果应对需求变化，你可以看看本站的《需求变化与IoC》《Unix的设计思想来应对多变的需求》的文章 ，从这些文章中，我相信你可以看到对于需求变化的代码质量需要的更高。

最后是——“时间不够问题”，如果是业务逼得紧，让你疲于奔命，那么这不是Code Review好不好问题，这是需求管理和项目管理的问题以及别的非技术的问题。下面我会说。

不管怎么样，上述Code Review的问题不应该成为“Code Review无意义”的理由或借口，这就好像“因噎废食”一样。干什么事都会有困难和问题的，有的人就这样退缩了，但有的人看得到利大于弊，还是去坚持，人与人的不同正在这个地方。这就是为什么运动会受伤，但还是会人去运动，而有人因为怕受伤就退缩了一样。

被业务逼得太紧

被业务逼得太紧，需求乱变，这其实和Code Review没有多大关系了。对此，我想先讲一个我的故事。

我去年在阿里的聚石塔，刚去的时候，聚石塔正在做一个很大的重构——对架构的大调整。因此压了很多业务需求，等这个项目花了2-3个月做完了后，一下子涌入了30-50个需求，还规定一个月完成，搞得团队疲于奔命。在累了两周后，我仔细分析了一下这些需求，发现很多需求是在重复做阿里云已经做过的东西，还有一些需求是因为聚石塔这个平台不规范没有标准所产生的问题。于是，我做了这么三件事：

1）重新定义聚石塔这个产品主要目标和范围，确定哪些该做，哪些不该做。

2）为聚石塔制定标准 ，让阿里云的API都长得基本一样，并制订云资源的接入标准。

3）推动重构阿里云的Portal系统，不再实现阿里云已经做过的东西，与阿里云紧密结合。

这些事情推动起来并不容易，聚石塔的业务方一开始也不理解，我和产品一起做业务方的工作，而阿里云也被我逼得很惨（在这里一并感谢，尤其阿里云的同学，老实说，和阿里云跨团队合作中是我这么多年来感觉最好的一次，相当赞）。通过这个事，聚石塔需求一下就有质的下降了。搞得还有几个工程师来和我说，你这么搞，聚石塔就没事可干了。姑且不说工程师对聚石塔的理解是怎么样的。 我只想说，我大量地减少了需求，尽最大可能联合了该联合的人，而不是自己闭门造车，并让产品的目标和方向更明确了。做了这些事情后，大家不但不用加班，而且还有时间充电去学技术，并为聚石塔思考未来的方向和发展。去年公司996的时候，我的团队还在965（搞得跟异教徒似的），而且还有很多时间去专研新的东西。

说这个故事，我不是为了得瑟，而是因为有些人在微博上抨击我是一个道貌岸然的只会谈概念讲道理的装逼犯。所以，我告诉大家我在聚石塔是怎么做的，我公开写在这里，你也可以向相关的同学去求证我说的是不是真的。也向你证明，我可能是个装逼犯，但绝不是只会谈概念讲道理的装逼犯。

被业务方逼得紧不要抱怨，你没有时间被逼得像牲口一样工作，这个时候，你需要的是暂停一下想一想，为什么会像牲口一样？而这正是让你变得聪明的机会。

我为你总结一下，

1）你有没有去Review业务部门给你的这么多的需求，哪些是合理的，哪些是不合理的。在Amazon，开发工程师都会被教育拿到需求后一定要问——“为什么要做？业务影响度有多大？有多少用户受益？”，回答不清这个问题，没有数据的支持，就不做。所以，产品经理要做很多数据挖拙和用户调研的工作，而不是拍拍脑袋，听极少数的用户抱怨就要开需求了。

2）产品经理也要管理和教育的。你要告诉你的产品经理：“你是一个好的产品经理，因为你不但对用户把握得很好，也会对软件工艺把握得很好。你不但会开出外在的功能性需求，也同样会开出内在的让软件系统更完善的非功能性需求。你不是在迁就用户，而是引导用户。你不会无限制地加功能，而是把握产品灵魂控制并简化功能。你会为自己要做的和不做东西的感到同样的自豪。”你要告诉你的产品经理：“做一个半成品不如做好半年产品”（更多这样的观点请参看《Rework摘录和感想》）

3）做事情是要讲效率的。Amazon里喜欢使用一种叫T-Shirt Size Estimation的评估方法来优先做投入小产出大的“Happy Case”。关于什么是效率，什么是T-Shirt Size Estimation，你可以看看《加班与效率》一文 。

4）需求总是会变化的，不要抱怨需求变化太快。你应该抱怨的是为什么我们没有把握好方向？老变？这个事就像踢足球一样，你要去的地方是球将要去的地方，而不是球现在的地方。你要知道球要去哪里，你就知道球之前是怎么动的，找到了运动轨迹后，你才知道球要去像何方。如果你都不知道球要去向何方，那你就是一只无头苍蝇一样，东一下西一下。

当你忙得跟牲口一样，你应该停下来，问一下自己，自己成为牲口的原因，是不是就是因为自己做事时候像就牲口一样思考？

其它

最后，我在给阿里今年新入职的毕业生的“技塑人生”的分享中，我给他们布置了5、6个Homework，分享几个给大家：

1）重构或写一个模块，把他做成真正的Elegant级别。

2）与大家分享一篇或几篇技术文章 ，并收获10-30个赞。

3）降低现有至少20%的重复工作或维护工作

4）拒绝或简化一个需求（需要项目中所有的Stakeholders都同意）

部署这些作业的原因，是我希望新入行的同学们对自己的工作坚持高的标准，我知道你们会因为骨感的现实而妥协，但是我希望你们就算在现实中妥协了也要在内心中坚持尽可能高的标准，不要习惯成自然，最后被社会这个大染缸给潜移默化了。因为你至少要对自己负责。对自己负责就是，用脚投票，如果妥协得受不了了就离开吧。

芝兰生于空谷，不以无人而不芳！君子修身养道，不以穷困而改志！

谢谢听我唠叨。

（全文完）

    1没有项目核心目标，没有明确目标，没有项目完结后的效益评估，没有明确要解决的核心问题，没有项目边界。反正合同也签了，过去遇到的所有问题，都希望这一个项目这一次都能解决。把IT方项目人员尽量留在企业当企业的劳工使用，没有上线时间限制，没有资源人数限制，一个劲的提要求让IT方人员干。

    2客户本身都没有尝试过，自己想着应该挺好，也没有细想，就非让IT化。

    3开会老没人。都有充足理由。来的人都决定不了。总负责人管不了 。能管的了的人，反而不管。级别够的，都不深入参与项目。只是来表示慰问，或者阶段总结会上出现 。领导平时不参与，几个业务部门在讨论会上打架打的不可开交，让领导来拍板。领导来了，听了双方各个理由，就拍板了。最后细想，这样的决策结果落地成IT肯定有问题。但大领导都决定了，谁也不敢去向大领导反映

    4客户方没有IT人员参与，是客户业务部门和IT方直接交流。各用各的思维，都想占主导位，捏不在一起。

    5IT人员在过程中躲事，能不做就不做，都扔给IT方来做，而且有什么业务与IT之间的矛盾，都让IT方尽量满足。开各种参数开关，满足各种情况，不管情况是否正常或合理。软件既复杂又不容易稳定。

    6客户IT方主导项目需求，最后上线的时候在业务部门真正运行，发现客户方IT部门理解的业务需求也不对，再重头改。

    7项目基础数据混乱，还不想整理，想继续使用。或者是过期数据，不一致的数据，重复的数据，缺失的数据，异常数据。整理这些数据就非常花时间。

    8报表各个指标组合，又不使用BI展示工具。开发工作量、开发工作难度、速度、报表准确性都受挑战。

    9客户说的，在签单前销售人员都答应，模棱两可觉得可以这样解决。真正签了合同执行落实时发现几经努力都达不到，费了牛劲浪费了大量时间还是达不到。

    10客户方内部斗争，IT方内部斗争，影响项目进程和项目讨论结果。你同意的，另一方就肯定反对，最终出来的讨论结果几经妥协已经变得很畸形，还让IT方实现。

    我们发现，我们有好的项目管理方法，也有相应配合人数和能力的项目团队，也有统一的项目模板，但每个项目回顾的时候都发现异常百出，当时没有有效控制。每次项目总结，都说下次如何做，但是到了下个项目，那人那地那景，出现了问题，上次总结的补救办法居然无法套上。

    我们再仔细分析一下，看看能不能个个击破。

    1 我们想制定一个有明确边界限制的目标和可数的问题，客户答应吗？所以我们要多树立自己专业的项目管理形象，取得客户信任。

    2客户都没有尝试过的，自己臆想的，这种业务，我们不IT化，也不打击客户，而是和客户一起思考业务流程细节和业务表格、岗位职能调整，考核，先让他们自己尝试人工去做。确实有效益而且业务稳定了再IT化。

    3 想让有级别真正管人的领导深度参与项目。可能吗？想让管事的人都到齐，可能吗？一般不可能。所以只能邮件和短信来群发及时汇报。能影响项目的，都要拉进这份群发名单中。

    4、5、6 我们来领导客户IT方、客户业务部门，我们来总协调总规划。客户答应吗？客户为什么不答应。为什么我们领导就擅长呢？给个理由先。所以要加强我们的行业分析、业务模型咨询分析、行业观点能力。让客户信任，相信我们有先进能力。

    7 基础数据，客户愿意自己先整理明白吗？很难。这是特别花时间花人工的，双方谁也不想自己扛下来这个活干。这个矛盾怎么解决？

    8 建议独立上套数据分析系统。但企业往往又不上。IT方也不想免费给上。这个矛盾怎么解决？

    9 我们曾经尝试让技术部门的项目经理充当售前，把达不到的技术问题消灭在前期。但是，销售和老板为了得单子，不让说实话，不让说做不了，宁可尝试最后确实达不到，也不能说达不到。这个矛盾怎么解决？

    10客户内部不斗争，项目团队内部不斗争。可能吗？好像不太可能。明着执行力很好，但实际都是糊弄，推委。这个问题不好解决。这个矛盾怎么解决？

    建议这篇文章，搞信息化的企业IT部门的人多来看看，或者转发给他的大领导或业务部门领导来看看。因为抱怨问题的人往往是问题的根源。

    但是这个容易实现吗？不容易。看blog读报纸的一般都是小兵。而IT部门领导，一般都是拍胸脯向大领导保证肯定能完成。而小兵呢，根本无法逾越直接转给大领导。大领导平时也接触不到这些信息。

1982 – 大家发现有97% 的C程序调用产生了“缓冲区溢出”问题。于是，C 程序员们开始意识到，就算是不必要也必需要初始化变量。然而，强制性的变量初始化这个明智的决定，很难影响了当时已经写成了的97%的C程序，所以结果什么也没有发生。 

1984 – 操作系统出现了“错误指针”的问题数量开始戏剧性地增涨。 

1985 – 一系列的让C语言有面向对象能力的解决方法出现了，一个叫“C With Classes”正准备商业化。然而，大家觉得名字“C With Classes”太清楚和容易被理解了，所以，最终的商业版本叫做—— C++。

1986 – C语言成为最流行的语句，其被很多业界分析师推荐于业务应用。他们向全世界宣称——由C语言写成的应用将可以运行在很多不同的平台上的，是跨平台的。目前看来，这些众多的分析者在当时有可能是因为某种迷幻而导致其大脑被所蛊惑了。

1988 – 业界的这些分析家们因为“摇头丸”吃完了。所以，在他们的幻觉过去以后，他们注意到，使用C语言来开发业务应用会增加5倍以上的开发时间，并且程序也不具备可移植性。他们开始停止向大众推荐使用C语言来开发业务应用了，只能很少一部服用可卡因的人开始转向推荐大众使用C++语言写业务应用程序，他们说，“那是面向对象的，所以，代码是很容易重用的”。

1990 – 在这个时候，所有的C编译器都转到了C++编译器上。但是，因为大多数的C++程序员并没有使用C++中那些面向对象的语言特性。也就是说，在实际上来说，那种浮肿的代码结构加上操作系统指针的代码被一种叫面向对象的编译器编译。

1990 – 在雇佣了一些转向“吸胶毒”的分析师后，Sun决定要创造一种叫Oak的语言，这种语言主要用于电视的机顶盒。因为当时几乎所有的程序员的DNA中都有C语的基因，所以，这个语言向C和C++中大量地借鉴了很多它们的语法和编程思路。然而，机顶盒上没有操作系统，也就不存在指针，所以，他们把指针从这门语言里给去掉了。

1994 – Sun公司里的某个人意识到为一个机顶盒开发一个语言是多么愚蠢的事情。于是，这个语言更名为Java，并且为其注入了“Internet”的特征，从而让其成为一个真正可以被移植的语言。其市场营销上相当成功，而那时有3%的业内人士开始明白什么是Internet，同时，那些精神不正常的分析师们还在不停地嗑药并向大众鼓吹他们的神话——“跨平台移植性”。

1995 – Sun 向业界的分析师们提供了免费蘑菇迷魂汤，导致那些分析师在喝下汤后，马上开始写下“Java是一门未来的可移植的和Ineternet高度可集成的语言”。

1996 中 – 17,468,972 篇文章出现，描述了Java是怎么一门未来的语言。这也是Java Applet开始进入Web页的时代。

1996 末– 程序员开始使用Java applet创建他们的Web页面，然后他们开始因为挫折和沮丧开始集体自杀。此时，那些分析师开始增大蘑菇迷魂汤的剂量。

1997 – 因为接受了产生幻觉分析师的建议，Corel 决定重写他们的应用，包括 WordPerfect，当然，是用Java写的。最终的结果是，这是迄今为止比“打字机”还慢的字处理软件。

1998 –  在意识到applet已在快速枯萎，Sun又一次的重新配置了Java，这次，他们叫Severlet，这是一个服务器的程序语言。这个设计在抄袭了Microsoft Transaction Server ，并且，他们说服所有人这个设计是他们创造的。

1999 – 业内那些喝多了的分析师们用一种咆哮的方式向大众介绍了Java 2 Enterprise Edition 。 21,499,512 文章被写出来。但是，实际上并没有人使用，因为J2EE太不成熟，而又太贵了。

2000 – J2EE 最终还是运转起来了（一点点）。而且，所有的Java卖主们开始准备向其砸钱，与此同时，Microsoft 宣布了.NET，这是一个包括了所有的J2EE功能但没那么贵的产品。实际上来说， Microsoft 决定让Windows的用户免费使用.NET 。 Scott McNealy 很愤怒，其对Microsoft开展了相关的法律诉讼。

.NET 包括了最新的C家族语言，叫C#，发音是“C-pound”，继承最家族的传统，使用着一个愚蠢的名字。

2001 – Microsoft 的市场部意识到，在市面上没有人谈论他们的产品，他们找了其中一个程序员一起吃中饭，才发现，他们把C#叫做 “C sharp”。

2002 – C# 成为 Microsoft .NET的一部分。 C++ 的开发者在 Microsoft 平台上为 “managed code”而欢呼雀跃，也就是说，他们最终得到了一个内存自动管理的功能，这一功能正是1991年的Visual Basic 及1995年的Java所创建的 。

copyright (C) 1996-2006 by Billy S. Hollis, originally posted on dotnetmasters.com 13 January 2006

There are also some optimized c-string and memory functions in the CRTL code. Looks like somebody got rid of the 1992/93 implementations.