一些人总是发出一些错误的声音，形成了劣胜优汰可怕的现象。他们在误导着中国，把我们的后继军训练成软件蓝领――――胸无大志，目光短浅，稍有点成绩就自满就自高自大的人，浑不知天外有天，外国正在虎视眈眈盯着中国的庞大市场。
由于软件蓝领的呼声人们不再致力于培养大批的高精尖人才，掌握国际尖端技术的人。而是花费心思培训一群猪出来给外国人利用。把自己的命运交给了外国人手里。结果，在最容易的管理软件领域也输给外国人，外国人派几个人过来，利用中国的劳动力，开发出软件，再卖给中国。大量的利润到了外国人手里。而我们的中的一些人还在沾沾自喜：外国人给的工资高；外国的软件好。
奴才！
低品质产品是没人要的。软件蓝领也不例外。
他们不知道中国制造一个优秀程序员的难度，还在患红眼病。程序员制造，你可算过成为一个程序的高昂代价？没日没夜地工作，没有女朋友，感情是一片沙漠，没有钱打工者的命运是悲惨的。
真想知道究竟是哪个公司的程序员为了五十块钱跳槽，是哪个公司说需要软件蓝领。
在马年，过春节，万家欢乐的时候，程序员们还在工作，用他们瘦弱的身躯，支撑起中国的软件工业。
他们把不思进取比喻为工作稳定。
国外可以在一个单位效力几十年。在国内不行。为什么？没有培训，没有上升机会。你被压榨完后就被扔掉。哪个有志向的人甘于这样的命运？
中国的程序员是世界上最好的程序员。他们不计报酬，没日没夜地工作。没有女朋友，没有节假日，可能几年后他们一无所有。他们仍在加班。
一、 程序员为什么要跳槽？有两个报道：
１、“程序员为了五十块钱就跳槽”“万月月薪请不动程序员”“２０％的程序员跳槽后都去了外企”
２、印度的程序员比中国稳定。
另有两个报道：
１、 本科生去美国工作两年后即可年薪１０万美元。当然，他们是加薪很快。
２、 国外的企业都有培训。很吸引人。许多人是冲着培训去的。
国外可以在一个单位效力几十年。在国内不行。为什么？没有培训，没有上升机会。你被压榨完后就被扔掉。哪个有志向的人甘于这样的命运？
中国的程序员是世界上最好的程序员。他们不计报酬，没日没夜地工作。没有女朋友，没有节假日，可能几年后他们一无所有。他们仍在加班。
有培训，就意味着你不会永远拿着现在的薪水。意味着你在不断进取，不断进步，能力越来越强，你就可以担当越来越重的工作，就可涨工资。给人看到未来。即使你对现在的薪水待遇不满意，你通过自身的辛勤不懈的努力和奋斗，就可达到你要的待遇。你不用嫉妒别人。只要你努力就可达到他甚至超过他。
没培训，意味着不思进取，思想僵化，要被淘汰。没有希望，看不到未来。你注定被淘汰。别人通过拼捕获得的成功你就要嫉妒。因为你永远达不到那个高度。只有暗算他，把他拉下来，你才能达到心理的平衡。
去外企，你可以看到一个光明的前途，你可以不断进步。路越走越宽。你在那个企业工作一段时间后，学到了很多东西。出来后你就是另外一个人。我曾经想去一个企业，不是因为他的工资高，而是他那里有培训，甚至送到国外培训，从他那里出来后可以当总经理。
在国内，你的路会越走越窄，最终无路可走。因为你没有学习，落后于时代，再找到新工作都很难。
国内公司只会大呼疾呼人才难留。他们没想过，他们是如何对待人才的，他们只会残酷剥削，搞政治斗争，整人。
国内公司不去学习别人的先进的管理方法，反倒怨来怨去，浑不去找自己自身的原因。
１、 为什么要跳来跳去？
因为在本公司内没有上升机会。
中国程序员是艰苦的，也是聪明的。他们利用一切时间进行学习。就拿我来说，军训完毕后，离计算机机房下班只有十五分钟时间了。一口飞跑到机房，只有十分钟可以学习电脑。就这十分钟，也要利用上。
当他们发现本公司没有培训机会，没有学习机会，可这一切又怎能挡得住前进的脚步？国内公司管理一般是很差的，员工没有成长机会和发展空间。唯一的办法就是跳槽。某人戏称，每跳一次，工资就要加一倍。就拿我来说，每跳一次工资也确实是加一倍。拼命学习获得了知识的高增长，个人的高速进步，这没错。而雇主能看上我，也确实是自己能力已经达到这个水平。但越来最后每跳一次的时间越长。也许是因为进步速度慢了吧。后来又有些后悔，跳来跳去没有根，人到了一定程度就要扎下根来，把一项技术搞透，就需要长时间的积累，反而又踏实下来了。
所以说，那些不断跳来跳去的程序员，其实是仍在初级阶段，到了中级阶段基本就稳定下来了，在某一个细分方向上获得突破。但我建议是，如果不能达到工资翻一倍的水平，或者目标公司没有特别之处，最好不要跳。否则每跳一次，原来积累的人际关系就会丢掉，而技术又没有长足的进步，如此跳来跳去，只会毁了自己，更可能越跳工资越低。到了一定层次后就不能再满足于一些小钱，而是要做事业了。衡量的目标，不是当前多少钱，而是以后会有多少钱。
一般来说，国内公司也没培训，初级阶段获得迅速成长的惟一途径是自我学习跳槽。中级阶段要稳定下来。因为你这时已经到了“高原阶段”，工资也到了高原，精力也没以前充沛，不能再没日没夜加班加点了，也很难再获得突破，要想技术飞速进步只能去国外了。或者自己苦心钻研。现在许许多多的程序员通过自己的努力都到了此阶段。
２、 为什么要跳到外企？
外企有信用。让人放心。有培训，有高薪，老板把你当人看，剥削较轻，不像国内企业那样敲骨吸髓。可以找到女朋友。一般可以找到大施身手的空间。但有随时被裁危险。但一般是做得非常开心、顺心。
老板说给你多少钱一般不用担心他会找理由克扣。这样你就可以尽可以放心地大施手脚。
下面列举几个事实，说明为什么要跳到外企：
１、广州惠创软件公司http://www.hcweb.com.cn/ ;在广州体育西路。
其老板以前是搞外贸的，发了财。我拿自己的全部代码(我拥有版权的软件),他卖.他老板说,你只能给我打工.你自己去运作,赚了钱,你这个软件开发者和版权拥有者只能拿到40%以下.而且你来到公司三个月后,代码的版权要归公司 。
我起身走了。如果我能出国的话，我一辈子都不愿意再回来。
２、广州市小聪软件公司http://www.jxcchina.com
我去之前谈好,我不要工资，我自己独立运作市场和软件开发，他公司只提供一个营业执照，赚钱分给他一半。辛苦了一个月，击败了众多对手后，一个十万元的项目总算有要签合同了。那个老板说，公司调整。你划到市场部。项目的10%拿到市场部，你再从市场部分得点数。(到我手里只有不到5%)。从下个月起，每个月1000块钱工资。你说话不算数，出尔反尔，没信用。我*。*无效。算工资的话，也行，那你把上个月的1000块钱工资算给我才行。不，上个月没工资。只能从下个月开始算工资。那我走，你把项目的15%提成算给我，这是你定的规定。没有15%，你只能拿5%。如果你现在走，那5%也拿不到。
跟这样的公司混，你有未来吗？我能拼命给他干吗？
我拿起背包头也不回地走了。一分钱也没拿到。找到的新工作是，一个月一万。打工。
我想把项目带走。但客户怕得不到保障。因为我没有公司。最后仍是把项目给了那个进销存公司。
３、晶苑集团。港资企业http://www.crystalgroup.com
我对晶苑集团怀着深深的尊敬，并祝 晶苑集团 南中国电脑部 叶富华先生 马到成功，新春愉快。
我印象最深的就是外企的信用。
面试时，接待小姐端来一杯茶水。我很感激他们对我这样一个普通程序员的重视。（我去国内公司面试没有一家给我端水的。他们让你先做一份考题。做完了你回去等通知。后来我有经验了，去之前先问问怎样面试，只要是做题，见不着考官的，一概不去。再后来发展到只要是国内企业的，一概不去。）我的工资是上一份工作的将近二倍。
欣喜若狂。公司有买被子津贴（公司给你买被子）、吃饭补助、住宿补助、加班费(1.5元/小时)。有加班费好啊。拼命加班吧。
每天工作十八个小时到二十个小时。在四个月零十天的工作中，我只休息了一天。其他时间时间每天都像玩命似地。。。没有人逼我们，是我们自愿的。
公司从香港总部派人到大陆对我们进行培训。支出专门的图书经费让我们建立电脑图书馆。请来专门的电脑教师，列出培训大纲，每天对我们进行程序培训。
４、香港迎新丰软件公司。港资http://www.welcomeERP.com ;位于广州天河软件园。
我做了四天，什么成绩都没做出来。但公司归给工资不误。午餐费、住宿费、交通费、保险费都给了我。很有信用。这样的公司，员工不会说它的坏话。只会尊敬、热爱和拥戴这个企业。
老板很好。我们只要使他的资本达到20%的利润率就行了。
5、矩元鞋业。台资。
月薪8000请了个程序员(这个程序员不是我，我没有那么菜）。不知什么原因，反正做了两个月什么也没做出来。公司虽然大呼上当，但仍然是客客气气地付了一万六给他。这份胸襟，试问哪个国内企业能做得到？
结论：
国外企业已经完成原始积累，所以剥削相对轻很多，给员工的空间也较大。国内的企业还正在进行原始积累，进行疯狂压榨。正如资本论所说，只给你基本的生活费，其他的全部被老板拿走。“每一个毛孔都滴着血和肮脏的东西”。那两个国内公司，也滴尽了无数程序员的血泪。
不说了。空喊口号没用。还是克隆微软，克隆人家的管理方式来得实在。把我们玩弄于股掌之上，说给我们加薪加薪再加薪全部算下来我拼命赚钱的9５%都被你拿走多一分都不给我，说给我股票给我们期权可没一样能兑现，你说给我们多少工资我时刻都要提防你克扣工钱。你太贪婪，恨不得把全部拿过去，全部占为己有，不给我们留下一点活路。
你喊多少口号都没用。我幸而生在这个加入ＷＴＯ的社会，要在以前，我早被你整死了。我入外企我光荣。我逃脱魔掌我光荣。“士为知己者死”，你不要怪我们去外企。不能因为你生在中国我们就活该被你整死。你是土老财，我们是被解放军解放的翻身作主的奴隶。
二、程序员工资太高？
你们在花前月下亲那柔嫩的红唇的时候，我们在做什么？你们在剥开女孩子衣服共度良宵的时候，我们在做什么？你们在唱歌跳舞纵情享乐的时候，我们在做什么？你们在争风吃醋大打出手的时候，我们在做什么？你们在给校长送礼的时候，我们在做什么？你们在喝酒猜拳的时候，我们在做什么？
我们在写程序。
如果你把我们的工资和那些好吃懒做在学校泡妞打架毕业后贪污受贿疯狂压榨人民血汗黑心黑手拿黑钱的人进行比较，我只能告诉你，你错了。
你付出了什么，我们付出了什么？
如果因为你的工资只有八百元，看见别人的工资超过你就生气，就要求别人的工资也要向八百元看齐，我只能说，你犯了红眼病了。中国人的劣根就是，不患穷患不均。外国人看到谁有钱就说，啊，我要超过他。中国人说，他妈 的，我恨不得把他杀掉！大家都穷，我没意见，如果有谁冒尖我就想把他给拔掉。只想问一句，别人辛苦工作的时候，你干什么去了？
我要说，当一个人，倾毕生精力和心血，把所有东西都倾注于一件事情时，他获得的只是普通人的十倍工资，这太低了。
只拿着几千块钱工资，太少了。拿这点工资想去买一个人的青春和爱恋，这个人太不值得了。
做生意的，当官的，欺压老百姓的，作威作福的，贪污受贿的。
他们不用担心失业，不用担心技术过时，不用担心众多的竞争者。他们不用担心房子，不用担心车子。谁都知道他们一个月不会只有几千块钱那么简单。打工，写程序，是不能同他们比的。一个拥用着程序员的聪明和智慧的人去做那些事情，收入肯定比当程序员强算了，不比了。比起来心痛。
这两个是纵向比较。同地区不同工种这间比较。按劳取酬，多劳多得，我们的所得与所付出的，仍然是不成比例。
再横向比较。同一个劳动力在不同劳动市场上价格的比较，同一工种在不同地区的工资进行比较。
程序员的工资，不是太高，而是太低了。
一个本科生，出国工作两年后就可年薪十万，美元。而我们在为我们伟大的*国家作贡献，只拿着5%的工资。(国外100万，国内才5万)
一个同事到了国外，月薪5000美元，而他在国内才4000人民币。相差十倍。
一个人，排除掉感情因素，他的东西当然是卖给出价高的那个人。这还用问吗？
正如大批的留学生回来。不是我爱国，而是国内的空白多，机会多，发展空间大，所以我们大批地回来。
时代在呼唤，人才的价值在回归，知识的价值在回归。
附记：
今年过春节，万家团聚，马年飞跃的时候，我在写程序。
刘兴波,你在做什么？
３、 中国需要大量软件蓝领？
我们已经输给了外国，还要在新一轮的竞争中自甘堕落？
1、谁要软件蓝领？
一记者去人才市场向各招聘单位问其需不需要软件蓝领.招聘单位都不明白软件蓝领是什么意思.待记者说明软件蓝领的意思后,各公司都说我们不要。基层人才从来都不缺乏。
一方面是报纸大声呼吁软件蓝领要尽快制造出来,”我们要有大量的低成本的代码工人”,另一方面,企业不要这方面的人才.怪事。是谁大声疾呼需要软件蓝领的？他不知道各大公司都在裁员吗？
面对生产力越来越高的生产工具（软件开发工具），软件蓝领淘汰势在必行。那些学习太慢的白领都会被淘汰掉，更遑论蓝领了。软件蓝领，还没培训出来就已面临灭顶之灾。
软件工厂是不错,但软件工厂的核心不是吞下大量的软件蓝领和人海战术,而是对现有资源的整合和利用,降低现有的生产成本和交易成本.一味嚷嚷要求软件蓝领的企业,只是那些由于管理不善快要被市场淘汰的企业,这样的险恶用心有两个:一是最好不要钱的软件奴隶供驱使,二是将那些正在会成长起来的优秀的人才扼杀在摇篮中，他们成长不起来，就减少了竞争对手。而且由于对他们进行的愚化教育，要他们立志成为软件蓝领。没有了胸怀大志，中国的软件产业才真正危险。
可喜的是，市场将用残酷的市场法则对那些人和那些所谓的软件蓝领进行残酷地淘汰。只有那些真正有领导眼光的魄力的“软件工厂”才会真正建立起来。微软才是软件工厂，他将几十几百人几千人几万人的力量集中在一起，生产出产品，在全世界销售。我们某些“软件工厂”不过是玩概念罢了。玩吧，玩吧，终有死的一天。你会死的很难看。
可喜的是，软件蓝领喊了很久也没见哪个企业招一个，更多的是裁员。
事实证明了蓝领的不适应性。机器排挤人，程序员中也在排挤之列。由于高生产力的开发工具的越来越多的使用，软件开发成本的大幅下降，软件开发越来越自动化，越来越多的人被机器排挤掉。许多由人去完成的事情，现在由机器做的很好，许多程序员被裁下来。(资深程序员应该有这种体会)。
现在所谓的“软件工厂”，最大的危害在于他由于在学生中传播，使许多学生胸无大志，挣两钱就满足，把许多优秀人才扼杀在摇蓝中。
我们需要的是,天才的政治家，整合起一盘散沙的中国，天才的军事家，抵抗外强的侵略。
附：有人由“深圳快找不到蓝领了”而觉得“软件业也快找不到蓝领了”。
深圳快找不到蓝领了。
不错。
他们要找的是什么样的蓝领？是以前概念中的只读完小学二年级，穿着蓝色工装，满身油污，手拿老虎钳的蓝领吗？
不。
他们要精通计算机技术，要精通图纸，要精通制造工艺，要精通机电技术，还要懂英文。这样才能读懂英文说明书，才能看懂图纸，才能编制数控机床所用的计算机程序，才能控制数控机床。而且这些最先进的数控机床使用了目前世界上最先进的技术，因此这个“蓝领”如果几年不跟踪技术趋势他就会发现他不再会使用这些代表着最先进生产力的机器，就会被淘汰掉。
这样的蓝领是一般的所谓的白领能比得上的吗？三个白领也比不上这样一个“蓝领”呀。随随便便大喊一声“我们找不到这样的蓝领”，实在是有失偏颇。有没有想过，在这样一个使用着高技术，掌握着自动化工具蓝领的背后，是多少低技术蓝领的失业？生产制造这样一个蓝领，需要多少金钱和时间？这样的蓝领实在是造价不菲。所以在国外，总工和总经理是一级的，总工的待遇有时比总经理还高。而在国内人多粥少人治环境中，技术人才实在得不到重视。
4、软件工厂
其实，我们真正想要的，不是软件蓝领，而是软件工厂。而且这样的工厂最多只要两个。
当软件生产的管理水平到了一定高度，自会以工厂的形式运作，以大幅降低生产成本。
软件工厂是用来做什么的？
１、生产什么？哪里这么多的订单来维持工厂的运转？
２、软件的零边际成本（即可复制多份而成本几乎为零）。一份软件只需要一份就够的情况下，多个工厂是不是重复开发，浪费资源？这样竞争的结果，顶好是全世界就一家工厂归好，交易成本减少到最小。
中国大规模的重复开发，低水平的重复开发。如果大家团结在一起，组成个工厂，严密组织，分工协作，既提高了生产率，也降低了浪费。
工厂的设立是为了降低交易成本。
软件工业也有生产成本逐渐下降的趋势。只有大规模地群体协作，用工厂这种组织方式能有效地提高生产力，降低交易成本。
工厂的核心不是软件蓝领，而是组织和协作。集中所有人的智慧去做一件事情。大规模地降低生产成本。
中国目前虽然需要软件，但还缺少强有力的组织。可以说，还没发展到工厂的程度。
所以我们曾经有个把中国所有程序员组织起来，像一个大型的软件公司那样运作，做成虚拟软件工厂的想法。但还没做完。
中国的IT确像有些人说的那样，中间人才大量，高精尖人才严重不足。在我看来，基层员工从来就不缺少，由于外国对我们进行技术*，所以我们在向前进军的路上很难突破。但我们中间人才正在夜以继日地，在管理和技术领域进行拼搏，向高精尖人才进军。但只要有一个能突围，一定会有大批人相继突围。我们在等待着群体突破的那一天。那一天，从中间领域“制造”出来的大批高精尖人才在国际软件工业叱咤风云，领袖群雄。
五、“淘尽黄沙始见金”，要是再有员工因为工资而“叛逃”的话，不如说一句：由他去吧！
很潇洒。很气派。道理也很对。只是口气有点自大，有点不自量力，而且也写错了。
我记得原文是"千淘万漉虽辛苦，吹尽狂沙始见金。”，出自于《菜根谭》。刘兴波这位仁兄居然用"淘"尽狂沙始见金”，可见是一位炒股高手。妙，妙！只可惜恐怕是人云亦云，如果所猜不错的话，这位仁兄在专家的指示下应该赔了不少。
只是，在人才界，这个恐怕还要改。去的是谁？留下的是什么？
很不幸，去的都是顶尖高手和优秀员工，留下来的只是找不到工作的人。在这个人满为患，就业困难的社会，只有那个顶尖高手和高素质的人，才能*选择工作单位，才能来去自如，才能到外企工作。留下来的，不是不想走，而是怕找不到新工作。只有那些有本事的人才能“你不把老子当人，老子自会找到把我当人的地方”
借用微软的一句话，那些最优秀的人才永远不会恳求你。
说说两件事。
1、在某软件公司工作期间，深圳一个猎头公司天天打电话来。没错，http://www.jpc.com猎头。
2、简历在网上发布几天后，突然接到神秘电话，邀去面试。咦，这个企业我没发过应聘信哪？去面试。几十人济济一堂，集中比赛。这个公司股东中，日本住友银行竟郝然在目。
3、某集团。好像是在某国际排名中占第十六位吧，说，你过来。你可以把你的朋友全都叫过来上班。把你父母也接来。
你以为被挖走的黄沙哪？
“沙中找金(人才争夺)好激烈，拿走黄金留下沙”。黄金以前被拿到美国，现在是拿到外企，留下的都是别人挑剩下来的。对不？
听刘兴波话的人要倒霉了。
今天是2002.2.14，情人节，一个令所有程序员泪如雨下的日子。“只羡鸳鸯不羡仙”，祝天下所有程序员早日结束不吃饭不睡觉的仙人的日子，早日过上鸳鸯的生活。
我拿着钱痛苦流涕：多少钱才能买走我的爱？
该帖被WULF编辑于2006-5-20 22:33:52。
超越自我 从程序员到系统分析员
大家应该对这两个词很熟悉了,但是对词里包含的意义可能并不是特别清楚。首先必须说明的是,程序员和系统分析员不存在谁高级谁低级的分别，他们是两种职业，对职业技能的要求完全不同。所以厉害的程序员就是系统分析员的说法是不对的。当然，系统分析员的技能要求他必须要懂得如何写程序，但是他的重心在于如何把一个很大的项目切割成适合个人的小块，然后将这些小块组织起来。程序员的职责就是如何更好更快的实现这些小块。
在正式开始之前，我们还是来看在Thinking In Java中作者对分析和设计的一段精辟见解：
分析和设计
面向对象的范式是思考程序设计时一种新的、而且全然不同的方式，许多人最开始都会在如何构造一个项目上皱起了眉头。事实上，我们可以作出一个“好”的设计，它能充分利用OOP提供的所有优点。
请原谅在这里突然出现了OOP这个词，他的意思是面相对象，虽然在之前没有提到，但是在现在OO概念满天飞的软件世界里，大家应该对他不会太陌生。这里我简要的说明一下。在之前我介绍的实际上都是在很早以前程序写作流传下来的经验（什么，教我们老古董，打他！），但是以前的非OO（就是基于过程）的软件设计方法目前在国际上已经很少采用，所以我这里讲软件设计的时候所有的概念都是基于OO的。即使OO的概念很简单的啦，大家思考一下，我们再学习C++的时候一开始使用的类不都是一些动物啦、正方形啦之类的，都是生活中的例子，对吧。其实OO就是我们看世界的一种方式。可是最早由于计算机技术的不发达，我们不得不用一些很奇怪的描述来表达我们的意思，只有这样计算机才能理解，很笨不是吗。比如我们必须使用参数、过程、函数。所以当时的软件设计方法都是基于过程的。举一个简单的例子来显示OO设计方法和基于过程的设计方法之间的差别：一句简单的日常短语－－“我吃饭”，用OO的方法来表述还是“我吃饭”，可是如果用基于过程的方法来描述的话就变成“我吃饭（饭）”，是不是很别扭呢。
有关OOP分析与设计的书籍大多数都不尽如人意。其中的大多数书都充斥着莫名其妙的话语、笨拙的笔调以及许多听起来似乎很重要的声明。我认为这种书最好压缩到一章左右的空间，至多写成一本非常薄的书。具有讽剌意味的是，那些特别专注于复杂事物管理的人往往在写一些浅显、明白的书上面大费周章！如果不能说得简单和直接，一定没多少人喜欢看这方面的内容。毕竟，OOP的全部宗旨就是让软件开发的过程变得更加容易。尽管这可能影响了那些喜欢解决复杂问题的人的生计，但为什么不从一开始就把事情弄得简单些呢？因此，希望我能从开始就为大家打下一个良好的基础，尽可能用几个段落来说清楚分析与设计的问题。
不要迷失
在整个开发过程中，最重要的事情就是：不要将自己迷失！但事实上这种事情很容易发生。大多数方法都设计用来解决最大范围内的问题。当然，也存在一些特别困难的项目，需要作者付出更为艰辛的努力，或者付出更大的代价。但是，大多数项目都是比较“常规”的，所以一般都能作出成功的分析与设计，而且只需用到推荐的一小部分方法。但无论多么有限，某些形式的处理总是有益的，这可使整个项目的开发更加容易，总比直接了当开始编码好！ 也就是说，假如你正在考察一种特殊的方法，其中包含了大量细节，并推荐了许多步骤和文档，那么仍然很难正确判断自己该在何时停止。时刻提醒自己注意以下几个问题：
(1) 对象是什么？（怎样将自己的项目分割成一系列单独的组件？）
(2) 它们的接口是什么？（需要将什么消息发给每一个对象？）
在确定了对象和它们的接口后，便可着手编写一个程序。出于对多方面原因的考虑，可能还需要比这更多的说明及文档，但要求掌握的资料绝对不能比这还少。
整个过程可划分为四个阶段，阶段0刚刚开始采用某些形式的结构。
阶段0：拟出一个计划
第一步是决定在后面的过程中采取哪些步骤。这听起来似乎很简单（事实上，我们这儿说的一切都似乎很简单），但很常见的一种情况是：有些人甚至没有进入阶段1，便忙忙慌慌地开始编写代码。如果你的计划本来就是“直接开始开始编码”，那样做当然也无可非议（若对自己要解决的问题已有很透彻的理解，便可考虑那样做）。但最低程度也应同意自己该有个计划。
在这个阶段，可能要决定一些必要的附加处理结构。但非常不幸，有些程序员写程序时喜欢随心所欲，他们认为“该完成的时候自然会完成”。这样做刚开始可能不会有什么问题，但我觉得假如能在整个过程中设置几个标志，或者“路标”，将更有益于你集中注意力。这恐怕比单纯地为了“完成工作”而工作好得多。至少，在达到了一个又一个的目标，经过了一个接一个的路标以后，可对自己的进度有清晰的把握，干劲也会相应地提高，不会产生“路遥漫漫无期”的感觉。
从我刚开始学习故事结构起（我想有一天能写本小说出来），就一直坚持这种做法，感觉就象简单地让文字“流”到纸上。在我写与计算机有关的东西时，发现结构要比小说简单得多，所以不需要考虑太多这方面的问题。但我仍然制订了整个写作的结构，使自己对要写什么做到心中有数。因此，即使你的计划就是直接开始写程序，仍然需要经历以下的阶段，同时向自己提出一些特定的问题。
阶段1：要制作什么？
在上一代程序设计中（即“过程化或程序化设计”），这个阶段称为“建立需求分析和系统规格”。当然，那些操作今天已经不再需要了，或者至少改换了形式。大量令人头痛的文档资料已成为历史。但当时的初衷是好的。需求分析的意思是“建立一系列规则，根据它判断任务什么时候完成，以及客户怎样才能满意”。系统规格则表示“这里是一些具体的说明，让你知道程序需要做什么（而不是怎样做）才能满足要求”。
需求分析实际就是你和客户之间的一份合约（即使客户就在本公司内部工作，或者是其他对象及系统）。系统规格是对所面临问题的*别的一种揭示，我们依据它判断任务是否完成，以及需要花多长的时间。由于这些都需要取得参与者的一致同意，所以我建议尽可能地简化它们——最好采用列表和基本图表的形式——以节省时间。可能还会面临另一些限制，需要把它们扩充成为更大的文档。 我们特别要注意将重点放在这一阶段的核心问题上，不要纠缠于细枝末节。这个核心问题就是：决定采用什么系统。对这个问题，最有价值的工具就是一个名为“使用条件”的集合。对那些采用“假如……，系统该怎样做？”形式的问题，这便是最有说服力的回答。例如，“假如客户需要提取一张现金支票，但当时又没有这么多的现金储备，那么自动取款机该怎样反应？”对这个问题，“使用条件”可以指示自动取款机在那种“条件”下的正确操作。
应尽可能总结出自己系统的一套完整的“使用条件”或者“应用场合”。一旦完成这个工作，就相当于摸清了想让系统完成的核心任务。由于将重点放在“使用条件”上，一个很好的效果就是它们总能让你放精力放在最关键的东西上，并防止自己分心于对完成任务关系不大的其他事情上面。也就是说，只要掌握了一套完整的“使用条件”，就可以对自己的系统作出清晰的描述，并转移到下一个阶段。在这一阶段，也有可能无法完全掌握系统日后的各种应用场合，但这也没有关系。只要肯花时间，所有问题都会自然而然暴露出来。不要过份在意系统规格的“完美”，否则也容易产生挫败感和焦燥情绪。 在这一阶段，最好用几个简单的段落对自己的系统作出描述，然后围绕它们再进行扩充，添加一些“名词”和“动词”。“名词”自然成为对象，而“动词”自然成为要整合到对象接口中的“方法”。只要亲自试着做一做，就会发现这是多么有用的一个工具；有些时候，它能帮助你完成绝大多数的工作。
尽管仍处在初级阶段，但这时的一些日程安排也可能会非常管用。我们现在对自己要构建的东西应该有了一个较全面的认识，所以可能已经感觉到了它大概会花多长的时间来完成。此时要考虑多方面的因素：如果估计出一个较长的日程，那么公司也许决定不再继续下去；或者一名主管已经估算出了这个项目要花多长的时间，并会试着影响你的估计。但无论如何，最好从一开始就草拟出一份“诚实”的时间表，以后再进行一些暂时难以作出的决策。目前有许多技术可帮助我们计算出准确的日程安排（就象那些预测股票市场起落的技术），但通常最好的方法还是依赖自己的经验和直觉（不要忘记，直觉也要建立在经验上）。感觉一下大概需要花多长的时间，然后将这个时间加倍，再加上10％。你的感觉可能是正确的；“也许”能在那个时间里完成。但“加倍”使那个时间更加充裕，“10％”的时间则用于进行最后的推敲和深化。但同时也要对此向上级主管作出适当的解释，无论对方有什么抱怨和修改，只要明确地告诉他们：这样的一个日程安排，只是我的一个估计！
阶段2：如何构建？
在这一阶段，必须拿出一套设计方案，并解释其中包含的各类对象在外观上是什么样子，以及相互间是如何沟通的。此时可考虑采用一种特殊的图表工具：“统一建模语言”（UML）。请到http://www.rational.com/去下载一份UML规格书。作为第1阶段中的描述工具，UML也是很有帮助的。此外，还可用它在第2阶段中处理一些图表（如流程图）。当然并非一定要使用UML，但它对你会很有帮助，特别是在希望描绘一张详尽的图表，让许多人在一起研究的时候。除UML外，还可选择对对象以及它们的接口进行文字化描述（《Thinking in C++》里说的那样，但这种方法非常原始，发挥的作用亦较有限。
我曾有一次非常成功的咨询经历，那时涉及到一小组人的初始设计。他们以前还没有构建过OOP（面向对象程序设计）项目，将对象画在白板上面。我们谈到各对象相互间该如何沟通（通信），并删除了其中的一部分，以及替换了另一部分对象。这个小组（他们知道这个项目的目的是什么）实际上已经制订出了设计方案；他们自己“拥有”了设计，而不是让设计自然而然地显露出来。我在那里做的事情就是对设计进行指导，提出一些适当的问题，尝试作出一些假设，并从小组中得到反馈，以便修改那些假设。这个过程中最美妙的事情就是整个小组并不是通过学习一些抽象的例子来进行面向对象的设计，而是通过实践一个真正的设计来掌握OOP的窍门，而那个设计正是他们当时手上的工作！
作出了对对象以及它们的接口的说明后，就完成了第2阶段的工作。当然，这些工作可能并不完全。有些工作可能要等到进入阶段3才能得知。但这已经足够了。我们真正需要关心的是最终找出所有的对象。能早些发现当然好，但OOP提供了足够完美的结构，以后再找出它们也不迟。
阶段3：开始创建
读这本书的可能是程序员，现在进入的正是你可能最感兴趣的阶段。由于手头上有一个计划——无论它有多么简要，而且在正式编码前掌握了正确的设计结构，所以会发现接下去的工作比一开始就埋头写程序要简单得多。而这正是我们想达到的目的。让代码做到我们想做的事情，这是所有程序项目最终的目标。但切不要急功冒进，否则只有得不偿失。根据我的经验，最后先拿出一套较为全面的方案，使其尽可能设想周全，能满足尽可能多的要求。给我的感觉，编程更象一门艺术，不能只是作为技术活来看待。所有付出最终都会得到回报。作为真正的程序员，这并非可有可无的一种素质。全面的思考、周密的准备、良好的构造不仅使程序更易构建与调试，也使其更易理解和维护，而那正是一套软件赢利的必要条件。
构建好系统，并令其运行起来后，必须进行实际检验，以前做的那些需求分析和系统规格便可派上用场了。全面地考察自己的程序，确定提出的所有要求均已满足。现在一切似乎都该结束了？是吗？
阶段4：校订
事实上，整个开发周期还没有结束，现在进入的是传统意义上称为“维护”的一个阶段。“维护”是一个比较暧昧的称呼，可用它表示从“保持它按设想的轨道运行”、“加入客户从前忘了声明的功能”或者更传统的“除掉暴露出来的一切臭虫”等等意思。所以大家对“维护”这个词产生了许多误解，有的人认为：凡是需要“维护”的东西，必定不是好的，或者是有缺陷的！因为这个词说明你实际构建的是一个非常“原始”的程序，以后需要频繁地作出改动、添加新的代码或者防止它的落后、退化等。因此，我们需要用一个更合理的词语来称呼以后需要继续的工作。 这个词便是“校订”。换言之，“你第一次做的东西并不完善，所以需为自己留下一个深入学习、认知的空间，再回过头去作一些改变”。对于要解决的问题，随着对它的学习和了解愈加深入，可能需要作出大量改动。进行这些工作的一个动力是随着不断的改革优化，终于能够从自己的努力中得到回报，无论这需要经历一个较短还是较长的时期。
什么时候才叫“达到理想的状态”呢？这并不仅仅意味着程序必须按要求的那样工作，并能适应各种指定的“使用条件”，它也意味着代码的内部结构应当尽善尽美。至少，我们应能感觉出整个结构都能良好地协调运作。没有笨拙的语法，没有臃肿的对象，也没有一些华而不实的东西。除此以外，必须保证程序结构有很强的生命力。由于多方面的原因，以后对程序的改动是必不可少。但必须确定改动能够方便和清楚地进行。这里没有花巧可言。不仅需要理解自己构建的是什么，也要理解程序如何不断地进化。幸运的是，面向对象的程序设计语言特别适合进行这类连续作出的修改——由对象建立起来的边界可有效保证结构的整体性，并能防范对无关对象进行的无谓干扰、破坏。也可以对自己的程序作一些看似激烈的大变动，同时不会破坏程序的整体性，不会波及到其他代码。事实上，对“校订”的支持是OOP非常重要的一个特点。
通过校订，可创建出至少接近自己设想的东西。然后从整体上观察自己的作品，把它与自己的要求比较，看看还短缺什么。然后就可以从容地回过头去，对程序中不恰当的部分进行重新设计和重新实现（注释⑩）。在最终得到一套恰当的方案之前，可能需要解决一些不能回避的问题，或者至少解决问题的一个方面。而且一般要多“校订”几次才行。
构建一套系统时，“校订”几乎是不可避免的。我们需要不断地对比自己的需求，了解系统是否自己实际所需要的。有时只有实际看到系统，才能意识到自己需要解决一个不同的问题。若认为这种形式的校订必然会发生，那么最好尽快拿出自己的第一个版本，检查它是否自己希望的，使自己的思想不断趋向成熟。
反复的“校订”同“递增开发”有关密不可分的关系。递增开发意味着先从系统的核心入手，将其作为一个框架实现，以后要在这个框架的基础上逐渐建立起系统剩余的部分。随后，将准备提供的各种功能（特性）一个接一个地加入其中。这里最考验技巧的是架设起一个能方便扩充所有目标特性的一个框架（对这个问题，大家可参考第16章的论述）。这样做的好处在于一旦令核心框架运作起来，要加入的每一项特性就象它自身内的一个小项目，而非大项目的一部分。此外，开发或维护阶段合成的新特性可以更方便地加入。OOP之所以提供了对递增开发的支持，是由于假如程序设计得好，每一次递增都可以成为完善的对象或者对象组。
这有点类似“快速造型”。此时应着眼于建立一个简单、明了的版本，使自己能对系统有个清楚的把握。再把这个原型扔掉，并正式地构建一个。快速造型最麻烦的一种情况就是人们不将原型扔掉，而是直接在它的基础上建造。如果再加上程序化设计中“结构”的缺乏，就会导致一个混乱的系统，致使维护成本增加。
计划的回报
如果没有仔细拟定的设计图，当然不可能建起一所房子。如建立的是一所狗舍，尽管设计图可以不必那么详尽，但仍然需要一些草图，以做到心中有数。软件开发则完全不同，它的“设计图”（计划）必须详尽而完备。在很长的一段时间里，人们在他们的开发过程中并没有太多的结构，但那些大型项目很容易就会遭致失败。通过不断的摸索，人们掌握了数量众多的结构和详细资料。但它们的使用却使人提心吊胆在意——似乎需要把自己的大多数时间花在编写文档上，而没有多少时间来编程（经常如此）。我希望这里为大家讲述的一切能提供一条折衷的道路。需要采取一种最适合自己需要（以及习惯）的方法。不管制订出的计划有多么小，但与完全没有计划相比，一些形式的计划会极大改善你的项目。请记住：根据估计，没有计划的50％以上的项目都会失败！
非常佩服作者对软件构建过程的精辟见解，软件工程是一门内容非常繁杂的学科，但是作者能够用浅显易懂的句子把它描述出来，真的是非常不简单。软件工程最早的提出者并不是计算机的专业人士，而是一位建筑设计师，所以软件工程的很多思想来自于建筑学。经过了几十年的发展，软件工程经历了很多次的蜕变。形成了今天的世界上以一些大公司提出的架构为主的形式：比如微软提出的COM及COM+以及基于其上的DNA体系，SUN提出的EJB，CORBA，还有BEA、WebLogic、IBM等公司的架构。虽然架构有不同，但是他们的思想都是相通的，架构的作用都是起到辅助开发者实现规范的、科学的软件开发过程。至于谈软件项目的管理和开发，那么Rational公司就是这方面的鼻祖。综合来说，目前世界范围内的软件工程提倡的就是以渐进的、螺旋式的开发方法构建基于组件的软件产品。现在说这些东西可能有些画饼的嫌疑，随着我们专题讨论的继续深入，这些概念就会很清晰的展现在面前。
虽然很希望能够继续的讨论软件工程方面的东东，但是我们的这个专题毕竟是讨论如何编写优美的程序的，离题还是不要太过分的好，至于软件工程的详细讨论，我会在接下去的专题中继续。在接下去的篇幅中，我们会继续讨论程序员和系统分析员之间的差别。
四个阶段
这里我不想举一大堆的数字和实例来描述软件危机和论证软件工程的重要性，这方面的资料有很多，如果一一列举的话，会被怀疑别有用心。事实上，建造狗舍和写一个小的软件没有很大的区别。虽然你认为你的能力可以很轻松的完成小型的软件系统，根本不需要任何的计划。好！我来问问你，你在写程序代码的时候，有没有过漏这漏那，程序快接近完成的时候却发现少了一个很重要的模块；有没有过在书写了大量的代码之后觉得自己写出来的东西不堪入目，恨不得重头开始；有没有过写程序花了两天的时间，但是Debug却花了一个星期的时间；有没有过听到软件的使用者说要改需求，你就恨不得狠狠揍他一顿。如果都没有，那么只有两种可能：你是个超级天才，所有人类能够想到的美好品质你都具有，另一种可能：你根本没有开发过软件。
即便是个人开发的软件，软件工程科学中也有相应的方法来指导软件的开发过程，这种方法叫做PSP（个人软件开发过程），与此相对的，还有TSP（小组软件开发过程）。这些被事实证明行之有效的方法包括了一整套的规范，帮助你开发你的软件，不让你的程序变得无法控制。可以说，对于任何一个软件系统来说，只要你花一些时间去设计，即便你的设计仅仅只是在草稿纸上随便的涂抹，在软件开发完成后，你就会惊喜的发现，你在软件开发早期的小小投入，已经为你带来了额外的好处。
路标和RUP
在阶段0中，我想最重要的思想就是就是“路标”的概念了，和这个概念相类似的概念还有“周期”和“里程碑”的概念，这些概念在Rational公司的RUP(Rational Unified Process 软件统一过程)中有详细的论述。不论这些概念叫做什么，他们体现出来的是一种迭代开发的思想。面对当今的复杂的软件系统，使用连续的开发方法：如首先定义整个问题，设计完整的解决方案，编制软件并最终测试产品，是不可能的。需要一种能够通过一系列细化，若干个渐进的反复过程而生成有效解决方案的迭代方法。
Rational Unified Process支持专注于处理生命周期中每个阶段中最高风险的迭代开发方法，极大地减少了项目的风险性。迭代方法通过可验证的方法来帮助减少风险－－经常性的，可执行版本使最终用户不断的介入和反馈。因为每个迭代过程以可执行版本告终，开发队伍停留在产生结果上，频繁的状态检查帮助确保项目能按时进行。迭代化方法同样使得需求、特色、日程上战略性的变化更为容易。(出自《Rational Unified Process白皮书》)
上面这段好像很复杂，但是他所要说明的思想却是很简单的，就拿搭建狗舍来说，你的第一个“路标”可能是要搭一个框架，这个框架是由几根结实的木头组成，等到框架完成之后，你会把你的小白叫来，让他试一下，糟糕的是，这个框架对于小白来说小了一些，这时候你嘘了一口气，因为你原来是打算把整个狗舍搭好以后再叫小白来试一下的，如果你那样做的话，你剩下的木头可能就不够再盖一间狗舍了。好吧，既然有了些问题，我们就把框架调整一下，可能这个过程也花了你一些木头，不过所幸木头还够。在修整完毕后，你觉得第一步的计划虽然有些挫折，不过仍可以算是成功的，接下来你就要建立第二个“路标”了：第二个的“路标”是为狗舍钉上墙板和做出一个底座，你可能花了一些时间来思考以及和你的小白商量是否要在墙壁上开一个窗户和给底座加上*，在决定之后，你很快的达成了第二个“路标”。而且在经过了小白的测试后，你发现完全没有问题，你自己都觉得有些佩服自己了，很快的，你又完成刷油漆等“路标”。整个过程进展的非常顺利，而你在做狗舍方面很有天赋的名声也在你的街坊四邻间不胫而走。
很简单是吧，其实本来就是简单的，软件工程的目的就是要把复杂的软件开发过程条理化，简单化。记住，在你使用迭代开发方法的时候，它在每个周期后的产品是一份可执行代码，是一份可以让你的用户品头论足的东西。而这份可执行代码不仅包括了程序本身，可能还有其他的产成品，例如：文档等。
问题和场景
在阶段1中，非常重要的一点是问题描述，在多数情况下，问题描述来自于你的软件的使用者，就是用户。用户的需求决定了问题描述，糟糕的是，用户多半不懂计算机，对他们来说，他们只能够用日常的语言来表达自己的需要。而你的任务就是要把他们的语言翻译成计算机语言，不过并不是指象C那样的高级语言，而是便于你构造系统的需求描述语言。这同样很简单：你只需要问自己几个问题就可以：在什么场合？有什么条件？做些什么事？回答好这三个问题，你就完成了一个完整的问题描述了。
举一个简单的例子：一个银行的信贷系统有这样的问题描述：
“若顾客采取信用贷款方式，销售员就请求信用部门的审核人员查核顾客的信用，此时审核人员会向销售员取得顾客信用编号和销货总金额。”
在某种条件下应该做什么事情，这就是这个问题描述的表现形式，很简单是吧。
实际上，这里可以引申出两个概念：场景(context)和问题(problem)，场景指的是一种特定的情况，会导致某种问题的发生；而问题是在某个场景之中，但它也有可能产生出新的场景。
过程和对象
有必要说明一下以前基于过程的软件开发和目前基于对象的软件开发的不同。在没有OO的年代里，DFD(Data Flow Diagram 数据流程图)是一份软件设计中的非常重要的文档，注意力的关键也是集中在数据如何在各个系统之间传递。可是在现在的OO概念中，数据大有为消息(message)所替代的趋势。比如你到麦当劳快餐店，要花10块钱买一份汉堡。在DFD的时代，就是这样表示的：
如果你用消息表示法来表示话，就是另一种方式：
怎么样，你觉得那一种方式更自然呢。(如果你敢回答第一种的话我就...)。再比如上一段话中关于问题描述的例子，如果用传统的数据描述的方法的话，就会是这样子的：
“若采取信用贷款方式，销售员就将顾客信用编号及总金额交给信用部门的信用审核人员。”
请比较其中的两句话：
“若采取信用贷款方式，销售员就将顾客信用编号及总金额交给信用部门的信用审核人员。”
“若顾客采取信用贷款方式，销售员就请求信用部门的审核人员查核顾客的信用，此时审核人员会向销售员取得顾客信用编号和销货总金额。”
了解其中的不同之处了吗，用自然的语言去描述你的问题，这是写出好的软件的第一步。
系统分析员的语言
场景描述是一个很不错的方法，可是随着你对系统的分析的深入，参与开发的人员的增加，你渐渐的感觉这种方法不够用了。原因有很多：文字的描述不够直观，不可能到达一种很细致的程度。这时候就需要一种能够描述问题、描述解决方案、起沟通作用的语言。这就是UML。
UML(Unified Modeling Language 统一建模语言)是由Rational公司发明，目前由OMG(标准化对象管理机构)维护。作为一种建模语言,UML的定义包括UML语义和UML表示法两个部分：
UML语义
描述基于UML的精确元模型定义。元模型为UML的所有元素在语法和语义上提供了简单、一致、通用的定义性说明,使开发者能在语义上取得一致,消除了因人而异的最佳表达方法所造成的影响。此外UML还支持对元模型的扩展定义。
UML表示法
定义UML符号的表示法,为开发者或开发工具使用这些图形符号和文本语法为系统建模提供了标准。这些图形符号和文字所表达的是应用级的模型,在语义上它是UML元模型的实例。标准建模语言UML的重要内容可以由下列五类图(共9种图形)来定义：用例图、静态图、行为图、交互图、实现图。
从应用的角度看,当采用面向对象技术设计系统时,首先是描述需求；其次根据需求建立系统的静态模型，以构造系统的结构；第三步是描述系统的行为。其中在第一步与第二步中所建立的模型都是静态的，包括用例图、类图(包含包)、对象图、组件图和配置图等五个图形，是标准建模语言UML的静态建模机制。其中第三步中所建立的模型或者可以执行，或者表示执行时的时序状态或交互关系。它包括状态图、活动图、顺序图和合作图等四个图形,是标准建模语言UML的动态建模机制。因此，标准建模语言UML的主要内容也可以归纳为静态建模机制和动态建模机制两大类。
这样说，你可能还是不了解UML到底是什么，不过UML并不是我们讨论的重点，你只需要知道UML是一种建模语言，他的目的就是在开发团队之间提供一种通用的、简单的沟通机制，并且UML是面相对象的。
上面所说的这些就是阶段2的重点所在。使用UML语言对阶段1中提出的问题描述进行深化，从各方各面看待问题：顺序、流程、数据、状态、接口等。最终你得到的是一套完整的文档，做为详细的程序设计的参考和标准。
不要累坏自己
上面说了这么多在编程之前要做的工作，但是要注意的是，不是所有的开发工作都必须做这么多的工作的。对于你来说，抓住最重要的内容，不要涉及到太多的细节。对你写出来问题描述，必须要仔细的分析，而这里的分析呢，并不是要你用程序来实现你的问题描述，而是你必须从问题描述中分析出对象(object)、事件(event)和消息(message)。例如上面所提到的例子：
“若采取信用贷款方式，销售员就将顾客信用编号及总金额交给信用部门的信用审核人员。”
你可能看到这句话以后就会在想做一个审核信用的函数，参数部分有信用编号和总金额，然后开始设计程序的细节。如果你是这样干的话，这说明你还没有真正了解OO的思想，你的开发方式仍然停留在以前基于过程的开发方式中。那么面相对象的分析是怎样进行的呢。我们还是来看这段话，撇开你的程序，你的语言，你从这句话中获得了什么信息？是的，你知道说这个企业中有销售员、有信用审核人员；要求审核顾客信用是他们的工作之一；顾客的信用编号和总金额是审核顾客信用的时候的重要信息。这是任何一个普通的人看到这段话后的感觉，这就是OO的分析(在OO中这种的分析方法称为OOAD)。其实是很简单的，和你采用什么样的程序一点关系都没有。
软件重用(Reuse)是软件工程中最重要的思想之一，只有软件重用，才能降低软件成本，提高软件的质量。你在对一个软件进行分析的时候，找出可以重用的对象，有助于你开发高效的软件系统。正如前面所说的，你不必把软件分析的过分细致，你只需从中找出关键性的、能够重用的对象就足够了。剩下的事情，就是对这些对象分配属性和方法，并充分的使用这些对象就好了。
还是那个例子：我们已经从中看到了一些对象：销售员、信用审核人员。但是他们在系统中不具备重用性，至少是重用性不强。信用部门这个对象也存在这个问题。所以不能够把他们作为底层的对象，我们用一个术语Entity Objects 来称呼底层对象。那什么是软件系统中的Entity Objects呢？*教导我们要透过现象看本质。上面的描述中有很多隐含的信息：
顾客请求信用贷款：这里就包括两个Entity Objects：顾客、信用贷款。
销售员、信用审核人员都是员工，所以员工也是一个Entity Objects。
观察一个Entity Objects，你会发现，Entity Objects已经是最小的单位，是使用软件的用户(这里是银行)最小的单位。当然不但是这个软件有Entity Objects，比如我们最常用的Word，我们可以想象一下它的Entity Objects有什么，可能是一种叫做图元的Entity Objects，一个图元包括了文字、图象以及其他的对象。
用OO的方法分析你的软件，从设计到实现都是非常的自然，可能你学习面向对象时是从C++开始的，被其中的虚函数、多态性、多基类继承搞得一头雾水。但是实际上OO的方法要比以前的方法简单的多，不相信？试一试，你就知道了。
校订、校订再校订
第3个阶段称为校订，这个称呼真是太贴切了，既不是测试，也不是返工。任何事物从诞生起都必须经历不断的改进才有可能成熟。(呵呵，说出这么有哲理的话，我都很佩服自己啊。)软件同样不例外。事实上，在阶段0中，我们就讨论了“路标”的概念，当你的第一个路标达成之后，剩下的应该都是属于校订的事了。通过和用户的交互，确定新的“路标”，不断的改进系统功能，优化系统结构，修正系统Bug。
正如作者所说的那样，真正OO的软件是经得起修改的，由于采用了多层的结构以及面向对象的思想，以前软件的致命伤(修改)在新的开发方法面前不会是个大问题。(注意，这并不是说你可以无规划构建你的软件)
由于以前的系统大多会将GUI、事务处理、数据存储都做在一起，当你需要修改一个地方的时候，你就会发现问题的严重性：一个小小的需求变动都意味着你的系统将面临伤筋动骨般的修改。在OO的时代里，所有的对象的访问都是通过接口(Interface)进行的，对象中方法的改变并不会接口产生影响，也就是说，调用该接口的模块不用做任何的修改。另外，如果你打算把你的系统的界面从C/S方式向B/S方式改变，同样不会有问题，你可以很容易的把GUI部分从原有的系统中剥离出来。软件的修改对你来说不再是一个恶梦。
职场：电脑程序员的蘑菇定律
电脑程序员意外的发现20世纪70年代，一批刚从学校毕业的“天之骄子”参加了工作，这些天马行空、独来独往的年轻人面对令人窒息的工作环境很难适应。于是，一批年轻的电脑程序员经过探索，发现了一段“蘑菇定律”。
这条定律是指，许多用人单位对待职业新手的一种管理方法，初学者被置于阴暗的角落(不受重视的部门或打杂跑腿的工作)，浇上一头大粪(无端的批评、指责、代人受过)，任其自生自灭(得不到必要的指导和提携)。
在这个定律中，虽然有年轻的电脑程序员自嘲的心理以及人们对他们的误解和漠视。但是，这对很多人来说，不一定是什么坏事，当上几天“蘑菇”，能够消除我们很多不切实际的幻想，让我们更加接近现实，看问题也更加实际。
笑迎蘑菇管理每一位初入职场的年轻人都不可避免地遇到这个阶段，如何以高效率走过这个时期，并从中汲取经验，迅速成熟起来，是每一个初入职场的人都应当面对的课题。
那么，你在被当做“蘑菇”时应当怎样做呢？第一，要喜欢你自己的这份工作。学会从工作中获得乐趣，而不仅仅是按照命令被动地工作。
第二，要注意礼貌问题。适当的礼仪十分必要，因为它里面包含了许多人类的智慧。以利于建立良好的人际关系。
第三，多做事，少抱怨。如果你在开始的工作中就满腹牢骚、怨气冲天，那么你就会对工作草率从事，从而有可能造成错误的发生；或者本可以做得更好的，而没有做到。这会使你在以后的职务分配中很难得到你本可以争取到的工作。
第四，做事还要有计划。在处理事情的时候要随时记录重要信息，事情处理完毕，要及时主动向领导汇报，并要做到报告时内容详细完整。
接受洗礼，适应环境正如温水青蛙原理所揭示的道理一样，越是严酷的自然环境，越能激发一个人的自下而上能力，从而使他(她)能脱离逆境的困境的困扰；而表面上温情似水的生存环境，则极可能会消磨你的斗志，并使你丧失应有的警惕性，从而逐渐让你陷入停滞的陷阱。
所以，那些表面看来对员工要求很严格，工作环境也不是很好的企业，反而能培养一个人的耐力和素质，从而在根本上提高人的生存能力，拓宽你的发展之路。
选择是需要成本的让我们来看看这样一则故事：一次，所罗门王把一个小女孩带到稻田跟前说：“你不是想要一件贵重的礼物吗？我可以赏给你，但你要替我做一件事情：把这片稻田里最大的稻穗选出来，拿给我。”
小女孩高兴地答应了。
“但是，我有一个条件，”所罗门王接着说，“你在经过稻田时，要一直向前走，不允许停下来，也不能退回来，更不能左右转弯。你要记住，我给你的礼物，是与你选择的稻穗大小成正比的。”
结果这个小女孩从稻田里走出来后，什么礼物也没有获得，因为她一路上总是嫌所看见的稻穗太小了。
不少年轻人也像这个小女孩一样，理想比天高，可是进入职场之后，并没有受到重视，一气之下不干了，认为后面一定还有更好的工作等着自己。就这样折腾了几年之后，好工作依然没有找到，而当初跟自己一起毕业的人，已经由普通职员升到了管理者。这就意味着，人生中最大的浪费就是选择浪费，这也是最容易被忽视的浪费。
选择是需要成本的，只要你认真选择了一份适合自己的职业，就应当努力坚持下去。
职场上成功的秘诀美国石油大王洛克菲勒经常固定在一家餐厅里用餐，每次用餐之后，他都会留下一美元当服务生的小费。
服务生忍不住说：“如果我是你，我不会吝惜给这么少的小费！”
洛克菲勒回答：“就是这样，你才只是一个服务生。”
这里还有一个故事。有位董事长一大早就到公司上班，看到新来的清洁工正在打扫卫生，就笑着对他说：“只要你好好做，总有一天，你也能像我一样做到董事长的。”
清洁工也笑着回答董事长：“董事长，您也要好好地经营公司，否则，有一天，您也会像我一样成为清洁工的。”
你不要以为是洛克菲勒，或者是董事长，就可以不认真做事，就可以马马虎虎过日子！因为，谁敢保证将来不会有主雇易位的一天呢？
对于新进人员来说，成功的秘诀无他，惟有辛勤工作，不断地自我反思，不断地自我改进。
由弘一网童保存，尚未注册。注册