二.从进门开始
0..绝对不10点以前出现在公司.
1.着装！着装！不管你是去实验室，或者去公司的大楼，在或者是小公司的民宅，或是自己创业的黑作坊；无论是春夏秋冬白天晚上刮风下雨电闪雷鸣台风龙卷风，一个装b的程序员都要十分在意自己着装！这里只提出参考建议。初级装：衬衣+牛仔裤+休闲鞋。中级装：T恤+宽松短裤+拖鞋。高级装：背心+宽松大花裤衩+人字拖。
2.得体的举止。在走廊以及任何形式的过道里，一定要双手插兜，走得像个痞子，至少要看起来有点反社会，如若不行，可走文弱天才型geek路线。。
3.如果有女性在你背后指指点点，小声嘀咕说这一定是一个技术男的时候，应该先低头，然后保持低头状态，缓缓回头，坏坏地蔑笑但是不要出声，然后快步前行。
4.进门后，一定不要跟任何人打招呼，笔直走向自己的位置，最多路过打一杯咖啡，千万不要有多余的动作，显示出自己的专注与心无旁骛。
三.坐下就不要再动了
1.坐下以后，姿势需要略微后仰，能翘着二郎腿最好了，然后在后仰的情况下低着头，以便看到屏幕，然后千万就不要再动了。
2.粗暴地把电脑前的大堆书推开一个口，然后摘下电脑上的一个便签，看一眼，不过3秒，可以开始coding了。
3.能不用IDE就不要用，实在装不了，无论IDE是什么，一定要调成DOS那种黑色背景的。
4.如果写前台界面，就不停地调试后台代码；如果写java，就在里面混编C；如果写C，就在里面混编汇编。不光要coding，还要时不时的翻出一本什么英文的书翻一翻，看不懂就看看插图，然后扔到面前假装懂了继续coding。
5.什么看起来高端就用什么，不要管实用不实用。例如对C++：switch统统重构成多态；如果有指针，统统改成智能的；C++一定要自己写template；数字是全部要替换成宏的名字能起多长就起多长；struct就不要出现了，如果出现，也一定要用__attribute__修饰一下；运算都是位操作的；操作符都是重载的；网络都是并发缓冲线程池的；int只用int32_t声明的;继承不用普通的，什么多继承虚继承啊；helloworld也要写捕获异常的；后人一看代码，中间一堆关键字extern,asm,auto,XXXXX_cast,volatile,explicit,register,template，让一般总在敲int,if,else,for的小程序员顿时心生崇拜。
6.注释？算了吧。只有两个路线可以选：一，变量名起得巨长无比，看代码就和读英文文章一样顺畅，根本不需要加注释。 二，代码无比晦涩，加不加注释根本无影响。
7.千万不要用IM工具交流，千万不要问同事问题，显得自己没有水平，都是自己上网或者查书。
8.无论是同事间开玩笑或者发生任何群体性事件，不要抬头，更不要东张西望，即使地震火灾，也一定要先提交代码再行离开。
四.潇洒地离开
1.人走，主机是千万千万不能关的，至少要跑个daily build，实在不行正在svn提交也勉强算过关。
2.书应该已经又堆到屏幕前了，千万不要整理，明天再来推开。
3.不强求最后一个走，但一定要所有的非程序员，什么市场啊前台啊pm啊都走光了，才可以走。
4.走得时候一定要率性，千万不要收拾任何东西，站起来，出门，好的，就这样。
5.如果今天一定要说句话的话，找到那个最苦逼的程序员，跟他说，你进度太慢了啊，不要老让我等你。

作者：程序猿
来源：http://sighlife.com

散弹枪编程

这种编程风格是一种开发者使用非常随意的方式对待代码。“嗯，这个方法调用出错了……那么我会试着把传出的参数从 false 变成 true!”，当然依然出错，于是我们的程序员会这样：“好吧，那我就注释掉整个方法吧”，或是其它更为随意的处理方式，直到最后让这个调用成功。或是被旁边的某个程序员指出一个正确的方法。

