软件编程杂谈文章汇总西方文艺复兴以来，中国在自然科学方面落后西方很多，软件领域也不例外。当然现在中国的许多程序员们对此可能有许多不同的意见，有些人认为中国的程序员水平远落后于西方，有些则认为中国的程序员个人能力并不比西方的程序员差，只是整个软件产业落后而已。
那么，到底中国的程序员水平比西方程序员水平差，还是中国有许多优秀的程序员达到或超过了西方程序员同等水平呢？要解决这个问题，必须先知道程序员有多少种技术层级，每个层级需要什么样的技术水平，然后再比较中国和西方在各个技术层级的人数，就可以知道到底有没有差距，差距有多大。
当然，对于如何划分程序员的技术层级，不同公司或不同人会有不同的划分标准，下面的划分仅代表个人的观点，如有不当之处，还请砸板砖予以纠正。
菜鸟第1层楼属于地板层，迈进这层楼的门槛是很低的。基本上懂计算机的基本操作，了解计算机专业的一些基础知识，掌握一门基本的编程语言如C/C++，或者Java，或者JavaScript，...，均可入门迈进这层。
在这层上，中国有着绝对的优势，除了从计算机专业毕业的众多人数外，还有大量的通信、自动化、数学等相关专业的人士进入这一行，此外还有众多的其他专业转行的人士，人数绝对比西方多出甚多。并且还有一个优势就是我们这层人员的平均智商比西方肯定高。
没有多少人愿意一辈子做菜鸟，因为做"菜鸟"的滋味实在是不咋的，整天被老大们吆喝着去装装机器，搭建一下测试环境，或者对照着别人写好的测试用例做一些黑盒测试，好一点的可以被安排去写一点测试代码。当然如果运气"好"的话，碰到了国内的一些作坊式的公司，也有机会去写一些正式的代码。
所以，菜鸟们总是在努力学习，希望爬更高的一层楼去。
从第1层爬到第2层相对容易一些，以C/C++程序员为例，只要熟练掌握C/C++编程语言，掌握C标准库和常用的各种数据结构算法，掌握STL的基本实现和使用方法，掌握多线程编程基础知识，掌握一种开发环境，再对各种操作系统的API都去使用一下，搞网络编程的当然对socket编程要好好掌握一下，然后再学习一些面向对象的设计知识和设计模式等，学习一些测试、软件工程和质量控制的基本知识，大部分人经过2～3年的努力，都可以爬到第2层，晋升为"大虾"。
中国的"大虾"数量和"菜鸟"数量估计不会少多少，所以这层上仍然远领先于西方。
大虾们通常还是有些自知之明，知道自己只能实现一些简单的功能，做不了大的东西，有时候还会遇到一些疑难问题给卡住，所以他们对那些大牛级的人物通常是非常崇拜的，国外的如Robert C. Martin、Linus Torvalds，国内的如求伯君、王志东等通常是他们崇拜的对象。其中的有些人希望有一天也能达到这些大牛级人物的水平，所以他们继续往楼上爬去。
由于"大虾"们经常被一些疑难问题给卡住，所以有了"大虾"们只好继续学习，他们需要将原来所学的知识进一步熟练掌握，比如以熟练掌握C++编程语言为例，除了学一些基础性的C++书籍如《C++ Primer》，《Effective C++》，《Think in C++》，《Exception C++》等之外，更重要的是需要了解C++编译器的原理和实现机制，了解操作系统中的内部机制如内存管理、进程和线程的管理机制，了解处理器的基础知识和代码优化的方法，此外还需要更深入地学习更多的数据结构与算法，掌握更深入的测试和调试知识以及质量管理和控制方法，对各种设计方法有更好的理解等。
学习上面说的这些知识不是一挥而就的，不看个三五十本书并掌握它是做不到的。以数据结构算法来说，至少要看个5～10本这方面的著作；以软件设计来说，光懂结构化设计、面向对象设计和一些设计模式是不够的，还要了解软件架构设计、交互设计、面向方面的设计、面向使用的设计、面向数据结构算法的设计、情感化设计等，否则是很难进到这个楼层的。
当然除了上面说的知识外，大虾们还需要去学习各种经验和技巧。当然这点难不倒他们，现在出版的书籍众多，网络上的技术文章更是不胜数，然后再去各种专业论坛里泡一泡，把这些书籍和文章中的各种经验、技能、技巧掌握下来，再去学习一些知名的开源项目如Apache或Linux操作系统的源代码实现等。此时对付一般的疑难问题通常都不在话下，菜鸟和大虾们会觉得你很"牛"，你也就爬到了第3层，晋升为"牛人"了。
看了上面所讲的要求，可能有些大虾要晕过去了，成为牛人要学这么多东西啊！要求是不是太高了？其实要求一点也不高，这么点东西都掌握不了的话，怎么能让别人觉得你"牛"呢？
需要提一下的是，进入多核时代后，从第2层爬到第3层增加了一道多核编程的门槛。当然要迈过这道门槛并不难，已经有很多前辈高人迈进了这道门槛，只要循着他们的足迹前进就可以了。想迈进这道门槛者不妨去学习一下TBB开源项目的源代码(链接：http://www.threadingbuildingblocks.org/)，然后上Intel的博客（http://software.intel.com/zh-cn/blogs/）和多核论坛（http://forum.csdn.net/Intel/IntelMulti-core/）去看看相关文章，再买上几本相关的书籍学习一下。
在国内，一旦成为"牛人"，通常可以到许多知名的公司里去，运气好者可以挂上一个架构师的头衔，甚至挂上一个"首席架构师"或者"首席xx学家"的头衔也不足为奇。有不少爬到这层的人就以为到了楼顶了，可以眼睛往天上看了，开始目空一切起来，以为自己什么都可以做了，什么都懂了，经常在网络上乱砸板砖是这个群体的最好写照。由此也看出，国内的牛人数量仍然众多，远多于西方的牛人数量，在这层上仍然是领先的。
也有不少谦虚的"牛人"，知道自己现在还不到半桶水阶段。他们深知爬楼的游戏就像猴子上树一样，往下看是笑脸，往上看是屁股。为了多看笑脸，少看屁股，他们并没有在此停步不前，而是继续寻找到更上一层的楼梯，以便继续往上爬。
从第3层爬到第4层可不像上面说过的那几层一样容易，要成为大牛的话，你必须要能做牛人们做不了的事情，解决牛人们解决不了问题。比如牛人们通常都不懂写操作系统，不会写编译器，不懂得TCP/IP协议的底层实现，如果你有能力将其中的任何一个实现得象模象样的话，那么你就从牛人升级为"大牛"了。
当然，由于各个专业领域的差别，这里举操作系统、编译器、TCP/IP协议只是作为例子，并不代表成为"大牛"一定需要掌握这些知识，以时下热门的多核编程来说，如果你能比牛人们更深入地掌握其中的各种思想原理，能更加自如的运用，并有能力去实现一个象开源项目TBB库一样的东西，也可以成为"大牛"，又或者你能写出一个类似Apache一样的服务器，或者写出一个数据库，都可以成为"大牛"。
要成为"大牛"并不是一件简单的事情，需要付出比牛人们多得多的努力，一般来说，至少要看过200~400本左右的专业书籍并好好掌握它，除此之外，还得经常关注网络和期刊杂志上的各种最新信息。
当"牛人"晋升为"大牛"，让"牛人们"发现有比他们更牛的人时，对"牛人"们的心灵的震撼是可想而知的。由于牛人们的数量庞大，并且牛人对大虾和菜鸟阶层有言传身教的影响，所以大牛们通常能获得非常高的社会知名度，几乎可以用"引无数菜鸟、大虾、牛人竞折腰"来形容，看看前面提过的Linus Torvalds等大牛，应该知道此言不虚。
虽然成为"大牛"的条件看起来似乎很高似的，但是这层楼并不是很难爬的一层，只要通过一定的努力，素质不是很差，还是有许多"牛人"可以爬到这一层的。由此可知，"大牛"这个楼层的人数其实并不像想像的那么少，例如比尔&盖茨之类的人好像也是属于这一层的。
由于"大牛"这层的人数不少，所以也很难统计除到底是中国的"大牛"数量多还是西方的大牛数量多？我估计应该是个旗鼓相当的数量，或者中国的"大牛"们会更多一些。
看到这里，可能会有很多人会以为我在这里说瞎话，Linus Torvalds写出了著名的Linux操作系统，我国并没有人写出过类似的东西啊，我国的"大牛"怎么能和西方的比呢?不知大家注意到没有，Linus Torvalds只是写出了一个"象模象样"的操作系统雏形，Linux后来真正发展成闻名全球的开源操作系统期间，完全是因为许多支持开源的商业公司如IBM等，派出了许多比Linus Torvalds更高楼层的幕后英雄在里面把它开发出来的。
可能有些菜鸟认为Linus Torvalds是程序员中的上帝，不妨说个小故事：
Linus，Richard Stallman和Don Knuth（高德纳）一同参加一个会议。
Linus说："上帝说我创造了世界上最优秀的操作系统。"Richard Stallman自然不甘示弱地说："上帝说我创造了世界上最好用的编译器。"Don Knuth一脸疑惑的说："等等，等等，我什么时候说过这些话？"由此可以看出，Linus Torvalds的技术水平并不像想像中那么高，只是"牛人"和"大虾"觉得"大牛"比他们更牛吧了。在我国，有一些当时还处于"大虾"层的人物，也能写出介绍如何写操作系统的书，并且书写得非常出色，而且写出了一个有那么一点点象模象样的操作系统来。我想中国的"大牛"们是不会比西方差的，之所以没有人写出类似的商业产品来，完全是社会环境的原因，并不是技术能力达不到的原因。
"大牛"们之所以成为大牛，主要的原因是因为把"牛人"给盖了下去，并不是他们自己觉得如何牛。也许有很多菜鸟、大虾甚至牛人觉得"大牛"这层已经到顶了，但大多数"大牛"估计应该是有自知之明的，他们知道自己现在还没有爬到半山腰，也就勉强能算个半桶水的水平，其中有些爬到这层没有累趴下，仍然能量充沛，并且又有志者，还是会继续往更上一层楼爬的。
看到这里，也许有些菜鸟、大虾、牛人想不明白了，还有比"大牛"们更高的楼层，那会是什么样的楼层？下面就来看看第5层楼的奥妙。
当大牛们真正动手做一个操作系统或者类似的其他软件时，他们就会发现自己的基本功仍然有很多的不足。以内存管理为例，如果直接抄袭Linux或者其他开源操作系统的内存管理算法，会被人看不起的，如果自动动手实现一个内存管理算法，他会发现现在有关内存管理方法的算法数量众多，自己并没有全部学过和实践过，不知道到底该用那种内存管理算法。
看到这里，可能有些人已经明白第5层楼的奥妙了，那就是需要做基础研究，当然在计算机里，最重要的就是"计算"二字，程序员要做基础研究，主要的内容就是研究非数值"计算"。
非数值计算可是一个非常庞大的领域，不仅时下热门的"多核计算"与"云计算"属于非数值计算范畴，就是软件需求、设计、测试、调试、评估、质量控制、软件工程等本质上也属于非数值计算的范畴，甚至芯片硬件设计也同样牵涉到非数值计算。如果你还没有真正领悟"计算"二字的含义，那么你就没有机会进到这层楼来。
可能有人仍然没有明白为什么比尔&盖茨被划在了大牛层，没有进到这层来。虽然比尔&盖茨大学未毕业，学历不够，但是家有藏书2万余册，进入软件这个行业比绝大部分人都早，撇开他的商业才能不谈，即使只看他的技术水平，也可以算得上是学富五车，顶上几个普通的计算机软件博士之和是没有问题的，比起Linus Torvalds之类的"大牛"们应该技高一筹才对，怎么还进不了这层楼呢？
非常遗憾的是，从Windows操作系统的实现来看，其对计算的理解是很肤浅的，如果把Google对计算方面的理解比做大学生，比尔&盖茨只能算做一个初中生，所以比尔&盖茨永远只能做个大牛人，成不了"专家"。
看到这里，也许国内的大牛们要高兴起来了，原来比尔&盖茨也只和我等在同一个层次，只要再升一层就可以超越比尔&盖茨了。不过爬到这层可没有从"牛人"升为"大牛"那么简单，人家比尔&盖茨都家有2万多册书，让你看个500~1000本以上的专业书籍并掌握好它应该要求不高吧。当然，这并不是主要的条件，更重要的是，需要到专业的学术站点去学习了，到ACM，IEEE，Elsevier，SpringerLink，SIAM等地方去下载论文应该成为你的定期功课，使用Google搜索引擎中的学术搜索更是应该成为你的日常必修课。此外，你还得经常关注是否有与你研究相关的开源项目冒出来，例如当听到有TBB这样针对多核的开源项目时，你应该第一时间到Google里输入"TBB"搜索一下，将其源代码下载下来好好研究一番，这样也许你的一只脚已经快迈进了这层楼的门槛。
当你象我上面说的那样去做了以后，随着时间的推移，总会有某天，你发现，在很多小的领域里，你已经学不到什么新东西了，所有最新出来的研究成果你几乎都知道。此时你会发现你比在做"牛人"和"大牛"时的水平不知高出了多少，但是你一点也"牛"不起来，因为你学的知识和思想都是别人提出来的，你自己并没有多少自己的知识和思想分享给别人，所以你还得继续往楼上爬才行。
我不知道国内的"专家"到底有多少，不过有一点可以肯定的是，如果把那些专门蒙大家的"砖家"也算上的话，我们的砖家比西方的要多得多。
当"专家"们想继续往上一层楼爬时，他们几乎一眼就可以看到楼梯的入口，不过令他们吃惊的是，楼梯入口处竖了一道高高的门槛，上面写着"创新"二字。不幸的是，大多数人在爬到第5层楼时已经体能消耗过度，无力翻过这道门槛。
有少数体能充足者，可以轻易翻越这道门槛，但是并不意味着体力消耗过度者就无法翻越，因为你只是暂时还没有掌握恢复体能的方法而已，当掌握了恢复体能的方法，将体能恢复后，你就可以轻易地翻越这道门槛了。
怎么才能将体能恢复呢？我们的老祖宗"孔子"早就教导过我们"温故而知新"，在英文里，研究的单词是"research"，其前缀"re"和"search"分别是什么意思不用我解释吧。或许有些人觉得"温故而知新"和"research"有些抽象，不好理解，我再给打个简单的比方，比如你在爬一座高山，爬了半天，中途体力不支，怎么恢复体力呢？自然是休息一下，重新进食一些食物，体力很快就可以得到恢复。
由此可知，对体能消耗过度者，休息＋重新进食通常是恢复体能的最佳选择。可惜的是，国内的老板们并不懂得这点，他们的公司里不仅连正常国家规定的休息时间都不给足，有些公司甚至有员工"过劳死"出现。所以国内能翻越"创新"这道门槛的人是"少之又少"，和西方比起来估计是数量级的差别。
再说说重新进食的问题，这个重新进食是有讲究的，需要进食一些基础性易消化的简单食物，不能进食山珍海味级的复杂食物，否则很难快速吸收。以查找为例，并不是去天天盯着那些复杂的查找结构和算法进行研究，你需要做的是将二分查找、哈希查找、普通二叉树查找等基础性的知识好好地复习几遍。
以哈希查找为例，首先你需要去将各种冲突解决方法如链式结构、二次哈希等编写一遍，再试试不同种类的哈希函数，然后还需要试试在硬盘中如何实现哈希查找，并考虑数据从硬盘读到内存后，如何组织硬盘中的数据才能快速地在内存中构建出哈希表来，...，这样你可能需要将一个哈希表写上十几个不同的版本，并比较各个版本的性能、功能方面的区别和适用范围。
总之，对任何一种简单的东西，你需要考虑各种各样的需求，以需求来驱动研究。最后你将各种最基础性的查找结构和算法都了然于胸后，或许某天你再看其他更复杂的查找算法，或者你在散步时，脑袋里灵光一现，突然间就发现了更好的方法，也就从专家晋升为"学者"了。
学者所做的事情，通常都是在前人的基础上，进行一些小的优化和改进，例如别人发明了链式基数排序的方法，你第1个发现使用一定的方法，可以用数组替代链表进行基数排序，性能还能得到进一步提高。
由于学者需要的只是一些小的优化改进，因此中国还是有一定数量的学者。不过和国外的数量比起来，估计少了一个数量级而已。
也许有人会觉得现在中国许多公司申请专利的数量达到甚至超过西方发达国家了，我们的学者数量应该不会比他们少多少。因此，有必要把专利和这里说的创新的区别解释一下。
所谓专利者，只要是以前没有的，新的东西，都可以申请专利；甚至是以前有的东西，你把他用到了一个新的领域的产品里去，也可以申请专利。比如你在房子里造一个水泥柱子，只要以前没有人就这件事申请专利，那么你就可以申请专利，并且下次你把水泥柱子挪一个位置，又可以申请一个新的专利；或者你在一个柜子上打上几个孔，下次又把孔的位置改一改，...，均可申请专利。
这层楼里所说的创新，是指学术层面的创新，是基础研究方面的创新，和专利的概念是完全不同的，难度也是完全不同的。你即使申请了一万个象那种打孔一类的专利，加起来也够不到这层楼里的一个创新。
当你爬到第6层楼时，你也许会有一种突破极限的快感，因为你终于把那道高高的写着"创新"二字的门槛给翻过去了，实现了"0"的突破。这时，你也许有一种"独上高楼，欲望尽天涯路"的感觉，但是很快你会发现看到的都是比较近的路，远处的路根本看不清楚。如果你还有足够的体力的话，你会想爬到更高一层的楼层去。
从第6层楼爬到第7层楼，并没有多少捷径可走，主要看你有没有足够的能量。你如果能象Hoare一样设计出一个快速排序的算法；或者象Eugene W. Myers一样设计出了一个用编辑图的最短路径模型来解决diff问题的算法；或者象M.J.D. Powell一样提出了一个能够处理非线性规划问题的SQP方法；或者你发现基于比较的排序算法，它的复杂度下界为O(NLogN)；或者你发现用栈可以将递归的算法变成非递归的；或者你设计出一个红黑树或者AVL树之类的查找结构；或者你设计出一个象C++或Java一样的语言；或者你发明了UML；...，你就爬到了第7层，晋升为"大师"了。
上面举的这些例子中，其中有些人站的楼层比这层高，这里只是为了形象说明而举例他们的某个成就。从上面列出的一些大师的贡献可以看出，成为大师必须要有较大的贡献。首先解决问题必须是比较重要的，其次你要比前辈们在某方面有一个较大的提高，或者你解决的是一个全新的以前没有解决过的问题；最重要的是，主要的思路和方法必须是你自己提供的，不再是在别人的思路基础上进行的优化和改进。
看了上面这些要求，如果能量不够的话，你也许会觉得有些困难，所以不是每个人都能成为"大师"的。中国软件业里能称得上是"大师"的人，用屈指可数来形容，估计是绰绰有余。值得一提得是，国外的"大师"就象我们的"大牛"一样满天飞的多。
我把我猜测本国有可能进到这层楼的大师列一下，以起个抛砖引玉的作用。汉王的"手写识别"技术由于是完全保密的，不知道它里面用了什么思想，原创思想占的比重有多少，因此不知道该把它划到这层楼还是更高一层楼去。原山东大学王小云教授破解DES和MD5算法时，用到的方法不知道是不是完全原创的，如果是的话也可进到这层楼来。
陈景润虽然没有彻底解决哥德巴赫猜想，但他在解决问题时所用的方法是创新的，因此也可以进到这层楼来。当然，如果能彻底解决哥德巴赫猜想，那么可以算到更高的楼层去。
求伯君和王志东等大牛们，他们在做WPS和表格处理之类的软件时，不知是否有较大的原创算法在里面，如果有的话就算我错把他们划到了大牛层。由于所学有限，不知道国内还有那些人能够得上"大师"的级别，或许有少量做研究的教授、院士们，可以达到这个级别，有知道的不妨回个帖子晾一晾。
鉴于"大师"这个称号的光环效应，相信有不少人梦想着成为"大师"。或许你看了前面举的一些大师的例子，你会觉得要成为大师非常困难。不妨说一下，现在有一条通往"大师"之路的捷径打开了，那就是多核计算领域，有大量的处女地等待大家去挖掘。
以前在单核时代开发的各种算法，现在都需要改写成并行的。数据结构与算法、图像处理、数值计算、操作系统、编译器、测试调试等各个领域，都存在大量的机会，可以让你进到这层楼来，甚至有可能让你进到更高一层楼去。
第8层科学家
科学家向来都是一个神圣的称号，因此我把他放在了&大师&之上。要成为科学家，你的贡献必须超越大师，不妨随便举一些例子。
如果你象Dijkstra一样设计了ALGOL语言，提出了程序设计的三种基本结构：顺序、选择、循环，那么你可以爬到第8层楼来。顺便说一下，即使抛开这个成果，Dijkstra凭他的PV操作和信号量概念的提出，同样可以进到这层楼。
如果你象Don Knuth一样，是数据结构与算法这门学科的重要奠基者，你也可以进到这层楼来。当然，数据结构和算法这门学科不是某个人开创的，是许多大师和科学家集体开创的。
如果你象巴科斯一样发明了Fortran语言，并提出了巴科斯范式，对高级程序语言的发展起了重要作用，你也可以进到这层楼来。
或者你象Ken Thompson、Dennis Ritchie一样发明了Unix操作系统和功能强大、高效、灵活、表达力强的C语言，对操作系统理论和高级编程语言均作出重大贡献，那么你也可以进到这层楼来。
或者你有Frederick P. Brooks一样机会，可以去领导开发IBM的大型计算机System/360和OS/360操作系统，并在失败后反思总结，写出《人月神话》，对软件工程作出里程碑式的贡献，你也可以进到这层来。
或者你提出了面向对象设计的基本思想，或者你设计了互联网的TCP/IP协议，或者你象Steven A.Cook一样奠定NP完全性的理论基础，或者你象Frances Allen一样专注于并行计算来实现编译技术，在编译优化理论和技术取得基础性的成就，&，均可进入这层。
当然，如果你发明了C++语言或者Java语言，你进不到这层来，因为你用到的主要思想都是这层楼中的科学家提出的，你自己并没有没有多少原创思想在里面。
看了上面列出的科学家的成就，你会发现，要成为&科学家&，通常要开创一门分支学科，或者是这个分支学科的奠基者，或者在某个分支学科里作出里程碑式的重大贡献。如果做不到这些的话，那么你能象Andrew C. Yao（姚期智）一样在对计算理论的多个方向如伪随机数生成，密码学与通信复杂度等各个方向上作出重要贡献，成为集大成者，也可以进入这层楼。
成为&科学家&后，如果你有幸象Dijkstra一样，出现在一个非常重视科学的国度。当你去世时，你家乡满城的人都会自动地去为你送葬。不过如果不幸生错地方的话，能不挨&板砖&估计就算万幸了。
从上面随便举的一些例子中，你可能能猜到，西方科学家的数量是非常多的，于是你会想中国应该也有少量的科学家吧？我可以很负责任地告诉你一个不幸的结果，中国本土产生的科学家的数量为0。目前在国内，软件领域的唯一的科学家就是上面提过的姚期智，还是国外请回来的，并不是本土产生的。
可能你不同意我说的本土科学家数量为0的结论，因为你经常看到有许多公司里都有所谓&首席XX科学家&的头衔。我想说的是，这些所谓的&首席XX科学家&都是远远够不到这层楼的级别的，有些人的水平估计也就是一个&牛人&或&大牛&的级别，好一点的最多也就一个&学者&的级别。尤其是那些被称作&首席经X学家&的，基本上可以把称号改为&首席坑大家&。
虽然我国没有人能爬到这层楼上来，但是西方国家仍然有许多人爬到了比这层更高的楼上。如果要问我们比西方落后多少？那么可以简单地回答为：&落后了三层楼&。下面就来看看我们做梦都没有到过的更高一层楼的秘密。
usidc 13:50 * 最近参加了一场面向移动互联网开发者的半公开会议，说是半公开，是因为场地选择在了企鹅公司的大楼里面，每个参加者都需要贴上企鹅公司的&来宾& 胸贴才能进入，这让P皇突然回味到了在北京MIX泡夜场的青葱时代啊，进门前几个彪形大汉在门口虎视眈眈，每人拿个戳，交钱卡戳放人！ 企鹅公司的保安虽然看起来不像东北大汉，但也有点中南海保镖的感觉。在我看来，作为一个正在标榜开放共赢的公司来说，森严的保卫措施传递出来的意味，和开放还是有点差距。
* 人气依然很旺，因为组织方邀请了不少有着人民币、美元背影的投资人过来参与，参会的大多是胸怀着无比美好的移动互联网创业理想，但目前正处于苦逼阶段的屌丝技术宅男；和投资人身上散发出的金光闪闪的气场比起来，我总是感觉大多数创业者投射出来的都是惨绿的迷茫感。
* 所讲的内容到没有什么太大的新意，广告时间+无太多意义的分享为主，有着世界一流名校背景的团队在干着用专业水准来山寨copy idea的投机工作；来自草根的创业团队结合着华强北的吸金套路做着微创新；还有不少独立coder只是在按照自己的喜好做着目的不太明确的项目；更有一些老牌公司在这个新的领域里面再寻找翻身的机会；台下的听众里面，不知台上所云、面露疑惑者有之；心怀非议，面露鄙夷者有之；无关无聊，呼呼大睡者也有之；话说有不少人是为了试试自己的运气，看看最后那台传说中的小米神器会花落谁家吧！难得的倒是，最后论坛时间的时候，几位投资人倒是说了三分真话，然而真话听到最后，P皇的感觉只有一个字来形容&&冷！真TM冷！
* 除了企鹅公司的空调应景的开的很大，让人身冷；投资人们的观点冷峻，冰水泼的让人心冷之外，也有某已经功成名就的大公司投资部的哥们一语惊人冷笑话冷出了经典：&移动互联网里面不止C多，B也多，大家更应该关注B的生意&。当然，人家说的C与B指的是B二B二C的意思；是否有双关之意不敢说，曲解成当今流行的B的含义，似乎也成立！微信、momo、友加、58同城、9158&& 赚钱、赚眼球、赚投资人热捧的项目，都是这些推动ONS的先行者啊！金领、宅男和农骗们真应该为移动互联网欢呼！欲女和职业工作者们也应该成为移动互联网忠实的簇拥！没啥可后悔的，因为事实上的天朝社会早就是这个样子了，用技术来反映、释放并撮合人类男女内心最大的欲望，然后从这种撮合中赚到银子，这不就是WEB X.0的含义么！
* 晚饭的时候，面对一桌不知道有没有地沟油的川菜大餐，年轻的小伙子们在热议的是怎么把MOKO上的模特们变成自己应用上用来吸引宅男眼球和用来变现的资本；这些20多岁的美女们，或许也知道世界上有一帮子人来用自己的身段赚取肉金吧，也不在乎互联网圈子里面再多赚一道，何况毕竟互联网圈子里面的人还算是文明多了！
* 天朝V5！让无数本来有希望变成乔布斯的青年才俊心甘情愿地，大踏步地走在20年后变成绝对符合非诚勿扰标准的，坐在大奔里面搂着美女数钱的猥琐大叔了！
usidc 11:32可能除了哲学家以外，我认为程 序员是最懒的一群人。他们的职业看起来又似乎有一定的劳动强度。想想看，生物学家要亲自做所有的实验&给数百只小白鼠注射药物不可能自动完成。医生必须给 病人进行身体检查；教授每年都要教授同样的课程；建筑师从各个角度制定方案，并手工地将方案一笔一划绘制出来。 让我们再来看看更为辛苦的一些职业，情况更糟。营销人员要不断重复地进行同样的产品宣传；理发师日复一日地做着同样的事情；收营员每天都以相同的方式对货物进行结算&工厂工人&
你面前呈现出了一幅图片，世界上有很多这样的人，他们每一小时，每一天，每一年，有些甚至一辈子都在重复做着几乎相同的事情。
来看看程序员
每当我们想连续两次做同样的事情时&我们会尝试想一个方法来自动完成此过程。每当你写的代码是完成同样的一件事时，你会开始寻找一个库；每当你启动一个类似的项目时，你会去寻找一个模板。
程序员的生活就是致力于消除重复的工作。
将琐碎地任务从我们的工作流程中剔除，这能让每个人生活得更轻松。这里有一个经典的笑话，说一个程序员情愿用一周的时间来写一个拷贝脚本，也不愿意将相同的文件复制粘贴两次，尽管复制粘贴可能只需要两分钟。
该死的，我们要遵循DRY（Don&t Repeat Yourself不要重复自己）的原则。这个原则的基本内容是宁愿创建一个令人费解的抽象类，也不要将不相同但非常相似的代码写两次。这当然会导致很多问题。
一般的软件项目充满了在顶层抽象类上构建的抽象类，你慢慢地会不清楚这些顶层抽象类将如何工作。甚至你完全不知道其代码在做什么。&Dizzying but invisible depth&，涉及到这个问题时，你真的应该读读这篇短文。
另一方面，懒惰本身已经证明了历史上许多科学和工程发展所带来的背后推动力。用有轮子的拖车运东西比人工搬运要轻松；用船在水中前行比游泳来得容易；甚至如果你他妈的想炸掉一座城市，你投掷一颗原子弹也比投掷几千个小炸弹来的容易。
所以这也许并不是说程序员是懒惰的。也许真正懒惰地是工程师们。只是恰巧在这样一个历史时刻，程序员作为工程师中最鲜明的一类，总是将世界向更好更光明的未来推动。而其它大多数领域已经在某种程度上稳定下来，或者需要更长的时间去适应新的工具。
这里有一个重要的问题要问：程序员天生就懒吗？聪明懒惰的人容易被编程工作吸引吗，或者这是一种社会效应？懒惰源于最好的编程实践？还是最好的编程实践源于懒惰呢？
最近，我有机会将一个建筑专业学生的一天与一个计算机科学专业的学生（就像我自己）的一天进行比较。
大多数的建筑系学生的生活充满了这样或那样劳动密集的任务，这些任务是她工作的一部分。在任何时候，她都有可能要对一些模型进行拼凑粘合，在 AutoCAD中从50个不同的角度对同一个物体进行绘图，或者在其它3D建模软件中重复相同的事情&然后将这些图片导入到Photoshop中成为真正 好看的图。
这种事会接连不断的发生。我估计她花费在课程作业上的时间比她实际上课的时间多一倍还不止（事实上她说花了5倍还多）。更糟糕的是，更好的完成这些任务并不能真正加快完成任务的进程，这只是意味着你多知道了几个键盘快捷键，意味着下次画图时你可能会少犯几个错误。熟练和精通完全无法优化关键的部分。
相比之下，当我不上课时，我通常都在做自己的项目。因为我可以，因为我有充足的时间。当有作业布置下来时，一般情况下，我都可以在几个小时内完成&即使是最关键最重要的项目，老师也很少给我们超过一周的时间来集中完成作业，最多两周。
精通编码并不意味着你打字更快（与建筑专业中等同的能力不同）。它意味着想出的解决方案更容易实现，利用工具来达到事倍功半的效果，诸如此类。最终，通过 互联网进行测试评判，而实现过程是最无关紧要的部分，因为每个人都会。如果你有一天的时间，你可以实现某些东西。如果你有更多的时间，你可以使这些东西实 现得更漂亮，模块化更高，可重用性更强，等等。
基本上你能够快速地实现眼前的任务，你工作中大部分时间都在致力于使你的任务完成得更加漂亮。但这对于你手头的任务来说其实并不重要，你这样做是因为你可以。
甚至于当程序员对自己的优化工作都产生厌倦时，他们会立马转而去创建工具来完成优化工作。
事情就这样周而复始地重复着。
接下来的家伙会使用他创建的新工具，使实现过程变得更快，接着优化它直到他最终厌倦，然后创建了一个新的更好的工具。
所以&是辛苦的工作？
但回到我最初的观点，辛苦工作对程序员的生产效率存在多大的影响？对于那些每天辛苦工作13小时以上，以取得竞争优势的创业者来说，这又意味着什么？这是值得考虑的一种优势吗？
辛苦的工作可能对程序员工作效率产生负面的影响。它掩盖了背后所做的优化工作&哦，我可以手动把它完成，这将只需要10分钟时间&（其实这需要20分钟）。下一次，一个相似的任务到来时，你可能需要再次手动把它完成，长此以往&
最重要的是，辛勤地工作会使你变得很笨。许多研究表明，持续疲劳的状态会使你做出错误的决策，甚至过多的决策也会让你会出错误的决定（称为决策疲劳）。事情上，这可能是我们喜欢创建抽象类并使用它们的原因&让其它人做大多数的决策，这样我就可以只专注于关键的部分。但是，我仍然没弄懂，到底是懒惰的人更喜欢编程，还是编程使他们变得懒惰&
usidc 11:33马克&吐温曾经说过，所谓经典小说，就是指很多人希望读过，但很少人真正花时间去读的小说。这种说法同样适用于&经典&的计算机书籍。
在Stack Overflow(以及其它很多软件论坛)上，诸如&程序员最应该读的计算机书籍有哪些?&这样的问题会周期性的出现。这样的问题不断的被提出、被回答，只是形式不同罢了。相同的几本书总是会出现在清单的前几名内，所以，如果想知道人们谈论的都是些什么，你有必要去读一读这些书的。
大多数程序员真正读过的计算机书籍代码大全(Code Complete)&&两届Software Jolt Award震撼大奖得主！程序员修炼之道（The Pragmatic Programmer）C程序设计语言( C Programming Language)(第2版)重构:改善既有代码的设计（Refactoring: Improving the Design of Existing Code）人月神话（The Mythical Man-Month）编码&&隐匿在计算机软硬件背后的语言（Code: The Hidden Language of Computer Hardware and Software）Head First 设计模式（Head First Design Patterns）编程珠玑（Programming Pearls）Effective Java中文版（Effective Java (2nd Edition)）or Effective C++（第三版）中文版Test Driven Development: By Example上面的这些书我自己都读过，所以我不难相信很多不是很优秀的程序员也都读过它们。如果你对编程有足够的兴趣，能够来到这里读这篇博客，你很可能读过 其中的大部分，甚至还有很多不在这个清单中的，所以我就不浪费时间每本书都评论一番了。我想说的是，这个清单上的每本书都是它各自领域里的奇书。所以，很 多有愿望不断提高自己的编程技术的程序员都读过这些书，这就不足为怪了。
在人们备受推崇的计算机书籍中，还有一类书受到了独特的待遇。我称下面这个清单为&最常被程序员们谎称读过的计算机书籍&。这并不是说推荐这些书的 人都没有真正读过它们。我只是有相当的信心怀疑更多的人只是在口头上宣称读过下列书籍，而实际上很少人真正读过它们。下面就是这个清单。
最常被程序员们谎称读过的计算机书籍算法导论（Introduction to Algorithms）(CLRS) 这本书的名称是所有出版过的计算机书籍中最让人误解一个。它被广泛的使用在很多大学里，通常被当作毕业生必需的算法课程。于是，只要在大学里上过计算机课 程的学生几乎都有一本这样的书。然而，除非你拥有计算机硕士学位(而且是算法研究领域的)，我怀疑你顶多只读过算法导论（Introduction to Algorithms）里节选的几章内容。这个书名让人误解，是因为&Introduction&这个词让人以为它很适合初级程序员。实际上不是。这本书对算法做尽可能详尽综合的介绍，就像其它一些随处可见的类似的书一样。请不要再把这本书推荐给初学者。编译原理(Compilers: Principles, Techniques, and Tools)(the Dragon Book).这本恐龙封面的书涵盖了开发一个编译器你所需要的全部的知识。它的内容包括词汇分析，语法分析，类型检查，代码优化，以及其它很多高深的题 目。请不要把这本书推荐给初级程序员，他们需要的只是分析简单的包含数学公式或HTML的字符串。除非你真的需要实现一个能够实用的编译器(或解释器)， 你根本不需要掌握这本&恐龙&书的全部强大威力。把它推荐给一个遇到简单文本分析问题的人，这证明你根本没有读过它。
计算机程序设计艺术(The Art of Computer Programming)(TAOCP) 我经常听到人们把这本书描述为&每个程序员必读&的系列计算机书籍。我认为这明显不是实情。在我说出这样大不敬的话、被你们用板砖拍死之前，请让我做解释 一下。这不是一本让你一页一页翻着读的书。这是一本参考大全书。把它放在你的书架上看起来会很不错(实际上也它确实很好)，但如果想把它通读一遍，你需要 几年时间，而且最后什么都没记住。这并不是说手边放这样一本书没有什么价值。它是一本参考书，当我遇到难题，走投无路时，很多次我都在这本书里找到办法。 但这本书终究是被我当作参考书。它复杂难懂，很理论，里面的例子都是汇编语言的。好的一面是，如果你想在这本书里寻找针对某一问题的解决方案，如果你找不 到，那就说明这个问题无解。它是一本对它所涉及到的领域做了最最详尽介绍的一本书。
Design Patterns: Elements of Reusable Object-Oriented Software(Gang of Four)这本书是唯一一本在这个清单里我从头到尾读过的书，读的结果是，我不知道该把这本书归到哪个类别。它出现在这个清单里，并不是因为我认为只有很少人真正读过它。很多人都读过。只是因为有更多推荐过这本书的人自己却没有读过。Design Patterns这边书的问题在于，很多书里给出的信息，你在其它很多地方都能看到。这样就使得一个初学者在维基百科上读了几篇关于设计模式的内容后，就敢在面试中宣称自己看过这本书。这就是为什么Singleton成 了一种新的全局变量的原因。如果有更多的人花时间读过这本也叫做Gang of Four的书的原著，那世界上就不会有这么多人会把17种设计模式硬塞到一个日志(logging)框架里了。这本书最精彩的部分是每章里描述如何正确的 使用一种模式的段落。遗憾的是，这些精华却在很多其它设计模式资料里被漏掉了。
C++程序设计语言(The C++ Programming Language)这本书不像一本编程教材，更像一本编程语言参考。有很多的迹象表明有人确实读过这本书，否则我们不可能有这么多的C++ 编译器可选择。编程初学者(或者甚至其它语言的专家)，如果想学C++，不应该直接去啃C++程序设计语言(The C++ Programming Language)这本书。告诉他们去读《C++ Primer中文版》。
正如我之前说的，我知道你们当中会有一些人真正的读过这些书。那这篇文章不是针对你的，针对的是那些企图通过假装读过这些书来表现自己的民众。 如果你自己没有读过这些计算机书籍，请不要推荐给别人。这样做会耽误别人的时间，误人子弟，因为一些阅历更丰富的人可能会有更好的书(更针对某一领域，更容易理解，跟某种编程语言或某种编程水平更契合的书)来推荐。除此之外，你也能避免被那些真正读过计算机程序设计艺术(The Art of Computer Programming)的人用MMIX知识给拷问住造成的尴尬(如果你不知道我在说什么，那我指的就是你)。
usidc 20:33如 果人们非要拿C++和Java来作比较，我建议他们去阅读The Design and Evolution of C++，看看C++为什么是今天这个样子，用我在设计C++时遵从的原则来检验这两种语言。这些原则与SUN的Java开发小组所持的理念显然是不同的。 除了表面语法的相似性之外，C++与Java是截然不同的语言。在很多方面，Java更像Smalltalk。（Sun的培训教材清楚地写道：Java在设计上采用了与C++相似的语法，与Smalltalk相似的语义。所以可以说Java与C++是貌合神离，与Smalltalk才是心有灵犀。）Java 语言相对简单，这部分是一种错觉，部分是因为这种语言还不完整。随着时间的推移，Java在体积和复杂程度上都会大大增长。在体积上它会增长两到三倍，而 且会出现一些实现相关的扩展或者库。这是一条每个成功的商业语言都必须走过的发展之路。随便分析一种你认为在很大范围内取得了成功的语言，我知道肯定是无 有例外者，而且实际上这非常有道理。
　　上边这段话是在Java 1.1推出之前写 的。我确信Java需要类似模板的机制，并且需要增强对于固有类型的支持。简单地说，就是为了基本的完整性也应该做这些工作。另外还需要做很多小的改动， 大部分是扩展。1998年秋，我从James Gosling（Java语言的创始人）那里得到一份建议书，说是要在Java中增加固有类型、操作符重载以及数学计算支持。
　　还有一篇论文，是数学分析领域的世界级大师，伯克利大学的W. Kahan教授所写的How Java's Floating-Point Hurts Everyone Everywhere（且看Java的浮点运算如何危害了普天下的芸芸众生,点击超链接进入详情），揭露了Java的一些秘密。我发现在电视和出版物中关于Java的鼓吹是不准确的，而且气势汹汹，让人讨厌。大肆叫嚣凡是非Java的代码都是垃圾，这是对程序员的侮辱；建议把所有的保留代码都用Java重写，这是丧心病狂，既不现实也不负责任。Sun和他的追随者似乎觉得为了对付微软罪恶的&帝国时代&，就必须如此自吹自擂。但是侮辱和欺诈只会把那些喜欢使用不同编程语言的程序员逼到微软阵营里去。
　　Java并非平台无关，它本身就是平台。跟Windows一样，它也是一个专有的商业平台。也就是说，你可以为Windows/Intel编写代码，也可以为Java/JVM编写代码，在任何一种情况下，你都是在为一个属于某个公司的平台写代码，这些代码都是与该公司的商业利益扯在一起的。当然你可以使用任何一种语言，结合操作系统的机制来编写可供JVM执行的程序，但是JVM之类的东西是强烈地偏向于Java语言的。它一点也不像是通用的、公平的、语言中立的VM/OS。私下里，我会坚持使用可移植的C++作大部分工作，用不同的语言作余下的工作。
　　&Java is not platform-independent, it is the platform&，B. S (Bjarne Stroustrup)的这句评语对于C++用户有着很大的影响，有些C++高手甚至把这句话作为自己的签名档，以表明对Java的态度和誓死捍卫C++的决心。
&Java is not platform-independent, it is the platform&-----B. S (Bjarne Stroustrup)&Java并非平台无关，它本身就是平台&-----C++之父 比雅尼&斯特劳斯特鲁普
usidc 20:34不久前，在互联网上出现了一篇有趣的文章，讲的是对于同一个问题，不同层次的Python程序员编出的Python代码显示出了不同的风格，代码都 很简单，有趣。
def factorial(x):if x == 0:return 1else:return x * factorial(x & 1)print factorial(6)一年编程经验(学Pascal的)
def factorial(x):result = 1i = 2while i &= x:resultresult = result * iii = i + 1return resultprint factorial(6)一年编程经验(学C的)
def fact(x): #{result = i = 1;while (i &= x): #{result *=i += 1;#}#}print(fact(6))一年编程经验(读过 SICP)
@tailcalldef fact(x, acc=1):if (x & 1): return (fact((x & 1), (acc * x)))else: return accprint(fact(6))一年编程经验(Python)
def Factorial(x):res = 1for i in xrange(2, x + 1):res *= ireturn resprint Factorial(6)懒惰的Python程序员
def fact(x):return x & 1 and x * fact(x & 1) or 1print fact(6)更懒的Python程序员
f = lambda x: x and x * f(x & 1) or 1print f(6)Python 专家
fact = lambda x: reduce(int.__mul__, xrange(2, x + 1), 1)print fact(6)Python 黑客
import sys@tailcalldef fact(x, acc=1):if x: return fact(x.__sub__(1), acc.__mul__(x))return accsys.stdout.write(str(fact(6)) + &\n&)专家级程序员
from c_math import factprint fact(6)大英帝国程序员
from c_maths import factprint fact(6)Web 设计人员
def factorial(x):#&&&&&&&&&&&&&&&&-#& Code snippet from The Math Vault &#& Calculate factorial (C) Arthur Smith 1999 &#&&&&&&&&&&&&&&&&-result = str(1)i = 1 #Thanks Adamwhile i &= x:#result = result * i #It&s faster to use *=#result = str(result * result + i)#result = int(result *= i) #??????result = str(int(result) * i)#result = int(str(result) * i)i = i + 1return resultprint factorial(6)Unix 程序员
import osdef fact(x):os.system(&factorial & + str(x))fact(6)Windows 程序员
NULL = Nonedef CalculateAndPrintFactorialEx(dwNumber,hOutputDevice,lpLparam,lpWparam,lpsscSecurity,*dwReserved):if lpsscSecurity != NULL:return NULL #Not implementeddwResult = dwCounter = 1while dwCounter &= dwNumber:dwResult *= dwCounterdwCounter += 1hOutputDevice.write(str(dwResult))hOutputDevice.write(&\n&)return 1import sysCalculateAndPrintFactorialEx(6, sys.stdout, NULL, NULL, NULL,NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL)企业级程序员
def new(cls, *args, **kwargs):return cls(*args, **kwargs)class Number(object):passclass IntegralNumber(int, Number):def toInt(self):return new (int, self)class InternalBase(object):def __init__(self, base):self.base = base.toInt()def getBase(self):return new (IntegralNumber, self.base)class MathematicsSystem(object):def __init__(self, ibase):Abstract@classmethoddef getInstance(cls, ibase):try:cls.__instanceexcept AttributeError:cls.__instance = new (cls, ibase)return cls.__instanceclass StandardMathematicsSystem(MathematicsSystem):def __init__(self, ibase):if ibase.getBase() != new (IntegralNumber, 2):raise NotImplementedErrorself.base = ibase.getBase()def calculateFactorial(self, target):result = new (IntegralNumber, 1)i = new (IntegralNumber, 2)while i &= target:result = result * ii = i + new (IntegralNumber, 1)return resultprint StandardMathematicsSystem.getInstance(new (InternalBase,new (IntegralNumber, 2))).calculateFactorial(new (IntegralNumber, 6))
usidc 00:19导读：许多团队都使得他们的基础架构越来越复杂，YouTube团队却尽量保持简单的风格。正是凭借简单的技术哲学，才成就了YouTube在线视频王者的盛名。
如果你想构建一个可以承载日访问量40亿次的网站，YouTube有许多值得借鉴的地方。本文是YouTube的工程师Mike Solomon在PyCon（PyCon是Python开源社区的开发者年度盛会）上关于YouTube扩展性演讲的摘要，相信会对大家有所启发。许多团队都使得他们的基础架构越来越复杂，YouTube团队却尽量保持简单的风格。他们使用Python作为主要开发语言，使用MySQL开源数据库，并一直使用Apache作为Web服务器。对一个如此庞大的站点而言，许多重要特性都源于点点滴滴的Python代码。这并不意味着YouTube不追求创新，他们更追求一种技术哲学，而非炒作。究竟是什么成就了世界上最大的视频网站？敬请阅读。惊人的数字
* 日访问量40亿次每分钟上传60小时的视频超过3.5亿终端访问利润是2010年收入的双倍视频的数量上升了9个数量级，开发人员却只上升了2个数量级一百万行Python代码
* Python：Python是YouTube的主要编程语言。Apache：YouTube一直使用Apache，每次HTTP请求都经由Apache。Linux：Linux是构建YouTube的基石，它有许多强大的工具，如strace何tcpdump。MySQL：MySQL有庞大的用户群。YouTube使用它的关系数据库特性，也使用它存储BLOB数据。Vitess：Vitess是由YouTube发起的一个开源项目，旨在打造高性能的MySQL前端。Zookeeper：分布式的锁服务器。Wiseguy：一个CGI Servlet容器。Spitfire：一个模板系统。Serialization formats：YouTube重写了BSON实现，速度提升了10-15倍。
关于扩展性的思考以下虽然都不是什么新思想，但希望对你有所助益。
* 分而治之是扩展性技术的灵魂。考虑以层次化的方式完成所有的工作。这也是数据分片的症结所在。要知道如何将数据分区，以及如何将已分区的数据进行关联。总而言之，保持简单与松散的耦合非常必要。充分利用Python的动态特性，构建易于扩展的软件架构。近似的正确性。要相信监控系统所报告的系统运行状态。如果问题没有出现，就认为一切良好。不一致的数据模型。例如，阅读评论的人和写评论的人对你刷新页面的动作会有不同的反应，但也不必完全基于事务处理进行系统设计，这会显得矫枉过正。我们依然需要不一致的数据模型。分布式系统的随机性。分布式系统就如同气象系统一样，对分布式系统进行调试会存在更多的随机性。例如，缓存过期。一般情况下，服务器会将流行的视频缓存24小时。如果一旦出现缓存同时过期的情况，服务器将同时开始缓存，荷载如闻惊雷！最快的函数调用就是不做任何调用。合理设计事务处理发生的间隔和次数。仔细观察API，并做到心中有数。如何定义输入、输出？所有的函数调用本质上都是围绕数据发生的，那在函数调用之后，又会发生什么？在Python中运用RPC重定向。程序员是代码的构建者，因此要做好约定。如果代码不幸失败了，还可以从RPC输出中追查原因。没有完美的组件。一个组件的运行周期可能持续1-6个月，具体多久，谁也说不清。随着时间的推移，我们会用Python和C重写一些东西，这证明你正在淘汰旧的组件，当你观察到一个新组件出现的时候，它诞生了。没有人了解整个系统的运作机制。因此，我们需要定义组件。视频转码和视频搜索截然不同，建立良好的数据规范非常重要。效率与扩展性并重。最有效率的是用C实现进程，但这样的方式缺乏扩展性。着眼于宏观层面、组件及其失败的原因。使用RPC是否明智？内联如何？进行分解研究，也许会发现不同之处。重视算法。与其绞尽脑汁用Python来实现高效的算法，不如用它做些更有实用价值的事。在这方面，C语言有它的优势。我们很少从事面向对象设计。我们使用了大量的名称空间，使用类来组织数据，但极少面向对象。我乐意用下面的词汇来形容我们的代码树：简单、实用、优雅、正交、可组合，这是我们的追求。
总结YouTube解决问题的哲学只有一个词：简单。许多YouTube的产品最初只是源于一个简单的Python脚本。这正是应了我们的一句老话，不积跬步，无以至千里；不积小流，无以成江海。
usidc 11:38编写代码大致如写散文。先从大纲开始。可以是一些要点或伪代码，或许已经胸有成竹，亦或是记录在笔记本上，这都不重要。写完了初稿。这是能运行的最 短、最简单的东西。它可能不是很漂亮，但已把要点表达清楚。你可能注意到了它的不足之处，更为重要的是，知道为什么会有（不足之处）。你只想让它能跑起 来。它可以稍后再精炼。
而这正是下一步要做的：终稿成品。成品将打磨、审查、编辑、调试。处理特殊问题（&edge case&），提供来源，匹配户型，并正确格式化。这类型的东西，就是一篇出色散文或一段代码之类的样例。
故而散文和代码相似。它们的开发方式亦相似。为什么&软件开发人员&对你重要？因为你能用作家所使用的策略来提升改善你的代码。
虽然同行评审实际上是书面作品的评审标准形式，但我感觉有点不适用于代码。所有程序员往往只专注于他们的程序输出。除了展示项目，有一个不错方法可以抵消这个，自公布代码。（A good way to counteract this is is to publish the code itself in addition to showcasing the project.）Github 的出现，使这个屡见不鲜了。
但成为一个更出色的程序员，甚至比这还容易。要做事情就是阅读更多的代码。优秀的作家大量阅读，优秀的程序员亦当如此。你阅读的代码不一定非常实用，可以只是非常有趣。可能稍后就能派上用场。
幸运的是，这两个建议相辅相成。通过公布你的代码，你给了其他开发人员提供阅读材料。他们的代码将会提高改善，期望他们也将公布代码。如此一来，你也能从中学习。
usidc 14:51这是来自新加坡的 iOS 开发者 Kent Nguyen 发表在1月底的一篇博文。这篇吐槽文在 iOS 开发圈子里流传甚广，从原文150多个评论就可见一斑，现翻译如下。让我们开门见山吧：做一个iPhone应用需要花多少钱？ 就是这个最常见的问题，我的很多朋友（大多是些西装革履的商务人士），还有我那些个对技术一知半解的客户们，他们都问过我这个的问题。通常，我会先给出一 个大致的报价，这个报价并没有细致到需要签合同确认每一个功能点的地步。即便是这样，每当的我报价一出口，对方都毫无例外的给惊着了（当然不是因为便宜）。
说实话，我没有狮子大开口。看看StackOverflow上这个著名的帖子吧，讨论的是开发Twitterific这 样一款应用需要多少钱，后来讨论范围扩展到开发一个iOS应用的合理费用范围。虽然这个帖子是在2008年发布的，而帖子的最佳答案是由一名来自 Twitteriffic的开发人员于2010年回答的，但是时至今日，帖子里面讨论的数字仍然是很靠谱的，而且我预计到2012年底依然有效。而我的报 价和这个帖子里面的数字比起来，简直是小巫见大巫了。
现在的趋势是，什么公司什么业务都想搞个iOS客户端，并且这种趋势在2012年看似依然火爆。所以我想起来写这篇博文，我想说一下开发一个iOS应用会 碰到的各种细节问题和横生的变数，借此解释为什么iOS应用开发成本这么贵。如果你在考虑搞一个iOS应用，而你本身是搞业务而不是做技术的，如果你目前 正在招标或者仅仅是想了解一下，那我这篇博会对你有帮助。当然，我说的东西并不局限于iOS应用开发，对Android、Windows Phone或者是Blackberry（如果RIM还能活的话）等移动应用平台基本上也是适用的。
开发之前需要仔细考虑的
别做拍脑瓜的决策，在开工之前你需要考虑的比你想象的要多。我通常会帮助或者指导客户把以下几个要素都过一遍：
一：和客户谈他们的移动应用，最让我吃惊的是他们从来没有想过支撑一个iPhone应用运行，背后需要涉及到的方方面面。他们想象中的iPhone是独立 存在于这个宇宙的，是如此的简单，以至于他们要我很快就给出一个项目预算报价，而不用讨论诸多细节。我问他们：&你们是否考虑过后台服务器的事情？你们的 应用需要和后端服务器做数据通讯？& 什么，听不懂？好吧，我用地球人的语言再把这个问题讲 一遍：&你们的应用不是需要用户注册嘛，你们考虑过把用户的数据存放在哪里了吗？我们需要一个地方去保存这些以后会用到的数据。& 第一次碰到这样的客户时，哥简直就怒了。后来我发现这不是客户的错：我是搞编程的，CS架构对我来说就像吃饭睡觉一样是不假思索的东西，而我的客户尽是些 高富帅，他们懂个毛CS架构！
所以，如果你不大懂技术，那请仔细听我说：如果你想做的移动应用需要用户注册和登录，或者你想随时控制移动应用的一些输出，甚至是你仅仅是需要一个用户反馈意见调查表这么简单的功能，那么，你得搞一台后端服务器。
二：好了，现在你知道你需要一台后端服务器。同时你还需要想办法让你的iOS应用和你的服务器能够对话，就是相互间接收数据什么的。不，这个问题不是简答 靠什么标准的即插即用的东东就能解决的，不是你们想象的那样！所有的东西都需要定制化开发，这就好比发明一门语言：你希望你的服务器和你的应用之间能够通 过一种语言沟通，但是你不希望其他人听得懂这门语言。
用行话说这就是制定服务器端API接口，或简称API。这些API应该在开发iPhone客户端之前就到位了。为什么？因为你必须先规定好一门语言的单词和语法，然后才能用这门语言说话吧！？好了，这就带出了第三点&如何开发这些API。
三：API的成功定制是项目成功的一半（反之亦然），所以千万不要掉以轻心。你要考虑你的业务数据模型、业务流程、调用业务需要提供的参数、特定事件发生 时数据间该如何互动等等。简单来说，我们要做的就是开发一个网站，上门跑着你的业务流程，只不过这个网站的所有运行结果都不是通过网页形式展现出来，而是 呈现在一行行的文本和数字中。举个例子：一个登录成功的反馈页面仅仅包含YES一个单词。
iPhone应用需要访问这些预先定义好的接口，并且按预定义格式提供必要的输入（比如用户名和密码），然后要对服务器端的反馈（YES或者NO）做出解析处理。所以，没有什么移动应用能够自动的含有用户注册和登录功能。
服务器端开发需要考虑的问题太多了：选择服务器，选择用什么语言开发，主机放在哪里才能增加访问速度，等等，这里我就不展开了。如果这一切对你来说很陌生，那么你最好去问问团队里的技术负责人，或者干脆让开发人员做决策。
四: 所以，关于服务器端API，你或者让自己的技术团队把它开发好，再将完善的API文档交给iPhone应用开发人员；或者你支付iPhone应用开发人员 额外的报酬来搞定这些。你找的iPhone应用开发人员可能会服务器端开发也可能不会。如果他会的话，我建议最好让他也同时负责服务器端开发，因为他最清 楚iPhone应用中需要哪些服务器端API。
如果你的服务器端API已经存在了，那么除了向iPhone应用开发人员提供相关文档之外，你还要考虑让他能够便捷的同服务器开发团队沟通，因为大多数情况下，iPhone应用需要在已有API基础上增加一些新的接口。
现在我们来看看iPhone应用开发本身
扯了大半天，我们终于开始谈iPhone应用开发本身了。一般来说，iOS平台上做所有事情都不能随心所欲。你最好在开发人员写代码之前把所有的需求都确认好好。这和开发网站不一样，按照实现签订的合同开发iOS应用，开发过程中对需求变更的容纳度可能很低：
用户界面： 无论你打算采用iOS标准界面还是自定义元素，在开发开始前一定要确认清楚，因为应用的程序架构是根据界面和用户使用流程来设计的。一个很好的例子就是在 界面底部使用了iOS标准的标签栏（Tab Bar），此后如果你想让标签栏里面的图标变成彩色的，这个代码改动量可没你想象的那么小！
代码之间的耦合： 如果是开发网站，你可以随意的添加一个页面或者一处链接。做iOS应用就没有那么简单了，很多东西一开始都要设计好，后期的一处改动会牵连很多东西，具体 原因是你无法理解的。iOS应用的代码写好之后，再改动行不行？行！但必须小心。 这就像设计电路板一样， 如果你不小心把那根线搭错了，整块电路板就会不工作。有人说架构优良的程序可以有很高的延展性，那纯属纸上谈兵。在About屏幕上添加一个电子邮件按钮 可能只需要几行代码的工作量，而添加一个转发到新浪微薄的按钮（译者注：原文是添加一个Facebook Like）就完全不是那么简单的事儿了！
让一个iPhone应用同时也支持iPad： 如果要评选最坑爹&需求变更&，那么这个绝对是当之无愧的。理由很简单：支持iPad根本不是TMD什么附加功能！iPad应用基本上都比iPhone应 用来得要复杂，界面设计和用户体验也大不一样。我问你，制造一辆电动自行车，然后把它改装成一部烧汽油的摩托车，这能是一回事儿吗！？电动自行车跟摩托车 看起来是很像，但是制造它们完全是两码事。
拿广受欢迎的Facebook官方应用来说，它的iPhone和iPad版本看似相似，实际用户操作流程完全不同。不仅仅是界面上的不同会带来额外的工作，对后台服务器API的需求也可能不一样。拿我熟悉的一个应用Denso来说（我熟悉它因为这是我开发的），它的iPad版本比iPhone多了几个功能，这些都需要额外的服务器端API来支持。记住，iPhone和iPad应用的用户体验需求是完全不一样的。
准备好开始了吗？希望此文能够帮助你和你的团队了解移动应用开发幕后的方方面面。除非你们要做一个像计算器那么简单的单机应用，否则你们很难用极低的成本搞定。综上所述，如果你觉得外包成本太高，那你只好招人自己开发。当然，如果你决定了要外包移动应用开发，那么我还要提醒一点：公司政治。 如果你是在一家大公司或者有着严格制度的机构里面干活，那么帮助合同开发者搞定那些个规章制度上的繁文缛节，对你来说是非常重要的一项工作，必要的时候甚 至可以做一些政策上的变通。 我同几个大型企业客户接触过，当我要求看他们的服务器端数据接口的时候，他们流露出很不安的表情。我想这或许是因为他们受制于公司规定而不能透露信息，这 无可厚非；或者他们还没有想好这种情况下该如何操作；或者他们的品牌制度蛋疼到需要在移动应用的每个屏幕上都摆着公司logo！最终我没有和这样的企业客 户合作，因为我无法想象如果有一天我需要增加一些服务器端API接口的话，和他们的规章和流程折腾，那将会是多么悲剧的事情。PS：开发移动应用很耗费时间，你最好有耐心。
usidc 17:28只要有了优秀的编程工具、高级的编程语言、丰富的构件库和辅助程序建立系统，就能解决所有问题？并及时地在预算范围内交付良好的软件系统吗？ 一个软件开发团队如果想要在项目中获得最大限度的成功，离不开人的因素。
软件开发团队中的意见
一个软件开发团队如果想要在项目中获得最大限度的成功，取决于团队中的成员能否形成技术性一致意见。但为什么这点如此重要呢？是不是团队成员只 要在诸如目录表格的布局上达成一致，或者建立一个很好的错误汇报机制就行了呢？技术性一致意见指的并不是与同事打成一片就可以了（当然，这也不是说在同事 之间建立良好的关系有什么错误）。技术性一致意见是指充分吸取团队中每个成员的技巧和经验，其目的是为了开发出更好的软件。
职业软件人员也许能够迅速理解一款好的软件，至少当他们看见一个好的软件时会宣称自己能够理解它，但是，在软件开发者中，很少有人能理解技术性 一致意见。可能许多软件开发者会说，我们以前使用过一致意见的方法来解决问题，但是效果非常差，他们还会举出许多例子，比如，一些很棒的构想就是在不断的 讨论中葬送了，最后为了所谓的整体性只得做出妥协；本来 6 个月可以完成的项目最后拖了 1 年：团队的能力也没有完全发挥出来。但如果仔细地听听他们的意见，你就会意识到他们所说的解决问题的方式根本就不是技术性一致意见，而是折衷。那么，二者 之间有什么差异呢？
折衷是没有前途的
折衷意味着所做出的选择是一种似是而非的东西。既不是甲，也不是乙，而是一个介于二者之间的东西。我们可以通过一个典型的例子来说明。如你的团 队正在开发一个图形用户界面的项目，一部分人强烈建议直接将控制按钮放在屏幕底部，而另一部分人建议在屏幕的左侧放置一个控制窗体。在这两种意见中，一种 是水平放置，一种是垂直放置，形成了两个极端。那么，一个最具有代表性的折衷方案就是，将控制按钮沿着对角线放置在屏幕的中央。
就像上面的例子所描述的，由折衷所产生的解决方案常常要比任何一个原有的方案都要差劲。但是技术性一致意见就恰恰相反，它所产生的解决方案要比 任何一个原有的方案都要好。如果不使用技术性一致意见，往往会由于顾忌到每种备选方案的优点，而采用优点均衡的方式，但实际上每种备选方案的优点也就丧失 了。真正的一致意见不是基于那种让每个个体都做出让步的折衷，而是基于综合的，新的综合体要比原有的任何一个个体都要好。最后的结局就是，开发出了更好的 软件。
一个综合体是一种具有新颖性的新个体，是集成了原有的每个建议和方案的本质特征的个体。在上面所说的界面设计例子中，可以明显地看出，一个具有 创造性的综合方案是给控制按钮窗体加上选项，由用户来决定是采用水平放置还是采用垂直放置。一致意见的方法不仅仅是将各种选择方案的优点集中起来，而且综 合方案还体现了新的特性和功能。通过集成水平放置和垂直放置这两种方案，我们可以实现终端用户定制。这样，最后的软件产品就集成了各种方案的好的方面，而 不是坏的方面。
形成真正的一致意见并不是一件容易的事情，那些政客和工人谈判代表们对此深有感触。达成一个技术性的一致意见与达成一个政策性的一致意见是有所不同的，但是有些本质特征是基本相似的：二者都需要制定一些约束条件以达成共识，参与者在讨论过程中都需要保持一种信念。
真正的信徒
团队成员必须坚信，从每个人的意见中提取出最好的方面并将其综合起来，就此形成一个技术性的综合体是完全可能的。只有坚信这点，成员们才有可能 坚定不移地寻找最好的解决方案，而不是轻易地折衷或者固执己见。每个成员发表自己对问题的看法，讲述方案的优缺点，通过坚持不懈地努力，成员们可以提高形 成具有创造性方案的可能性，而这种创造性的方案会比原有的任何方案都更好。
当每个成员都相信开发一个好的软件要比在软件中使用自己所喜爱的方案更重要时，一致意见式的设计会发挥更大的作用。如果我们注重最终软件产品的质量，在团队讨论过程中会更容易发现每种意见的优点。
如果团队中的成员不是独自炫耀个人能力，而是认同联合协作的工作方式，那么对于软件开发会更有帮助。有些公司愿意奖励杰出的个人，而不是奖励团 队；或者晋升那些惯于单打独斗，特别是那些不会也不可能与他人共事，常常一个人解决问题的程序员，而不是表彰整个团队。这样的公司会做出如下论断：最好的 软件是他们的天才程序员开发出来的。这些公司意识不到，除了这种方法以外，其实还有其他的方法可以达到更好的效果。
在建立技术性一致意见时，一个必须遵循的原则就是：绝不能以货易货!对于政客们来说，采用以货易货的贸易方式是一种获得成功的经典策略，但对于 技术性一致意见而言，这是有害无益的。举例来说，在上面的界面设计例子中我们可以采用以货易货的方式，如果让我同意你的愚蠢方案，将控制按钮窗体放在屏幕 底部，那么你就要同意我聪明的设计思想，加上没有标签的图标。最终的结果就是，界面不是最好，而只是一个具有两个普通特性的界面。这种以货易货的策略其实 是另一种形式的折衷，而折衷之所以糟糕，是因为在不同方面所做的决策会相互影响。好的技术性一致意见必须将问题分别对待，对于不同的问题分别采用最好的解 决方案，而绝不能因为某个方面固执己见，致使另一个方面让步。
一般来说，大家都认为技术决策所依据的都是技术性因素，诸如事实、可测量的数值、应用中需要考虑的事项等。但实际情况是，诸如感觉、意见、直 觉、偏见等，都会对决策的制定或者问题的解决产生影响，这些都是人在做事情时所不可避免的因素。尽管有些人试图否认、控制、压制这些非理性的因素，但这些 都是绝不可能完全避免的。
对于那些希望采用技术性一致意见方式来解决问题的团队，有一个基本的技巧是必须掌握的：将事实和意见分开。对于一个协同工作的团队来说，如果期 望创造性地解决问题并获得最好的结论，他们必须知道他们已经掌握了哪些信息，并能够随时获得最好的信息。发表意见并不是错误，团队成员应该能够自由地表达 他们的意见。意见是有用的，特别是那些经过深思熟虑的意见，但是成员在表达意见时必须能够保证他们的意见不要和事实、数据、分析混在一起。就算是事实，也 是具有局限性的。例如，在美学或者行销领域中，事实所起的作用可能就会不太显著。遗憾的是，有些团队成员一旦形成自己的意见，他们往往就对事情的真实程度 视而不见了。
有时候，把某些东西称为事实并不意味着它就是真正的事实，因此，团队必须学会如何单刀直入地解决问题，而且大家还需达成一致&&不玩文字游戏。 我的第一任妻子在我们共同生活的早期就学会了这一点，只要我说出以&事实很清楚地表明&&&开头的一段话，她就会对我所讲的东西表示怀疑，因为这意味着随 后所讲的话极有可能只是我个人的看法，而不是基于任何数据或证据所得到的结论。除了这个尴尬的话题外，我有时还会掉入另一个语言陷阱中，那就是众所周知的 &95％的科学家都认为&&&。有些人可能意识到了，在软件业中，有一句同样著名的话：&你知道的，绝大多数的职业软件工程师，至少 95％以上，都会采用这个方法。&当然，如果你还想继续使用这个小技巧，你必须改变百分数，例如：&将近 78％的 WordPerfect 用户都知道最好的方法是&&&，&如果我们做个调查，2／3以上的C程序员都会同意&&&。有时候，看上去好像真的有那么多的科学家、软件工程师、终端用 户站在你的背后支持你的意见。
但是，这仅仅是我的看法。
usidc 12:28一寸光阴一寸金，寸金难买寸光阴。时间有多么珍贵，不用我多说大家都非常清楚。光知道时间的珍贵是不够的，重要的是我们如何合理的安排自己的时间。让每一分每一秒都过得有价值！
我们已经进入了一个信息化的时代，大多数的工作都可以找到合适的工具帮我们完成。同样，管理时间制定计划也有非常好的工具。像什么谷歌日历、Hotmail日历、Outlook、飞信等等，我就不一一列举了。类似的工具我也用过一些，感觉谷歌日历跟Hotmail日历是非常不错的。之前我一直用的是谷歌日历，但最近不知怎么谷歌经常无法同步，所以就改用Hotmail日历了。其实这两者除了外观有点差别之外，功能与基本设定几乎完全一样，如下图，一天24小时可以在任何时间设定你要做的事情。
对一些有规律、经常重复的事情可以设置循环&&按天、周、月、年等循环，非常的人性化。
另外还有多种提醒方式，包括电子邮件、电脑端或手机端弹出窗口提示、让你无论何时何地都能够及时收到提醒，不错过任何一件事情。
如果不方便用电脑的话，还可以同步到手机上。如今智能手机正以龙卷风一般的势头席卷全球，目前Android手机平均日激活量已经超过50万台，再加上IOS、新兴的WindowsPhone、三星的Bada系统、惠普的WebOS等等。几乎快达到人手一部的地步了。而每一部智能手机都具有很强大的日程管理功能。我们可以将谷歌日历或者Hotmail日历同步到我们的手机上。本人目前用的是微软的WindowsPhone，所以下面就以WindowsPhone为例
锁屏和开始界面都可以看到接下来要做或者正在做的事情，非常方便。
可以单独浏览每天的安排，也可以纵观整个月，把握整体的安排。
点击某个具体的事件可以对其进行编辑，如果是循环事件还可以选择编辑本次，还是编辑所有。如果在手机端进行更改日历同样会同步到服务器上，利用强大的云实现无缝链接。
有了以上这些强大的工具以后，安排时间制定计划已经不成问题。但是新的问题又来了，那就是我们制定了这些计划如何才能够很好的执行呢？想要解决这个问题也不难，咱们往下看：
说完了时间管理，下面我们说说个人管理。前面的时间管理只是教我们怎么安排时间制定计划，而接下来要说的个人管理，是教我们如何按时保量的去完成我们所制定的计划。关于个人管理的方法有很多，例如普瑞玛法则、番茄工作法等。这些方法所主张的观点都很相似，中心思想大概都是将一整天分为若干个时间片，在这些比较短的时间片里只做规定的事情，其他事情不要做不去想。没结束一个时间片进行短暂的休息，连续几个时间片以后进行较长的休息与放松。从而达到在短时间内精神高度集中提高效率的目的。下面我们就以普瑞玛法则为例简单的说一下：
普瑞玛法则普瑞玛法则除了主张将时间分段以外，其更核心的思想如下：普瑞马法则：就是如果把一件更难完成的事情放在比较容易完成的事情前面做。那更难完成的事情就可以成为比较容易完成的事情的强化刺激。换句话说，把不愿意干的任务或者工作放在喜欢完成的任务之前。如果经常完成困难的、有挑战性的任务，那么工作能力就会增长；相反的话，工作能力就要下降。也就是说，把好玩的事情留在后面做。
没错，把自己最喜欢，觉得最有意思的事情放到最后做，这样做起事情来回更加有盼头，更有动力。就像吃东西一样，如果先让你把你喜欢的东西吃了，那么你不喜欢吃的东西你还会去吃吗；相反，如果规定必须先把你不喜欢的东西吃完，才可以吃你喜欢的东西结果会完全不同。
这种方式在一开始的时候会有些困难，但只要稍微费些力气坚持一下就会过去。注意：中途不可跳过某个不喜欢的事情，而去做自己喜欢的事情。普瑞玛法则对于改变惰性的生活方式有很好的效果，而且据说对于经常有抑郁心情的人也颇有效果。普瑞玛法则还有很多具体的实施方式，这里就不一一列举了，如有兴趣请看考百度百科中的普瑞玛法则解释。
最后再为大家推荐一本很有名的关于时间管理的书&&尽量去做:无压工作的艺术
usidc 12:30身边有几个做PHP开发的朋友，也接触到不少的PHP工程师，他们常疑虑自己将来在技术上的成长与发展，我常给他们一些建议，希望他们能破突自己，有更好的发展。先明确我所指的PHP工程题，是指毕业工作后，主要以PHP进行WEB系统的开发，没有使用其的语言工作过。工作经验大概在3~4年，普通的WEB系统（百万级访问，千成级数据以内或业务逻辑不是特别复杂）开发起基本得心应手，没有什么问题。但他们会这样的特点：
* 除了PHP不使用其它的语言,可能会点shell 脚本。对PHP的掌握不精（很多PHP手册都没有看完,库除外）知识面比较窄（面对需求，除开使用PHP和mysql ，不知道其它的解决办法）PHP代码以过程为主，认为面向对象的实现太绕，看不懂
这些PHPer 在遇到需要高性能，处理高并发，大量数据的项目或业务逻辑比较复杂（系统需要解决多领域业务的问题）时，缺少思路。不能分析问题的本质，技术判断力比较差，对于问题较快能找出临时的解决办法，但常常在不断临时性的解决办法中，系统和自己一步步走向崩溃。那怎么提高自己呢？怎么可以挑战难度更高的系统？更高的挑战在那里？结合我自己的经验，我列出一些具体挑战，让大家先有个感性的认识。高性能系统的挑战在那里？
* 如何选择WEB服务器？要不要使用fast-cgi 模式要不要使用反向代理服务？选择全内存缓存还是硬盘缓存？是否需要负载均衡？是基于应用层，还是网络层？ 如何保证高可靠性？你的PHP代码性能如何，使用优化工具后怎么样？ 性能瓶颈在那里？ 是否需要写成C的扩展？用户访问有什么特点,是读多还是写多？是否需要读写分离？数据如何存储？写入速度和读出速度如何？ 数据增涨访问速读如何变化？如何使用缓存？ 怎么样考虑失效？数据的一致性怎么保证？
高复杂性系统的挑战在那里？
* 能否识别业务所对应的领域？是一个还是多个？能否合理对业务进行抽象，在业务规则变化能以很小的代价实现？数据的一致性、安全性可否保证？是否撑握了面向对象的分析和设计的方法
当我所列出的问题，你都能肯定的回答，我想在技术上你基本已经可能成为架构师了。如何你还不能回答，你需要在以下几个方向加强。如何你还不能回答，你需要在以下几个方向加强：
* 分析你所使用的技术其原理和背后运行的机制，这样可以提高你的技术判断力，提高你技术方案选择的正确性;学习大学期间重要的知识, 操作系统原理，数据结构和算法。知道你以前学习都是为了考试，但现在你需要为自己学习，让自己知其所以然。重新开始学习C语言，虽然你在大学已经学过。这不仅是因为你可能需要写PHP扩展，而且还因为，在做C的应用中，有一个时刻关心性能、内存控制、变量生命周期、数据结构和算法的环境。学习面向对象的分析与设计，它是解决复杂问题的有效的方法。学习抽象，它是解决复杂问题的唯一之道。
"这么多的东西怎么学，这得学多久呀" ？如果你努力的话，有较好的规划，估计需要1~2年的时间。如何有效的学习是一个大问题。 自己有些实践但很零散，不好总结。昨天晚上睡觉前，突然想到了RUP的核心，"以架构为中心，用例驱动，迭代开发"，借用这个思想，关于有效的学习的方法，可以这样来表述：以原理、模型或机制为中心，任务驱动，迭代学习。有点抽象， 举个例子来说明如何学习。目的： 学习如何提高处理性能。可迭代驱动的任务： 通过IP找到所在地域。这是WEB应用常见的任务，IP数据库是10左右万行的记录。第一次迭代： 不考虑性能的情况下实现功能（通过PHP来实现）。因为无法直接通过KEY(IP)进行查找地域，所以直接放到数据或通过关联数组这种简单的方法都是不行的。思路还是先把数据进行排序，然后再进行查找。
1. 如何通过IP查找？ 已序的数据，二分查找是最快的。如何排序？用库函数sort当然 是可以，但是即然是学习，那还是自己实现快速排序吧。
学习目标： 排序算法，查找算法。PHPer 一般数据结构和算法基础比较差，平时也没有这方面的任务，自己也不学习，因此这方面的知识很缺乏。但是，编程解决的问题，最终都会归结到数据结构和对这种数据结构操作的算法。如果数据结构算法常在心中，那遇到问题就能清晰认识到它内在的结构，解决方法就会自然产生。第二次迭代：优化数据的加载与排序。如果做到第一步，那基本上还是不可用，因为数据每次都需要的加载和排序，这样太耗时间。 解决的思路是，数据一次加载排序后，放到每个PHP进程能访问到的地方。放到memcache 这是大家容易想到问题。其实放到共享内存(EA等加速器都支持)中是更快的方式，因为memcache还多了网络操作。 数据是整体放入到共享内存，还是分块放入，如何测试性能? 如何分析瓶颈所在(xdebug)? 在这些问题的驱动下你会学习到。学习目标： 检测、定位、优化PHP性能的方法; PHP实现结构对性能的影响。第三次迭代： 编写PHP的扩展。性能还是上不去，不得不进入C/C++的世界了，不过从此你将不只是PHPer 而服务端的全能型工程师，当然这对没有做过C/C++的同学挑战是巨大的。 我这里无法再简单来说如何学习C/C++ ，可以参看 《PHP程序员学习C++》学习目标：C/C++的学习，PHP扩展的编写怎么确定需要学习的机制和原理呢？ 怎么找到驱动学习任务呢？我对需要学习的东西，都没有什么概念，怎么回答以上的两个问题？
1. 从这个技术的定位来找出需要学习的重点，即它怎么做到(机制）的和它为什么能这样做到 （模型或原理）列出这个技术最常见的应用，做为学习的任务，从简到难进行实践。
假如我需要学习Javascript ,我对于HTML，CSS有点感性认识。首要我了解到，JS 是WEB领域的动态语言，主要解决网页的动态交互的。那我要学习的要点如下：
* JS如何与HTML 进行交互 （机制）JS的动态特性在那里，与其它动态语言有何区别？（语言模型）
如果完全自学，找到需要学习的要点（机制、模型、原理） 设定学习任务的确不是那么容易把握。如果找到一个有经验的人来指导你或加一个学习型的团队，那学习的速度的确会大大提高。
usidc 12:月，在经历了将近2个月的热烈讨论和百般纠结之后，老陈的创业团队终于解散了。其中，我们每个人心里的那种无法言明的心情，有多少人能够理解？表面上看，我们的项目是终结于资金短缺，而深度剖析的话，应该属于经营不善&&我们不应该总是把缺钱当作借口。不过，今天我们要讨论的不是之前已经解散的创业项目，而是在这之后，我遇到的一些事情。
团队一：不缺资金但项目不明确在解散前夕，曾经有一个做LBS的团队找我，期望我能够加盟他们。当我问道为什么的时候，他的回答是：&我看好你的技术，我们对你的能力都很认可！而且，我们不缺钱！&。但实际上，我并不想知道为何选择我，而是想知道这个项目对我的吸引力在哪里。
作为已经创业多年的人，我在团队里不只是负责技术，几乎事事参与，所以我更加关注的是项目前景。当我问到为什么选择做LBS的时候，他说最近流行这个。MGD，这是一个什么逻辑？流行什么我们就一定要做什么？话说很多成功都是在流行之前开始做的，当已经开始流行的时候，你还有多少机会？
回过头来看看2011年，迅猛发展的是电商，风投、天使都把钱往里面砸。才刚刚进入2012，团购倒下一大片，各种中小电商平台也相继倒闭。按照这个逻辑，我也可以预测，2013年、2014年之后将会有大批的移动项目、旅游项目相继倒闭。这是规律，虽然是一个不太准的规律！
好吧，关于如何选择LBS我们不再讨论了，那么就讨论一下如何做吧？对方表示目前还没有定型&&听到这个，还需要继续谈下去吗？
当一个人、一个团队没有认清市场的时候，他们也就无法辨清方向，这样的团队每天除了依靠一腔热血虚度年华之外，还有什么作为呢？他们还有很长的路要走&&
团队二：声称要收购我们，结果自己先倒闭了这个团队做的是网上超市，据说背后合作了二十几家银行，2011年营销额2000万，今年有望突破一亿。听起来很不错，而且在我们即将弹尽粮绝的时候，提出收购我们，那我们真的是求之不得！
在进行了第一次交流之后，双方感觉良好，对方要求到我们的办公室进行第二次谈判。但就是在这次，无论是营销上还是技术上，他们提出了很多看似弱智的问题。不过，我们的理解是，可能对方真的是老大级人物，在某些方面懂得不深是有可能的。没有什么奇怪的。
然而，第三次谈判，是去对方公司。技术由我来沟通，而运营等问题由我的合作伙伴沟通。回来之后我们讨论了一下，发现了很多问题：
他们的平台和其他看起来很强大的企业一样，做的很烂、很乱、很失败！他们的SEO、SEM观念都很陈旧，而且太过于恪守成规；他们不愿意再多花钱，能承诺给我的常规待遇是3000元/月，而我的伙伴也只能拿到4000元/月；除了我们的待遇很低之外，他们也不愿意、不同意再招聘新人；&&以上几点是我们没有同意被收购的主要原因。除此之外，他们对自己的项目相当的不自信，因为他们也是创业公司，一直在寻求融资。据他们介绍，在融资过程中经常被问及一个问题，即&如果竞争对手有足够的钱，那么你的项目是否还能存活？&。实际上，在我看来，这个问题根本不可能被经常问及，因为这样的问题本身就是个问题。有足够的钱，我们就能够组建足够好的团队，然后去做任何想做的事情。但这只是理论，要把这些极品和偶然全部凑到一起，至少在这个地球上得好几千年或者好几百万年才能来那么一回！
惧怕这个问题，也就是惧怕自己，这说明他们对自己的项目还没有足够的把握，在经营过程中可能遇到了发展瓶颈，对自己的项目认识并没有那么清楚。
如果说看不清市场我们就失去了方向的话，那么看不清自己的项目我们就迷失了自己！当自己找不到自己、失去信心的时候，就可以对一些看似很有道理的问题执着起来！
总结原本还想再分享对其他三个团队的看法，但有些困了，改天有机会从其他角度再说吧！
我们做人做事，都要清清楚楚、明明白白，不要盲目自信，也不要轻信他人。做技术也是一样的，我经常跟猴子们说，我回答给你的只是理论和我自己的经验，至于是否符合你自己的项目，要自己多动手测试、评估，不要盲目的听信于我。
好项目、好团队、充足的资金凑到一起的机会很少，即使凑到一起了也未必能够找到合适的人才。尤其是在稍微大一点的团队里面，这种现象更为明显。劝诫企业认清自己的方向、不要盲从、不要滥用人才和资金，不要走冤枉路！
usidc 13:04当知道了我要为微软工作后，一个朋友问我&为什么你要给那个人干活？为什么不去IT创业呢？&我的回复差不多是&我喜欢每两周领一次工资的生活&，但其实还有更多的原因。
不错，这正常的朝九晚五的工作的一个最大的好处是稳定。我有健康保险，休假日，薪水收入也不错。这并不是我不想IT创业的最大原因。最大的原因是，我还没有找到一个我们足够感兴趣，愿意全部精力都投入到其中的目标。
我知道，如果我草率的与人合作，完成他人的某个理想，我不会有足够的热情来完成那些创始人们需要处理的所有的零零总总的烦事。如果我自己成立一个公 司去IT创业，我将需要自己处理诸如工资结算，账务，法律等问题。我现在不想做这些事情。我想的是集中精力做出一些很酷的玩意儿。
那么，当你为老板干活时，对于遇到的那些让人厌烦的事情怎么办呢？这些事情已不再重要。如果我忘记了提交任务进度，经理会发邮件通知我。如果我忘了偿还公司内的账务，后果只会稍微严重一点点。
我不需要成立一个IT创业公司。我可以以一个程序员的身份加入一个公司，而且能对这个公司产生重要的影响。这毫无置疑是有一定的吸引力的，有朝一日也许我会成为这样的人。现在，我只想为&某个老板&干活，很高兴能看到我将要去开发的软件能被百万人使用。
usidc 13:06月光博客6月12日发表了《写给新手程序员的一封信》，翻译自《An open letter to those who want to start programming》，我的朋友（他在本站的id是Mailper）告诉我，他希望在酷壳上看到一篇更具操作性的文章。因为他也是喜欢编程和技术的家伙，于是，我让他把他的一些学习Python和Web编程的一些点滴总结一下。于是他给我发来了一些他的心得和经历，我在把他的心得做了不多的增改，并根据我的经历增加了&进阶&一节。这是一篇由新手和我这个老家伙根据我们的经历完成的文章。
我的这个朋友把这篇文章取名叫Build Your Programming Technical Skills，我实在不知道用中文怎么翻译，但我在写的过程中，我觉得这很像一个打网游做任务升级的一个过程，所以取名叫&技术练级攻略&，题目有点大，呵呵，这个标题纯粹是为了好玩。这里仅仅是在分享Mailper和我个人的学习经历。（注：省去了我作为一个初学者曾经学习过的一些技术(今天明显过时了)，如：Delphi/Power builder，也省去了我学