1. 在没有足够的驾驭的能力时，不要在写代码甚至设计系统的时候考虑设计模式；设计模式应用的更好的时候，是在对刚做完的项目做重构和做项目/软件技术交流时，用来交流的。比如我用一个单件替换了原来的做配置信息的全局变量。

2. 对于程序员来说，难度排序应该是： 写代码 < 读代码 < 写人人能看懂的代码 。所以，一般看到别人代码时第一反应是“这个代码应该重写”的程序员，是初级程序员，尤其是对好好的在线提供服务的系统或者软件。

3. 软件不可控的因素更多的在于软件的不可见，即使给你软件的架构图纸也没法可控，但对于建筑或者机械行业，即使没有图纸也能比较简单的看到结构。

————- 故事的分割线 ———————-
基于以上的总结，其实很容易讲一个让绝大多数程序员似曾相识的故事.

一天，老板问程序员A：我们要做这样一个项目，你看大概要多少时间？
A： 以这些功能点来说，我估计需要2-3个月吧
老板：哦， 2个月阿，好，那就教给你了.
A: … (心想，我啥都没干呢怎么先给我砍掉了1个月的时间呢？)
A: 老板阿，2个月不靠谱阿
老板：你不是说2-3个月吗？
A: 那2个月是肯定不够的阿
老板: 这个事情确实非常重要，非常着急，有什么困难你克服一下，加加班。这个项目搞完了好处少不了你的.
A： …. ， 好吧

———— 时间的分割线 ————-
一个月后
老板: 兄弟，咱那个项目进展如何了？
A：正赶工做呢，辛苦阿
老板：让我看看
A打开界面让老板大概用了用，然后..
老板：很不错阿，都能用了，还有哪些是没做完的呢？
A: 一些参数检查，一些细节功能, bla bla bla
老板:那些先不用做了，这里改一下，那里改一下，哎，你拿支笔记一下 bla bla bla

然后，一堆靠谱和不靠谱的需求产生了

———— 时间的分割线 ————-
又两月过去，项目发布

老板: 小A阿，咱们那个项目反响不错，就是bug稍多了点，另外还有些功能需要增加一下，bla bla bla
A：bug多是正常的，时间太紧张，能做完就很不错了。（喵了个咪的，一早告诉我三个月，一早告诉我那一堆想法，怎么会有这么多问题，还反响不错，我看就是不能用）
老板: 小A阿，我列了个清单，后面你就照着这个单子改吧
A: 好吧 ，（怕怕，那一堆赶工的代码，还得我改，我可再也不想碰那堆垃圾了，先忍几天）

———— 时间的分割线 ————–
又两周过去