如果我们把一个正规的程序员和一个撞大运的程序员放在一起做结地，那么，那个正规的程序可以马上变得发疯起来，并且，可以把正规的程序员的智商降到最低。两个撞大运的程序员不应该在一起做结对编程，这是因为他们破坏性的才能会造成的伤害会比只有一个还差。

撞大运编程

这是一种比散弹枪编程要温和一些的编程方式，我相信这种方式可能会是大多数程序员都会使用的方式。这种编程方式经常出现于程序员并不确切知道他们在干什么，也不知道所写的程序的本质和实际，但是可以让程序工作起来。他们以一种撞大运的方式在写程序，某些时候，他们根本就不知道某个错误的原因，就开始稀里糊涂地修改代码。一旦出现问题，他们会用两条路：1）停下来，理解一下程序，找到出错的原因。2）使用散弹枪编程方式开始解决问题。

测试驱动开发（Test Driven Development）是一种可以用来拯救上百万的撞大运编程的程序员。于是，他们有了一个更为NB的借口：只要我的程序通过测试了，你还有什么话好说？别骂我，测试驱动开发是一个不错的事物，其主要是用来控制撞大运开发所带来的问题。

Cargo-Cult 编程

关于Cargo Cults 这个词儿来自二战期间的某些太平洋上小岛里的土著人。在战争期间，美国利用这些小岛作为太平洋战场上的补给站。他们在这些小岛上修建自己的飞机跑道以用来运输战争物资。而那些小岛上的土著人从来没有见过飞机，当他们看到飞机的时候，觉得相当的牛，可以为那些白人带来各种各样的物品和食物。当二战结束后，那些土著人仿照着修建了飞机跑道，并用竹子修建了塔台。然后就在那期望着有飞机为他们送来物品和食物。

Cargo Cult 编程是一种非常流行的编程方法，使用这种方法的程序员会学习其它编程高手的编程方法，虽然他们并不知道为什么高手们要那样做，但是他们觉得那样做可以让程序工作起来。举个例子，当时有大量的程序员在J2EE出现的第一年中过度地使用了EJBs和Entity Beans。

刻舟求剑编程

刻舟求剑是一个很流行的寓言了。这种风格的编程在程序员的圈子里是非常常见的。比如，有一天，你发现了一个空指会的异常，于是你到了产生空指针异常的地方，简单地放上一个判断： if (p != NULL)。

是的，这样的fix可以让你的程序工作起来，但你并没有真正地解决问题。你只不过是在你的船边记下了剑掉下去的位置，这样做只不过把问题隐藏起来，最终只会让你的程序的行为变得神出鬼没。你应该找到为什么指针会为空的原因，然后再解决这个问题。

设计模式驱动型编程

正如这种编程的名字所说的，这种编程风格使用大量的设计模式，在你的程序中，四处都是设计模式，你的代码到处都是Facade，Observer ，Strategy，Adapter，等等等等。于是，你的程序要处理的业务逻辑被这些设计模式打乱得无法阅读，最后，也不知道是业务需求重来，还是设计模式重要，总之，实际业务需求的程序逻辑被各种设计模式混乱得不堪入目。

侦探型编程

在解决一个Bug的时候，侦探型程序员会调查这个Bug的原因。然后，则调查引发这个BUG的原因的原因。再然后，其会分析修正代码后是否会导致其它代码失败的因果关系。再然后然后，他会使用文本搜索查找所有使用这个改动的代码，并继续查找更上一级的调用代码。最后，这个程序员会写下30个不同的情形的测试案例，就算这些测试案例和那个Bug没有什么关系，最最后，这个程序员有了足够多的信心，并且精确地修正了一个拼写错误。

与此同时，其它一个正常的程序修正了其它5个Bug。

屠宰式编程

使用这种风格的程序员，对重构代码有着一种难以控制的极端冲动。他们几乎会重构所有经手的代码。就算是在产品在Release的前夜，当他在修正几个拼写错误的bug同时，其会修改10个类，以及重构与这10个类有联系的另20个类，并且修改了代码的build脚本，以及5个部署描述符。

