web项目经理手册-开发时间估算

项目经理制定项目时间表的时候，需要估算每个任务所需的时间，其中开发任务中模块的分配和时间估算是其中最主要的部分。本篇专门就这部分作一个阐述。一、在分配模块和估算开发时间时，我们需要把握的原则和目标：1、保证项目整体的进度。2、有助于确保开发编码的质量。3、有助于提高开发编码的速度。二、每个公司都拥有自己的技术框架，开发人员主要的工作通常投入在具体的商业逻辑上。通常每个模块所需的开发时间取决于以下三

web项目经理手册-版本控制流程

 web项目经理手册-版本控制流程        大家在项目过程中是否会经常发生以下问题：1、测试人员在测试阶段更新测试环境时，发现编译不通过，或者应用出现异常，无法进行测试。后来发现的根源是测试和开发共用一个分支。2、有一天某个人群发了一条邮件通知，“我们的项目代码已经发到主干，这段时间大家不要修改主干信

圈子圈套3(终局篇).txt

圈子圈套3
作者：王强

内容简介：
　　全景展示了商场和职场的生死厮杀、巅峰对决。主人公的命运、项目结局、所有的恩爱情仇都在本书中揭开谜底。
　　再次陷入低谷的洪钧在内忧外患中不甘消沉，在职场上和自己的上司明争暗斗，在商场上则和夙敌俞威为了争夺“中国第一资源集团”这一超级大单展开了博弈……鹿死谁手，看洪钧、俞威各施手段，步步是陷阱，招招含奇谋，处处有玄机……问英雄谁是英雄？商场无情，职场冷酷，成败皆英雄。《圈子圈套三部曲》是一场盛宴，《圈子圈套3.终局篇》无疑是盛宴中的压轴极品，浓缩作者十数载职场、商场体悟，尽现成功要决。

圈子圈套(2)

内容简介：
　　IT企业商战内幕纪实：圈子圈套(2)
　　洪钧出任维西尔中国区总经理，他和俞威之间的较量又或明或暗地展开来，面对内部的纷争和商场上的尔虞我诈，他该如何出招;一波未平，一波又起，一股来自总部的人事变动的暗流汹汹向他袭来，他又将如何应对……

圈子圈套2.txt

圈子圈套1.txt

圈子圈套

内容简介：
　　IT企业商战内幕纪实：圈子圈套
　　本书是作者的《中国现代商道三部曲》的第一部。虽是一部文艺小说，但小说中所涉及到的IT行业的残酷商战和外企圈子内幕均以真实事件为原型，基于作者深厚的生活积淀，生动描写了在华外企高层的各地各色人物。IT业的广大从业人员及外企白领们，都会觉得小说真实而深刻、生动而亲切。
　

圈子圈套1.txt

如何判断你用的是左脑还是右脑！

如果你看见这个舞女是顺时针转，说明你用的是右脑；   
如果是逆时针转，说明你用的左脑。   

耶鲁大学耗时5年的研究成果，据说。   
...

学历历程

 如果你是一个菜鸟或者自认为初学者那么本文非常适合你；不能说这30本书就是最佳组合，但是可以说这个组合不差；本人曾博览群书，很多书重复，很多书讲的不适用，这些书都是目前书店可以买到的；达到中级程序员以后怎么成为高级程序员就靠你自己了，而此时你已经有辨明是非的能力，这也就是本文的目的！30本好书点评：分4大方向（html--Web的基础；javascript--让网页动起来；C#--程序；

小白兔的笑话集合 呵呵

小白兔蹦蹦跳跳到面包房，问：“老板，你们有没有一百个小面包啊？” 老板：“啊，真抱歉，没有那么多” “这样啊。。。”小白兔垂头丧气地走了。 第二天，小白兔蹦蹦跳跳到面包房,“老板，有没有一百个小面包啊？” 老板：“对不起，还是没有啊” “这样啊。。。”小白

电话面试经历

出来混，迟早要还。也有了人生第一次电话面试。没有签NDA，所以在这里分享一下。但愿对各位大佬有帮助。职位是架构。要求是对Java和J2EE熟，能编程，熟悉OO设计。有架构经验，等等等等，都是大路货，没什么出奇的。再说出奇的我也不行啊。

总的感受：