A: 老板，我准备考研了。所以，我得离开公司了，感谢老板的栽培
老板： ？！， 年轻人阿，有想法是好的，但也要负责任阿，你看咱们的项目还有那么多事情要做，你看你能不能坚持一下，把咱们的项目处理完再走
A: 不成阿，我这里好多事情都安排好了，时间没法变了，对不住了。（我靠，都是你拍脑袋的注意，这时候你要我负责，想得美）
老板:(@#@$@%)

几天后，招了新程序员B到公司了
老板: 小B阿，现在公司有个拳头产品，需要你来维护一下。
小B： 太感动了，我才来就把这么重要的事情交给我，老板你放心吧

几天后
小B: 老板，那套系统的代码我看了，前面干这个活的程序员太傻X, 明明有很多地方可以改进，他都是瞎写的，你要的新功能和那些bug，在这个老系统里基本上没法改。不行我就给咱重写了这个系统得了。
老板：那需要多长时间阿
小B: 估计要2个来月吧，
老板: 那我要的那些功能和那些bug的修改呢？
小B： 您放心吧，我会用最新的XXX技术,yyy架构，保证东西出来的又快又好

———— 时间的分割线 ————-
一个月后
老板: 兄弟，咱那个项目进展如何了？
B：正赶工做呢，辛苦阿
老板：让我看看
B打开界面让老板大概用了用，然后..
老板：很不错阿，都能用了，还有哪些是没做完的呢？
B: 一些参数检查，一些细节功能, bla bla bla
老板:那些先不用做了，这里改一下，那里改一下，哎，你拿支笔记一下 bla bla bla

然后，一堆靠谱和不靠谱的需求产生了

———— 时间的分割线 ————-
又两月过去，项目发布

老板: 小B阿，咱们那个项目反响不错，就是bug稍多了点，另外咱们原来那些不错的功能怎么都没有了呢?，bla bla bla
B：bug多是正常的，时间太紧张，能做完就很不错了。那些老功能不是都涵盖在新功能里了么.（喵了个咪的，一早告诉我三个月，一早告诉我那一堆想法，怎么会有这么多问题，还反响不错，我看就是不能用. 还想要以前的功能,那些功能都跟你的新需求有冲突,我不干掉可就没法做完你要的东西了）
老板: 小B阿，我列了个清单，后面你就照着这个单子改吧
B: 好吧 ，（怕怕，那一堆赶工的代码，还得我改，我可再也不想碰那堆垃圾了，先忍几天）

———— 轮回的分割线 ————-
又一个新的轮回开始了

 在这里，我的看法又稍有不同，我认为是语言的抽象层次不够。这一点，Go做得比D好一些，因为Go把进程和网络抽象到了语言内。而契约编程和单元测试可以用代码规范来实现。

另外，我还隐约觉得这种抽象还缺少了一些东西，可能需要我学习一些lisp知识之后才能有所了解。

待续吧

鉴于我对git的这些命令了解得还是不够清楚，顾以下说明仅供参考。

1. 创建服务器上的仓库，作为公共仓库，需要
git init –bare
但要在本地创建一个自己用的仓库， git init 就够了。

2. 在服务器上初始化好一个仓库目录后，就可以使用了。只需要有远程访问的权限就可以作为远程仓库。
如:
克隆到本地仓库:
git clone user@host.domain:/Path/to/repository/

3. 创建好本地克隆之后，总会有提交到服务器仓库的时候，第一次push，需要使用
git push origin master

—————————–
最后更新: 2012-02-11 19:28

难得成为世界名人的债主啊

如何成为艾未未的债主
1）邮政汇款（2－3天）：北京朝阳区崔各庄乡草场地村258号 100015 路青收 （国外可选择西联汇款）

2）（首选方式，即时到账）中国建设银行北京市分行前门支行幸福大街储蓄所 6222 8000 1013 1006 244 刘艳萍（国际转账SWIFT代码: PCBCCNBJBJX）

3）支付宝：fakesheji@gmail.com（即时到帐，每天取出15万限制）

4）paypal：fakesheji@gmail.com （因为资金进入频繁目前被paypal冻结）

信息来源：http://loveaiww.blogspot.com/2011/11/ai1001_6999.html

其实，现在的软件开发也是这个现状，所以我们需要更强的代码生成工具

本来，我一直用 grep 进行辅助，后来看到gedit有个插件classbrowser还不错，在python程序下完全没有问题，但是在编辑php程序文件时却怎么都列不出类和函数来

经过2天对 classbrowser 代码的跟踪，最后发现问题所在。

classbrowser对php文件的解析使用的ctags工具，我本机的ctags是 ctags.emacs23的符号链接，在ubuntu的安装包里还有另外一个 ctags-exuberant, 这个包则是原生ctags的扩展版本。安装这个ctags包之后，
gedit的classbrowser插件就可以正确解析 php 文件了。

—————————
PS: 列表虽然出来了，但是效果没有那么理想。没有层级，没有折叠，类/变量/函数只是颜色和图标的不同

–EOF–

小公司好调头首先是受制于团队能力。小公司之小，首先必然是人少，而且不够专业。小公司里，一专多能的人会更受欢迎，如果太专，则在小公司里往往无法做事, 因为你上下游配合的环节都做不到足够专业。也正是这样的用人概念，也就造成了小公司需要频繁掉头的事实: 很多过于专业的事情做不了，只能寻找另外一个适合公司当前人力配置的事情来做。

小公司好调头的另一个原因，人力财力有限，一个方向上遇到障碍，不可能拼尽全力去死磕，只能掉头。绝大多数选择创业的老板都是有一点背景并且看到一些希望，所以往往并不缺乏机会，尤其是一战成名的机会。但这种机会也往往需要投入公司的全部人力物力之后都不够，这对创业公司就形成了一个无形的壁垒:慢慢熬; 或者用尽各种手段整合到足够的资源; 或者等下一次更合适一点的机会。 但只要想抓住一次机会，这次机会就绝对不是为你量身定做的，你就一定要对整个公司的业务、流程、甚至团队进行调整。

就这么简单的2个原因，就导致了小公司会频繁的掉头，尤其典型的就是经常可以听到在小公司工作的人在抱怨: “老板一点准主意都没有，今天做个东，明天做个西的, … 。 ” 其实，他只是不了解老板的无奈，谁不想踏踏实实把一件事情做好阿, 可是太多的时候由不得他阿。

绝大多数的人会认为确定盈利模式，建立公司制度是老板的事情，我的看法是不全是老板的事情。公司老板的首要任务是如何让公司活下来，做到这一点只需要不断找到盈利点就可以了，然后才是如何让公司更规范化的运行和找到所谓的盈利模式。我们都知道，大公司和小公司的一个显著的区别就是制度明确和流程的清晰，但如果我们仔细的想一下: 谁能记得住一个大公司全部的制度文本和流程要求？ 我相信很少有人能, 能做的这些人估计也都是职业的行政和人力人员。那大公司的制度到底是什么？我也想了很多，突然顿悟了: 是习惯。

继续深挖我这个结论，就不难得出: 一个公司做事的习惯，不是老板说了算的，是靠整个团队不断磨合来养成的，最终形成文字的变成了制度, 形不成文字的就是文化。小公司既然面临不得不变来变去的困境，又要养成良好的做事习惯，这真是雪上加霜，要不为什么会有绝大多数的小公司会在几年内死掉呢。

有了这个结论，就不难看明白另外一个现象了: 绝大多数能从小成长起来的公司，都会在快速发展的阶段进行大换血，甚至有些情况下老板都会被换掉，比如老板自己把公司卖掉了, 或者被投资方炒掉了。其实这些现象都有一个共同的结果: 引入空降兵的做事习惯，让公司的制度建立起来。这样做的坏处大家也都看过无数次了：公司不是家；公司已经不是当初我喜欢的那个公司了；公司越来越没有人情味了；当初的和睦快乐的团队消失了。但这些都不是公司的错，错在管理者。

几个简单的问题就可以想明白: 换血的目的是什么？因为要建立更好的做事的习惯。为什么现有的部门/团队没有建立起良好的做事习惯？因为他们没有做，或者没有意识去做。大换血就一定会成吗？不一定，必然还存在部门与部门之间的合作问题。大换血除了流失了老员工之外，还有什么损失呢？ 损失的公司原有的氛围和文化。所以，现有的团队没有跟上公司的进步，被换掉是自然淘汰的结果，但随着换血流失掉的老员工和原有的公司文化，也没有哪个老板是不心疼的。员工的牢骚我们反倒是见的更多一点，见不到老板的牢骚，也无非是2个原因:太多的事情要做，顾不上；我确实有责任，也没什么好牢骚的。

困境，又是困境。该怎么办，我想了很久。

起初，我认识到，我也许是我们团队中最先发现这个问题的，那么唤醒团队其他成员的责任自然在我身上，为我的部门建立良好的做事习惯的责任也自然在我。然后，我迅速又认识到，部门不是孤立存在的，只有一个部门能在公司的成长的过程中存活下来并不是成功，也并不能真正的保住公司的氛围，反而更容易形成所谓的小圈子。我必须让团队的人和我一起为这个目标努力。

首先，我看到了公司的问题所在，别人可能没看到或者没有精力去处理，更有可能很多人会想那不是我的事情，但那些事情又没有达到需要老板去关注的程度，该怎么办？ 我认为，我看到了就应该我解决。但我的时间和精力也是有限的，我需要解放自己的手和脑，要么换自己部门的人，要么给他们做培训，或者兼有。解决了自己的问题，放开了自己的手，才有机会抬起自己的眼，看看部门合作上有什么问题，有没有可以帮助其他部门共同进步的地方。各个部门的事情都能顺利进展了，我们这些管理层的成员才能让老板的意图更快的达成，才有机会帮老板分担更多的压力，老板才会有时间和精力考虑更多的所谓公司的方向和模式的问题。而所谓模式，往往也是源自各个团队能做的最好的事情。

每次部门的技术交流会我都会讲, 公司的进步取决于公司每个团队的进步，团队的进步又取决于团队的每一位成员，我必须不断的教育我的团队成员，让他们能更专业的胜任工作，唯有如此，我才能有时间和精力去为合作团队分担更多的压力，为我的老板考虑更多的事情。自然，老板仍然只需要考虑如何保证公司的生存就好，管理层更多的要考虑如何发展，只有各个部门的响应不断变得规范速度不断变快的时候，老板才有空余的精力考虑更为远大的目标，公司才能迈向下一个台阶。在规范化不断推进的过程中，缺失的环节和岗位会被自然发现，当这个环节变得足够重要的时候，合适的人自然会加入进来。

对于我，一个部门的管理者来说，我的成就不是我写了某某软件某某系统，也不是做了多好的服务多大的销售业绩，我的成就是我是一家创业成功的公司的中的一员，公司的每一次进步都有我的努力，我的部门顺利的配合了老板和其他部门并取得了成功，并成功建立了部门内和部门间的流程。我想这就是创业的态度吧。

–EOF–

然后，右键点任务栏网络连接的图标->编辑链接->无线宽带，然后按照向导执行下来就行了。

—-eof—-

前几天，白鸦的文章 絮叨”产品” 也在讨论这个问题。

在我看来，无所谓这个人到底应该是什么工种什么特长，只需要他尽量专职，必须专注的为一个产品的生命周期负责。这个产品的生命周期应该包括:需求调研，可行性分析，UI/UE的设计，实现方案的确定，运营方向及方案的确定，效果的统计和分析，项目的后续发展(扩大，持续或终止)。

以上这些阶段，看起来很像软件工程里系统分析师要干的活儿。其实本来就是，因为互联网产品没有明确的需求方，只有潜在的用户。而国内CS专业里，软件工程都是针对客户项目进行教学和实践的。而且，互联网产品和客户项目的还有一个本质的区别就在于:客户项目只需要取悦客户，客户满意就一切OK;互联网项目却要为后续的投入负责。

按照上述的产品生命周期划分，公司领导和项目经理的职责应该是:公司领导定好方向，产品经理负责分析可行性和制定运营计划，然后由产品经理推动整个项目或终止这个项目。

但因为要对项目的后续投入负责，而一般的互联网公司里，产品经理往往不可能有这么大权力决定一个项目的生死(另一个真相是，没有几个项目经理懂得如何做市场调研和分析)，从而拍板项目要做的是公司领导，甚至连带着把工期也拍板了。因为产品经理的项目前期的不作为，自然，他也不必为后续的投入负责，更不需要为运营的方向和方案伤脑筋了。结果，一个产品经理就被定位成了UI/UE 设计师 兼 设计技术和前端之间的沟通协调人了。

这一点，白鸦的 絮叨”产品” 一文里就对baidu产品的成功做了一个描述，其中白鸦最欣赏也正是产品经理的全职全责。

———————-
现在说回绿人，既然我认为自己想的挺明白了，那为什么绿人也在这个困境之中呢？
原因其实很简单:人力不足。

一个好的旅游产品线，涉及的内容是相当多的，每一个点都可以深入下去做出花来。但哪一个点会是能让绿人开花的点没有人能打包票，同时作为一个经济体，生存并盈利始终是最应该优先考虑的问题。所以，就成就了现在的状态: 哪一个点能让绿人多活一段时间或者说多盈利一点，哪一个点就应该做一些投入。

如何解开这个困局呢？ 我还在苦苦寻找