来源：http://goo.gl/pf6x2
来源的来源: http://www.codeinstructions.com/2008/10/styles-of-programming.html

1.开发者需要了解更多领域和商业上的知识，程序员可用对工作相关的生意完全不在意。
2.开发者在意维护的责任，程序员更关心新技术。
3.开发者对工作方式更看重，程序员则认为技术是统治性的因素。
4.程序员试图用编译代码解决所有的问题，开发者知道编码只对软件本身有效。
5.开发者寻找其中的可重复性，程序员喜欢一次性。用龟兔赛跑来比喻的话，程序员是兔子开发者就是那龟。
6.程序员喜欢复杂，开发者则希望简洁。
7.开发者关心客户的需要及满足客户的要求，程序员则愿意早点结束。
8.开发者把工作当作工作，程序员则把工作当作玩。”

来源: http://blog.donews.com/wushuangk/archive/2006/10/14/1059995.aspx

最后我发现我这些函数可以组合成各种各样的流程，我的程序终于好修改了，我很高兴

但是我又发现，我的界面和我的流程混在了一起，另一个程序也想使用我的函数，但是我的函数中有对我的特定界面关联的代码，我不能连界面一起都给他，因为他有他的界面，但作的事我已经实现了
于是我把功能函数和界面控制分开了

我就作了这些，我的代码很容易理解，即使新员工，只要他看完业务手册和数据结构，他就明白我代码为什么这么写。
而且我的函数由于都是自己负责输入参数和输出参数的校验，有明确和统一的报错信息，所以很容易找到错误进行BUG修复。
由于我的程序都是小函数组成的，都有明确报错，所以错误很容易找到，经过测试组的专业测试后，我的代码很稳定
即使出错，也扩散不大，都是小bug，对系统整体没有大影响

虽然我在前进的过程中也经历过困惑，一心钻在OO和设计模式中。但是有可能是功力不够，不得其解。看着Delphi的源码
应用了很多的OO和模式，并且他的类库多年发展也没有多大的改变，所以深信OO和模式的威力，而对自己的能力很灰心。但是代码还得继续写，还想进一步提高，于是才摸索出现在的一套做法。既实用又简单应用，每个人都能办到

我认为我的代码方法已经可以满足现在的产品制造，并且在软件性能调整上也积累了一些珍贵的经验。
我发现性能最容易提高也效果最明显的就是用SQL profilter，优化SQL。
优化代码，因为涉及到业务，很不好着手。优化数据库结构，由于代码都是构建在特定数据表之上，所以这是最难改的地方

但是我高兴了没多久，我又遇到问题了。因为我的程序即使再好改，但是客户的需求真是千奇百怪，我每天在接听用户的电话，并且修改用户千奇百怪的问题。我很烦。
于是我作了实施员。我想真正看看客户到底怎么回事。
于是我理解了很多。我明白了很多的事情不是技术和软件所能解决的，而是现实环境的弊病。但是这个弊病还不是一个工程就能解决的，这是一个复杂的网。所以这些问题我就说服用户不要用软件来处理，因为软件是死的，而人的做法是灵活的。
而且我发现用户虽然提了很多需求，但是有的需求他一个月用不了一次，但是修改起来却不容易。有的需求修改完，在实际应用中却发现不可行，那个需求只是客户想解决过去的问题而想的一个办法根本没有经过实际的校验。有的需求修改来修改去都是表面问题，在实际应用中才发现重点问题没有提需求所以上线又搁下了

我作了总结：
1软件擅长大数据量计算和查询，还有数据联网共享，如果需求不能发挥软件特点，就不让软件实现。这样我少修改了一些
2有的需求都是表面需求，修改了也用处不大，反而耽误了重点需求的提出和修改，所以告诉用户只修改核心功能。但是用户提了很多需求，不修改完不上线。后来发现，由于他们没有深刻理解我们系统的整体思想，所以没有上线实际用，根本不知道新改的功能是否好用。用户只是脱离了整体，单独思考想怎么就怎么，没上线根本他不知道后果，怎么说也不行，就得让他看见教训他才反悔，但是已经修改了。往往出现这样的情况。最后得出一个结论：一次只提三个需求，并且用书面提出，免的说了不算算了不说。核心功能的需求修改可以满足80％的日常使用就上线。这样我少修改了很多
3并且我在实际做工程中，积累了大量的经验，写成FAQ，各种成功案例，让用户在没有提需求之前先看看自己到底有多少老软件实在不能解决而才买新软件帮助的事。新软件就是解决你过去解决不了的事。如果你没有解决不了的事，提什么需求