用自己的话总结对方的话挺有用。表明了你在积极思考，理解了对方的意思，并且避免了双方的误解。关键是要加上自己的理解、延伸，和追加问题。面试官介绍他们的技术时我用了这坨方法，明显感到对方话多起来，也更为随意。大概正确的理解让对方打开了话匣子。
准备一个电话用耳机。不然一小时的面试下来，手挺累的。而且做编程题时需要在本子上演算，拿着话筒也不方便。用免提效果不如耳机好。尤其现在家 家都用IP电话，用免提有非常明显的杂音。
准备一杯水。除非老大您久经沙场，面试如老友闲谈。多少会紧张，导致口干。一杯水能让人舒服，很好地缓解情绪。
问题挺简单，但我居然卡壳。可见事前充分准备多重要。下面详说。

大致的面试过程

寒暄过后，面试官介绍他们的技术。介绍完后，问我有没有问题。我陈述自己对他们技术的理解，列举了几坨可能的应用，问他自己的理解对不对。他同意。于是继续他们的技术同他们的竞争对手有什么区别。然后又问了点搜索中常见的问题，比如怎么处理扩展性，怎么抓取数据，怎么整合数据，如何数据挖据什么的。目的不在了解他们的具体技术。反正也问不出来。主要是表明自己对他们的相关技术有兴趣，有一定了解。另外也是找机会称赞他们技术新颖的时候（前提是真觉得他们的东西不错。诚恳很重要哈）。感觉大家言谈甚欢。直到对方说如果你有问题，等会儿还可以继续问我。于是知趣打住，等待对方提问。

问题从我的经历开始。你现在做什么。负责什么。用什么技术。多少跟Java有关，多少跟JSP/Servlet有关，多少跟前台有关。多少跟后台有关等等。你都很久没有用Java了（俺现在做很多AJAX应用），技术不会落后么？于是俺强调其实没有全职做Java也就一年，但技术并没有撂下。比如俩月前还写了一坨stream-processing proxy server。至于JSP，一坨简单模板技术而已，用不用关系不大嘛。再说相关书没少看。然后列举几坨最近看的常见书籍，对方也就没再追问。本来想说语言不重要，关键是背后的技术。但想想人不是来听我上课的，遂作罢。

然后面试官说，So you still know Java, huh? Do you know Java Collections? 我耳背，听成了Java concurrencies? 心头一凉。心想，哪壶不开提哪壶嗫？做JEE的哥们儿里，有多少人成天和concurrency打叫道啊？都是托Container的福。只有书本知识和玩具程序的体验哈。不过嘴上不能示弱。答：然，concurrency的知道。结果对方说，不不不，是Collections。说说Collections里的常见数据结构。随口说了几个。对方继续问：如果有一百万key-value pairs供查询用，怎么办？答：可以用HashMap，如果你没有synchronization的要求。对方继续追问，可能有有什么潜在问题？我聊了点常见的问题，诸如数据多了需要不断重新组织bucket，会时不时影响性能。对方接着问：那你还用HashMap？心想：Call！设套让俺钻呐？于是答：因为够简单。再说如果担心性能，我们可以测试嘛。找出瓶颈再优化不迟。面试官没有纠缠，换了个话题追问：如果这些key-value是用于cache的，用hashmap有什么问题？答曰：可能导致大量垃圾。然后讨论了一下Weak Reference，Soft Reference，和Phantom Reference的区别。对方问，如果用String作为key，还可以怎么处理？答：用Trie。面试官接着问：那如果要做子串查询呢？顺口答：Suffix tree。奇怪的是对方没有深入问下去，而是换了个话题问：如果我只关心key，你怎么处理value？这个时候我开始犯傻，答：那你用boolean或者整数，还可以知道每坨key出现多少次。结果我大概听力有问题，人不是这个意思。所以面试官提示：我不关心value。于是俺醒悟：答; 那就用Set。奇怪的是他也没有追问关于Set的选取和实现，就跳到下一个问题了。事后想来，这是教训：应该先问清楚对方的需求再答题。平时我肯定是这么做的。但不知道为什么面试时这些常识通通忘掉了，先入为主。当时好像也不紧张阿。

之后进入编程时间：写一坨函数交换两个String。我一听想，难道是传说中的陷阱？于是特意确定，你是想我写一坨函数：void swap(String s1, String s2)，运行后s1的值同s2的值交换？对方说是。于是我说不可能。解释了pass by value和pass by reference。然后对方问怎么可能。我说你用StringBuffer或者一坨Array/某坨Collection都行。他好像满意了。于是跳到下一个问题。

问：说说一坨request进来后，JSP的life cycle。我背书。然后他追问：怎么保证线程安全。答不要用instance variable。你要用partial/full synchronization也行，但这多半表示你的设计出问题了。然后他又反过来问：那你在JSP里怎么保证不用instance variable。我说不用<%!就行了。其实我们有严格的编程规范。像<%!这种东东只在书上见过。俺一辈子都没用过。两人笑。后来面试官又问了几个常见的Java/JEE问题，不过我忘了。