我的产品终于可以很快完成上线，所以可以大规模推广市场了

但是我们的产品制造又出问题了。因为客户越来越多，客户的需求越来越多。我们需要开发更多的系统，但是我们的时间有限，我们的人手有限，而且我们的人手大多是新手。怎么办。我们遇到了灾难。我们的代码质量因人而异。我们的版本管理混乱。我们的文档没有人编写，大家都被分配到用户处去上线。怎么准备数据字典，怎么切换系统，怎么记录客户需求，怎么管理系统，怎么修改代码，我们没有任何记录。现场不能离开程序员一步，一离开用户出事了就不知怎么办，没有任何可查的资料。

于是我又做了项目管理，我们缺少很多规范。事有千万，先从紧处来。写文档费时间，就开会给大家讲做事的经验。实施和代码修改需要什么必要规范就制定什么规范。在这期间最容易犯的错就是中央集权，什么事都必须自己做主。下属不管大事小事都请示你。我被搞的什么都干不了，都成了救火队员。我的团队陷入了混乱之中，因为我烦乱之中作了很多饮鸩止渴的决定。我于是又犯了一个错误，我说你们能决定的事尽量自己决定，不要问我，我权利下放。结果是：各自作各自的事，互相不通知。有的事没人管，有的事多人修改，各有一套。

我终于明白了，我作了总结：
1项目经理是找到得力的人，指导他们做事的方向。如果下属不知如何作时，及时提供给下属做事方法
2制定规范，其实也就是做事方法
3制定计划，分配人力去作。检查结果
4有紧急事务立刻做出果断解决，继续前进

我的团队终于平静了下来，但是大家都很疲惫。大家干的很累，但是由于实施和修改消耗了大量的钱，我们没有赚钱，大家什么都没有得到。团队很灰心，也很失望。我下了计划，我自己都很灰心，大家认为再努力也不会再有结果，所以拖拖拉拉，进度和成本已成不可再提的事情。

人，缺少了精气神，就什么都没有了。我们就是缺少了这些。

我就开始重新建立团队的精气神

我发现有人为了跳槽开始学习新的技术，而这种技术是公司现有产品不需要的，但是他们却在上班时间作。我先从此下手。
我讲了技术的方向，让他们认清他们现在所学将会很快淘汰。
我又讲了现在市场的实况，让他们认清外面公司也不好过。
我还讲了我们所从事的行业多有潜力，我们公司将有新的举措。

人心又开始一点一点收回了。

但是我们仍然需要完成那些未收尾的工作，仍然需要去奔赴新的客户市场。虽然员工很疲惫，虽然我们刚从飘摇中过来，
但是我们不能止步，因为我们为盈利而存在，我们别无选择。

我能够将代码写的很好，性能很高，产品制造很有计划和成本控制，团队很有战斗力。但是我发现了一个问题，我们的产品市场不再扩大了。市场份额大规模开拓已很艰难，因为新产品的新鲜感已经过去了。我们在动荡的日子作的项目给公司带来了阴影，公司一直没有大赚钱，投资方很生气。

我明白了。公司毕竟是为利润而存在的。公司不是为产品制造而存在，不是为了解决别人的问题而存在。赚钱是第一位。
不赚钱即使你在媒体上作的很风光也一文不值。有人靠手赚钱，有人靠嘴赚钱，有人靠脑子赚钱，有人靠身体赚钱，不管黑猫白猫，只要抓住老鼠就是好猫。成在营销，败在管理。

我开始关注资本运作，联盟伙伴建设，市场营销，客户关系营运。我知道，生活才刚刚开始。

来源: http://cscer.yculblog.com/post.316988.html