真正的算法题没几道。都比较简单。第一道是两坨排好序的数组。求它们的overlap。比如[a, c, e, f]和[d, a, g, h, k, f, s]的overlap是af。其实就是求他们的LCS。那么简单的题，我居然一下卡壳。当时不知道为什么脑子完全被LCS的常用算法占据。问题是，这样就没用上排序这项条件。我也想到了用类似Merge Sort的方法做，但不知为啥又把它否定了。这个时候对方提示了一下，说brute force怎么做，我赶快答。然后就想出了答案。接着对方问复杂度，我说O(m+n)，对方就跳到下一道题了。这次失败的教训是

镇定，镇定，再镇定。我居然忘了多演算几个例子，问他对复杂度的要求，以及从brute force开始推演。
练习，练习，再练习。在时间压力下解决问题同悠闲地做题自娱自乐有本质区别。至少压力会干扰我的直觉，让一些平时看来简单的东西变得捉摸不透。平时就注意夯实基础和拓宽思路才不会在关键时掉链子。
临场经验也挺重要。其实Polya的解题方法我也常用。平时开会和给学生讲题也是站在白板边就开始大声思考。但到了面试，还是觉得思路非常拘束。

第二道算法题是一坨任意整数数组。写一个函数，把数组里的奇数放前面。偶数放后面。比如[1, 2, 3, 4, 5]，处理后得到[1, 3, 5, 2, 4]。这次我学乖了，先演算了几个例子，然后问了他顺序重要不。他说不重要。我说，俺决定从最简单的开始，试一试顺序做，放一坨下标，指向数组起始元素。说到这里，算法出来了。然后分析复杂度，时间O(n)，空间O(1)。好像他也就满意了。虽然这次稍微顺利了点，但感觉还是非常束缚。完全没有平时编程时思路清澈自由的感觉。貌似解释思路只是为了拖延时间，脑子里好像被塞了一块抹布。非常郁闷。

最后一题刚好关于Suffix Tree，就不多说了。

然后是我的提问时间。我问了公司的文化。然后问除了Job Description上的条条，他们到底找什么样的人。然后又问了他们的开发流程。顺便聊了下流程，表明自己对软工的套路也熟悉。

最后大家道再见。面试官说会同HR的人讨论。再看有没有必要安排下一轮面试。比较诡异的地方是，我申请的是架构的职位，但电话面试没有问关于设计和架构的问题，也没有问和人打交道的问题。还有他也没有问关于scalability的问题和多线程编程的问题。这也比较奇怪。据说他们是天天和这些东西打交道的。我猜大概是以为电话面试是用来过滤候选人的，所以不会复杂和面面俱到。现场面试的题目会更深广一些。

到微软工作还有意思么?

首先是牛皮轰轰的Joel Spolsky 写了一篇精彩的帖子, 讨论Windows Vista关机菜单的累赘设计。这篇帖子引出了一微软程序员（Moishe Lettvin）的文章，The Window Shutdown Crapfest。简单归纳一下：

Moishe用了整整一年才完成Windows关机菜单。
实现该菜单用了200来行代码
这个看似简单的功能牵扯到Windows Shell组，Windows Kernel组，和Mobile User Experience组。加上各类经理，一共42（！）个人参与讨论怎么实现关机菜单。
42个人的讨论乱成什么样不难想象。连续N周，每次90分钟的激烈讨论，才能让所有人闭嘴。
Windows过于庞大，不得不采用多个代码库分层管理。后果是从代码check in到代码集成要花上几周甚至几个月（Thoughworks享受continous integration的老大们不要笑岔气了哈）。
让每个人都满意的产品多半毫无新意，扼杀每个人的热情。Vista关机菜单也不例外。用Moishe的话说，就是42个人都满意的设计只能是乏味的“最小公分母”。横空出世的软件大作往往由两三个优秀程序员倾注心血锻造而成。这样的产品浸染了程序员的精神，张扬着程序员的个性。惟其激进，才有穿云裂石的力量。它不可避免地招来许多人强烈的恨意，但也受到更多人狂热的喜爱。Google的产品小组一般都是2到3人，不是没有道理。Seth Goding和Kathy Sierra的博客有很多相关的讨论，强烈推荐。

这样的工作有意思么？

Update：Joel又发了一个短帖子，里面说九十年代初微软把IBM臃肿的OS/2开发团队作为案例研究，找出微软以后不应该做的事。想不到从1991年到2006年15年间，微软也编程了一个臃肿的怪兽，用了整整5年才能发布自己旗舰产品的一套松散补丁（Joel应该是说微软的Windows Vista)。