3. 你们的测试组还在用Word写测试用例么？　
 不要用Word写测试用例（Test Case）。应该用一个专门的系统，可以是Test Manager，也可以是自己开发一个ASP.NET的小网站。主要目的是Track和Browse。
 
4. 你们的项目组有没有建立一个门户网站？　
　要有一个门户网站，用来放Contact Info、Baselined Schedule、News等等。推荐Sharepoint Portal Server 2003来实现，15分钟就搞定。买不起SPS 2003可以用WSS (Windows Sharepoint Service)。

5. 你们的项目组用了你能买到最好的工具么？　
　应该用尽量好的工具来工作。比如，应该用VS.NET而不是Notepad来写C#。用Notepad写程序多半只是一种炫耀。但也要考虑到经费，所以说是"你能买到最好的"。
 
6. 你们的程序员工作在安静的环境里么？　
　需要安静环境。这点极端重要，而且要保证每个人的空间大于一定面积。
 
7. 你们的员工每个人都有一部电话么？
需要每人一部电话。而且电话最好是带留言功能的。当然，上这么一套带留言电话系统开销不小。不过至少每人一部电话要有，千万别搞得经常有人站起来喊："某某某电话"。《人件》里面就强烈谴责这种做法。
 
8. 你们每个人都知道出了问题应该找谁么？　
　应该知道。任何一个Feature至少都应该有一个Owner，当然，Owner可以继续Dispatch给其他人。

9. 你遇到过有人说"我以为…"么？　
　要消灭"我以为"。Never assume anything。
 
10. 你们的项目组中所有的人都坐在一起么？　
　需要。我反对Virtual Team，也反对Dev在美国、Test在中国这种开发方式。能坐在一起就最好坐在一起，好处多得不得了。
 
11. 你们的进度表是否反映最新开发进展情况？ 　
　应该反映。但是，应该用Baseline的方法来管理进度表：维护一份稳定的Schedule，再维护一份最新更改。Baseline的方法也应该用于其它的Spec。Baseline是变更管理里面的一个重要手段。
 
12. 你们的工作量是先由每个人自己估算的么？　
　应该让每个人自己估算。要从下而上估算工作量，而不是从上往下分派。除非有其他原因，比如政治任务工期固定等。
 
13. 你们的开发人员从项目一开始就加班么？　
　不要这样。不要一开始就搞疲劳战。从项目一开始就加班，只能说明项目进度不合理。当然，一些对日软件外包必须天天加班，那属于剥削的范畴。
 
14. 你们的项目计划中Buffer Time是加在每个小任务后面的么？　
　不要。Buffer Time加在每个小任务后面，很容易轻易的就被消耗掉。Buffer Time要整段的加在一个Milestone或者checkpoint前面。
 
15. 值得再多花一些时间，从95%做到100%好值得，非常值得。　
　尤其当项目后期人困马乏的时候，要坚持。这会给产品带来质的区别。
 
16. 登记新缺陷时，是否写清了重现步骤？
　要。这属于Dev和Test之间的沟通手段。面对面沟通需要，详细填写Repro Steps也需要。
 
17. 写新代码前会把已知缺陷解决么？
 要。每个人的缺陷不能超过10个或15个，否则必须先解决老的bug才能继续写新代码。
 
18. 你们对缺陷的轻重缓急有事先的约定么？　
　必须有定义。Severity要分1、2、3，约定好：蓝屏和Data Lost算Sev 1，Function Error算Sev 2，界面上的算Sev 3。但这种约定可以根据产品质量现状适当进行调整。
 
19. 你们对意见不一的缺陷有三国会议么？
 必须要有。要有一个明确的决策过程。这类似于CCB (Change Control Board)的概念。
 
20. 所有的缺陷都是由登记的人最后关闭的么？ 　
　Bug应该由Opener关闭。Dev不能私自关闭Bug。
 
21. 你们的程序员厌恶修改老的代码么？　
　厌恶是正常的。解决方法是组织Code Review，单独留出时间来。XP也是一个方法。
 
22. 你们项目组有Team Morale Activity么？　
　每个月都要搞一次，吃饭、唱歌、Outing、打球、开卡丁车等等，一定要有。不要剩这些钱。
 
23. 你们项目组有自己的Logo么？　
　要有自己的Logo。至少应该有自己的Codename。
 
24. 你们的员工有印有公司Logo的T-Shirt么？　
　要有。能增强归属感。当然，T-Shirt要做的好看一些，最好用80支的棉来做。别没穿几次就破破烂烂的。

25. 总经理至少每月参加次项目组会议要的。　
　要让team member觉得高层关注这个项目。
 
26. 你们是给每个Dev开一个分支么？　
　反对。Branch的管理以及Merge的工作量太大，而且容易出错。
 
27. 有人长期不Check-In代码么？　
　不可以。对大部分项目来说，最多两三天就应该Check-In。
 
28. 在Check-In代码时都填写注释了么？　
　要写的，至少一两句话，比如"解决了Bug No.225（给bug编号）"。如果往高处拔，这也算做"配置审计"的一部分。
 
29. 有没有设定每天Check-In的最后期限？　
　要的，要明确Check-In Deadline。否则会Build Break。
 
30. 你们能把所有源码一下子编译成安装文件吗？ 　
　要的。这是每日编译（Daily Build）的基础。而且必须要能够做成自动的。
 
31. 你们的项目组做每日编译么？　
　当然要做。有三样东西是软件项目/产品开发必备的：1. bug management; 2. source control; 3. daily build。

32. 你们公司有没有积累一个项目风险列表？　
　要。Risk Inventory。否则，下个项目开始的时候，又只能拍脑袋分析Risk了。
 
33. 设计越简单越好越简单越好。　
　设计时候多一句话，将来可能就带来无穷无尽的烦恼。应该从一开始就勇敢的砍。这叫scope management。

34. 尽量利用现有的产品、技术、代码千万别什么东西都自己Coding。
BizTalk和Sharepoint就是最好的例子，有这两个作为基础，可以把起点提高很多。或者可以尽量多用现成的Control之类的。或者尽量用XML，而不是自己去Parse一个文本文件；尽量用RegExp，而不是自己从头操作字符串，等等等等。这就是"软件复用"的体现。
 
35. 你们会隔一段时间就停下来夯实代码么？　
　要。最好一个月左右一次。传言去年年初Windows组在Stevb的命令下停过一个月增强安全。Btw，"夯"这个字念"hang"，第一声。

36. 你们的项目组每个人都写Daily Report么？　
　要写。五分钟就够了，写10句话左右，告诉自己小组的人今天我干了什么。一则为了沟通，二则鞭策自己（要是游手好闲一天，自己都会不好意思写的）。

37. 你们的项目经理会发出Weekly Report么？　
　要。也是为了沟通。内容包括目前进度，可能的风险，质量状况，各种工作的进展等。
 
38. 你们项目组是否至少每周全体开会一次？　
　要。一定要开会。程序员讨厌开会，但每个礼拜开会时间加起来至少应该有4小时。包括team meeting, spec review meeting, bug triage meeting。千万别大家闷头写code。
 
39. 你们项目组的会议、讨论都有记录么？　
　会前发meeting request和agenda，会中有人负责主持和记录，会后有人负责发meeting minutes，这都是effective meeting的要点。而且，每个会议都要形成agreements和action items。
 
40. 其他部门知道你们项目组在干什么么？　
　要发一些Newsflash给整个大组织。Show your team's value。否则，当你坐在电梯里面，其他部门的人问："你们在干嘛"，你回答"ABC项目"的时候，别人全然不知，那种感觉不太好。
 
41. 通过Email进行所有正式沟通
Email的好处是免得抵赖。但也要避免矫枉过正，最好的方法是先用电话和当面说，然后Email来确认。

42. 为项目组建立多个Mailing Group 　
　如果在AD+Exchange里面，就建Distribution List。比如，我会建ABC Project Core Team，ABC Project Dev Team，ABC Project All Testers，ABC Project Extended Team等等。这样发起Email来方便，而且能让该收到email的人都收到、不该收到不被骚扰。
 
43. 每个人都知道哪里可以找到全部的文档么？　
　应该每个人都知道。这叫做知识管理（Knowledge Management）。最方便的就是把文档放在一个集中的File Share，更好的方法是用Sharepoint。
 
44. 你做决定、做变化时，告诉大家原因了么？　
　要告诉大家原因。Empower team member的手段之一是提供足够的information，这是MSF一开篇的几个原则之一。的确如此，tell me why是人之常情，tell me why了才能有understanding。中国人做事喜欢搞限制，限制信息，似乎能够看到某一份文件的人就是有身份的人。大错特错。权威、权力，不在于是不是能access information/data，而在于是不是掌握资源。
 
45. Stay agile and expect change 要这样。　
　需求一定会变的，已经写好的代码一定会被要求修改的。做好心理准备，对change不要抗拒，而是expect change。
 
46. 你们有没有专职的软件测试人员？　
　要有专职测试。如果人手不够，可以peer test，交换了测试。千万别自己测试自己的。
 
47. 你们的测试有一份总的计划来规定做什么和怎么做么？
 这就是Test Plan。要不要做性能测试？要不要做Usability测试？什么时候开始测试性能？测试通过的标准是什么？用什么手段，自动的还是手动的？这些问题需要用Test Plan来回答。
 
48. 你是先写Test Case然后再测试的么？　
　应该如此。应该先设计再编程、先test case再测试。当然，事情是灵活的。我有时候在做第一遍测试的同时补上test case。至于先test case再开发，我不喜欢，因为不习惯，太麻烦，至于别人推荐，那试试看也无妨。
 
49. 你是否会为各种输入组合创建测试用例？　
　不要，不要搞边界条件组合。当心组合爆炸。有很多test case工具能够自动生成各种边界条件的组合--但要想清楚，你是否有时间去运行那么多test case。

50. 你们的程序员能看到测试用例么？　
　要。让Dev看到Test Case吧。我们都是为了同一个目的走到一起来的：提高质量。

51. 你们是否随便抓一些人来做易用性测试？ 　
　要这么做。自己看自己写的程序界面，怎么看都是顺眼的。这叫做审美疲劳--臭的看久了也就不臭了，不方便的永久了也就习惯了。
 
52. 你对自动测试的期望正确么？　
　别期望太高。依我看，除了性能测试以外，还是暂时先忘掉"自动测试"吧，忘掉WinRunner和LoadRunner吧。对于国内的软件测试的现状来说，只能"矫枉必须过正"了。

53. 你们的性能测试是等所有功能都开发完才做的么？　
　不能这样。性能测试不能被归到所谓的"系统测试"阶段。早测早改正，早死早升天。
 
54. 你注意到测试中的杀虫剂效应了么？　
　虫子有抗药性，Bug也有。发现的新Bug越来越少是正常的。这时候，最好大家交换一下测试的area，或者用用看其他工具和手法，就又会发现一些新bug了。
 
55. 你们项目组中有人能说出产品的当前整体质量情况么？　
　要有。当老板问起这个产品目前质量如何，Test Lead/Manager应该负责回答。
 
56. 你们有单元测试么？　
　单元测试要有的。不过没有单元测试也不是不可以，我做过没有单元测试的项目，也做成功了--可能是侥幸，可能是大家都是熟手的关系。还是那句话，软件工程是非常实践、非常工程、非常灵活的一套方法，某些方法在某些情况下会比另一些方法好，反之亦然。

57. 你们的程序员是写完代码就扔过墙的么？　
　大忌。写好一块程序以后，即便不做单元测试，也应该自己先跑一跑。虽然有了专门的测试人员，做开发的人也不可以一点测试都不做。微软还有Test Release Document的说法，程序太烂的话，测试有权踢回去。
 
58. 你们的程序中所有的函数都有输入检查么？　
　不要。虽然说做输入检查是write secure code的要点，但不要做太多的输入检查，有些内部函数之间的参数传递就不必检查输入了，省点功夫。同样的道理，未必要给所有的函数都写注释。写一部分主要的就够了。
 
59. 产品有统一的错误处理机制和报错界面么？　
　要有。最好能有统一的error message，然后每个error message都带一个error number。这样，用户可以自己根据error number到user manual里面去看看错误的具体描述和可能原因，就像SQL Server的错误那样。同样，ASP.NET也要有统一的Exception处理。可以参考有关的Application Block。
 
60. 你们有统一的代码书写规范么？　
　要有。Code Convention很多，搞一份来发给大家就可以了。当然，要是有FxCop这种工具来检查代码就更好了。
 
61. 你们的每个人都了解项目的商业意义么？　
　要。这是Vision的意思。别把项目只当成工作。有时候要想着自己是在为中国某某行业的信息化作先驱者，或者时不时的告诉team member，这个项目能够为某某某国家部门每年节省多少多少百万的纳税人的钱，这样就有动力了。平凡的事情也是可以有个崇高的目标的。
 
62. 产品各部分的界面和操作习惯一致么？　
　要这样。要让用户觉得整个程序好像是一个人写出来的那样。
 
63. 有可以作为宣传亮点的Cool Feature么？　
　要。这是增强团队凝聚力、信心的。而且，"一俊遮百丑"，有亮点就可以掩盖一些问题。这样，对于客户来说，会感觉产品从质量角度来说还是acceptable的。或者说，cool feature或者说亮点可以作为质量问题的一个事后弥补措施。
 
64. 尽可能缩短产品的启动时间要这样。　
　软件启动时间（Start-Up time）是客户对性能好坏的第一印象。
 
65. 不要过于注重内在品质而忽视了第一眼的外在印象程序员容易犯这个错误：太看重性能、稳定性、存储效率，但忽视了外在感受。而高层经理、客户正相反。这两方面要兼顾，协调这些是PM的工作。
 
66. 你们根据详细产品功能说明书做开发么？　
　要这样。要有设计才能开发，这是必须的。设计文档，应该说清楚这个产品会怎么运行，应该采取一些讲故事的方法。设计的时候千万别钻细节，别钻到数据库、代码等具体实现里面去，那些是后面的事情，一步步来不能着急。
 
67. 开始开发和测试之前每个人都仔细审阅功能设计么？　
　要做。Function Spec review是用来统一思想的。而且，review过以后形成了一致意见，将来再也没有人可以说"你看，当初我就是反对这么设计的，现在吃苦头了吧"

68. 所有人都始终想着The Whole Image么？
要这样。项目里面每个人虽然都只是在制造一片叶子，但每个人都应该知道自己在制造的那片叶子所在的树是怎么样子的。我反对软件蓝领，反对过分的把软件制造看成流水线、车间。参见第61条。
 
69. Dev工作的划分是单纯纵向或横向的么？　
　不能单纯的根据功能模块分，或者单纯根据表现层、中间层、数据库层分。我推荐这么做：首先根据功能模块分，然后每个"层"都有一个Owner来Review所有人的设计和代码，保证consistency。
 
70. 你们的程序员写程序设计说明文档么？　
　要。不过我听说微软的程序员1999年以前也不写。所以说，写不写也不是绝对的，偷懒有时候也是可以的。参见第56条。
 
71. 你在招人面试时让他写一段程序么？　
　要的。我最喜欢让人做字符串和链表一类的题目。这种题目有很多循环、判断、指针、递归等，既不偏向过于考算法，也不偏向过于考特定的API。
 
72. 你们有没有技术交流讲座？　
　要的。每一两个礼拜搞一次内部的Tech Talk或者Chalk Talk吧。让组员之间分享技术心得，这笔花钱送到外面去培训划算。

73. 你们的程序员都能专注于一件事情么？　
　要让程序员专注一件事。例如说，一个部门有两个项目和10个人，一种方法是让10个人同时参加两个项目，每个项目上每个人都花50%时间；另一种方法是5个人去项目A，5个人去项目B，每个人都100%在某一个项目上。我一定选后面一种。这个道理很多人都懂，但很多领导实践起来就把属下当成可以任意拆分的资源了。
 
74. 你们的程序员会夸大完成某项工作所需要的时间么？　
　会的，这是常见的，尤其会在项目后期夸大做某个change所需要的时间，以次来抵制change。解决的方法是坐下来慢慢磨，磨掉程序员的逆反心理，一起分析，并把估算时间的颗粒度变小。
 
75. 尽量不要用Virtual Heads 最好不要用Virtual Heads。　　Virtual heads意味着resource is not secure，shared resource会降低resource的工作效率，容易增加出错的机会，会让一心二用的人没有太多时间去review spec、review design。一个dedicated的人，要强过两个只能投入50%时间和精力的人。我是吃过亏的：7个part time的tester，发现的Bug和干的活，加起来还不如两个full-time的。参见第73条。73条是针对程序员的，75条是针对Resource Manager的。
 

记住建议就是建议！！！

陆汝钤，计算机语言的形式语义.北京:科学出版社,1992
屈延文，形式语义学基础与形式说明.北京:科学出版社,1998
周巢尘，形式语义学引论，长沙：湖南科学技术出版社，1985
另外上海师范大学物理信息学院陈仪香教授对此也有深入研究。以下对四种语义学的简介来即自陈教授"形式语义的论语理论研究进展"一文（见下列著作第二章：陆汝钤主编，《知识科学与计算科学》.北京：清华大学出版社，2003）

操作语义的基本思想是建立一个抽象机器以模拟程序在执行过程中如何进行数据处理。
指称语义的思想是使语言的每一成分对应于一个数学对象，该对象称为该语言成分的指称，程序看作输入域到输出域的映射，输入域和输出域统称为论域。因此论域与映射是指称语义的基本研究对象。
公理语义实在程序正确性验证的基础上发展起来的，它给出一种方法，使人们在给定的前提下，验证某种特性是否成立。
代数语义的基本思想是把描述语义的逻辑体系和满足这个逻辑系统的各种模型统一在一起，同时把模型的集合看成是以代数机构，研究这些模型之间的关系。

戴维民主编的《信息组织》一书（高等教育出版社.2004 面向21世纪课程教材）中认为语法、语义和语用信息的分法是"按照信息组织的层次分"，具体解释如下：
"从认知的角度，可把信息分为语法信息、语义信息和语用信息。由于主体具有观察力，能够感知事物运动状态及其变化方式的外在形式，由此获得的信息称为语法 信息；由于主体具有理解力，能够领悟事物运动状态及其变化方式的逻辑含义，由此获得的信息称为语义信息；又由于主体具有明确的目的性，能够判断事物运动状 态及其变化方式的效用，由此获得的信息称为语用信息。"有一定道理，好像又不是很确切。不知道这种理解出自何处？语言学？哲学？认识论？

计算机形式语义学参考书：

1、周巢尘，《形式语义学引论》，湖南科技出版社（绝版）
2、周之英，翻译，《计算机形式规范概论》，清华大学出版社（绝版）
3、屈延文，《形式语义学基础与形式说明》，科学版（绝版）
4、陆汝钤，《计算机语言的形式语义》，科学版
5、陈意云，（实际是编译的），《形式语义学基础》，中国科技大学出版社
6、陈意云，（实际是编译的），《程序设计语言理论》，中国科技大学出版社
7、宋国新，翻译，《程序设计语言的形式语法及语义》，机工版

从发展来说，国内的形式语义学或程序理论的教材，落后国外十年以上。国外现在最流行的几本教材是：

1、《Semantics of Programming Languages》（Carl A.Gunter）MIT Press 1992
这是目前也许是最流行的一本教材，主要采用了简单类型的Lambda Calculus和范畴学来表达语义学，内容取舍比较合理，章节安排也不错，属于高级教程，评价也很高，很多大学都推荐使用。

2、《The Formal Semantics of Programming Languages》（Glynn Winskel）MIT Press 1993
另一本流行的一本教材，作者Winskel是剑桥大学的教授，该书在欧洲几乎成为标准教材了，评价也很高，中高级教程，很多大学都推荐使用，已经出了中文版，大家可以到书店买到。

3、《Foundations for Programming Languages 》（John C. Mitchell ）MIT Press 1996
作为桌案上的参考书就最好了，作者是斯坦福教授。这本书是一本巨作，内容齐全，大量泛代数内容，绝对是超高级教程，但作为教材的话内容太多了，850页，真的是本大部头

4、《Theories of Progamming Languages》（John C. Reynolds）Cambridge Press 1998
Reynolds是CMU教授，他的这本教材出发角度和上面的几本有所不同，按作者的话来说，就是尽量避免使用高深的数学理论，诸如范畴学之类的东西，同时这本书内容涉及也比较广，甚至有并发理论和CSP。该书在评价非常高，推荐大家看。

5、《Semantics of Programming Languages》（R.D. Tennent）Prentice-Hall 1990
这本书的最大特点就是采用imperative language作为研究对象，和国内的教学最符合了，国外很多大学，特别是欧洲的大学，普遍采用函数式汝ML语言作为研究和教学语言。作者R.D. Tennent在八十年代初，曾经出版过一本《Principles of Programming Languages》，国际国内都很多人参考过这本书。

6、《Introduction to the Theory of Programming Languages》（Bertrand Meyer）Prentice-Hall 1988
作者大家都很熟悉了，他的另一本书《Object-Oriented Software Construction》前几年就已经引进中国了。这本书几乎没有高深的数学内容，可能这本书出的比较早些，书的内容要比前面的几本书都要容易浅些，但作为入门的书，我推荐这本。

通用惟一标识符（UUID）是128位比特的数字，用来惟一地标识因特网上的某些对象或者实体。

A Universally Unique Identifier is an identifier standard used in software construction, standardized by the Open Software Foundation (OSF) as part of the Distributed Computing Environment (DCE). The intent of UUIDs is to enable distributed systems to uniquely identify information without significant central coordination. Thus, anyone can create a UUID and use it to identify something with reasonable confidence that the identifier will never be unintentionally used by anyone for anything else. Information labelled with UUIDs can therefore be later combined into a single database without need to resolve name conflicts. The most widespread use of this standard is in Microsoft's Globally Unique Identifiers (GUIDs) which implement this standard.

一个UUID 是一个标识符标准用于软件架构，是由开放软件基金会（OSF）作为分布式计算环境（DCE）的一部分而制定的标准。UUIDs的目的就是使分布式系统可以不需要重要的中央调合系统而能唯一地标识信息。这样，任何人能创造一个UUID 和使用它来标识一些东西，而且，你有足够的信心来确定这个标识是永远不会被任何人无意地使用在任何东西上。因此，信息加上了UUID标签就能合并到单个数据库中而不用去解决命名冲突的问题。这个标准的广泛应用在微软的全球唯一标识符（GUIDs）上，GUID实现了这个标准。

A UUID is essentially a 16-byte number and in its canonical form a UUID may look like this:

:550E8400-E29B-11D4-A716-446655440000

And has this structure in the C programming language:

typedef struct {
unsigned32 time_low;
unsigned16 time_mid;
unsigned16 time_hi_and_version;
unsigned8 clock_seq_hi_and_reserved;
unsigned8 clock_seq_low;
byte node6;
} uuid_t;

The J2SE 5.0 release of Java provides a class that will produce 128-bit UUIDs. The API documentation for the class refers to ISO/IEC 11578:1996.

关于UUID的定义，详细内容可参考http://www.ietf.org/rfc/rfc4122.txt，文档里面还有C语言对UUID标准的各种实现。

GUID

A Globally Unique Identifier or GUID is a pseudo-random number used in software applications. While each generated GUID is not guaranteed to be unique, the total number of unique keys (2128 or 3.4028×1038) is so large that the possibility of the same number being generated twice is very small.

一个全球唯一标识符 或 GUID 是一个假随机数用于软件中。虽然每个产生的GUID是不保证唯一的，但不同的标识符总数是（2128 也就是3.4028×1038）如此之大，以至于相同的数字被产生两次的机率是很相当小的。

The GUID is an implementation by Microsoft of a standard called Universally Unique Identifier (UUID), specified by the Open Software Foundation (OSF).

GUID 是微软对UUID这个标准的实现。UUID是由开放软件基金会（OSF）定义的。

UUID还有其它各种实现，不止GUID一种，其它的在此不详细说明。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/nidehong/archive/2006/11/22/1406125.aspx

UUID是是128位整数(16字节)的全局唯一标识符(Universally Unique Identifier)，指在一台机器上生成的数字，它保证对在同一时空中的所有机器都是唯一的。通常平台会提供生成UUID的API。UUID按照开放软件基金会(OSF)制定的标准计算，用到了以太网卡地址、纳秒级时间、芯片ID码和许多可能的数字。由以下几部分的组合：当前日期和时间(UUID的第一个部分与时间有关，如果你在生成一个UUID之后，过几秒又生成一个UUID，则第一个部分不同，其余相同)，时钟序列，全局唯一的IEEE机器识别号（如果有网卡，从网卡获得，没有网卡以其他方式获得），UUID的唯一缺陷在于生成的结果串会比较长。关于UUID这个标准使用最普遍的是微软的GUID(Globals Unique Identifiers)。

UUID，其格式为：xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxxxxxx(8-4-4-16)，其中每个 x 是 0-9 或 a-f 范围内的一个十六进制的数字。而标准的UUID格式为：xxxxxxxx-xxxx-xxxx-xxxxxx-xxxxxxxxxx (8-4-4-4-12)

       在建立数据库的时候，需要为每张表指定一个主键，所谓主键就是能够唯一标识表中某一行的属性或属性组，一个表只能有一个主键，但可以有多个候选索引。因为主键可以唯一标识某一行记录，所以可以确保执行数据更新、删除的时候不会出现张冠李戴的错误。数据库的主键生成有多种方式，每种方式都有其优点和缺点，应该根据不同的需求在主键的时间和空间效率上做平衡折中，从而选择不同的主键生成策略。归纳起来，对主键的选择主要有以下四种方式：

1.     自动增长字段

         自动增长型字段允许我们在向数据库添加数据时，不考虑主键的取值，记录插入后，数据库系统会自动为其分配一个值，确保绝对不会出现重复。

2.     手动增长字段

         手动增长型的字段，也就是说主键的值需要自己维护，通常情况下需要建立一张单独的表存储当前主键键值。

3.     GUID类型

         GUID是Globally Unique IDentifier的缩写，是一个128位的随机数,并保证不产生重复。

4.     COMB类型

         COMB（combine）型可以理解为一种改进的GUID，它通过组合GUID和系统时间，以使其在索引和检索事有更优的性能。

COMB数据类型的基本设计思路是这样的：既然GUID数据因毫无规律可言造成索引效率低下，影响了系统的性能，那么能不能通过组合的方式，保留GUID的10个字节，用另6个字节表示GUID生成的时间（DateTime），这样我们将时间信息与GUID组合起来，在保留GUID的唯一性的同时增加了有序性，以此来提高索引效率。

下面转自：温少，首发于博客园

替代方案之一，就是使用关系数据库的自增长字段，自增长字段的一个问题是，无法预先创建一个ID，只能够在保存的时候才能生成ID，这对于批量关联插入数据来说，不满足需求。

替代方案之二，就是使用一个记录ID的表，每次加一，在事务中使用Select FOR UPDATE来读取然后UPDATE SET FVALUE = FVALUE + 1，或者使用我之前文章中所提到的CAS算法。 这样做，会导致性能低下，每生成一个ID的成本都很高。

替代方案之三，就是把ID分成两部分，Seed和IncrementID。Seed采用上面的方案二或者其他办法生成，IncrementID使用一个AtomicInteger来每次递增生成。SEED转化为九进制数字，这样SEED就不会包含9，于是使用9作为分隔符，把SEED和IncrementID隔开。这样做，就可以做高性能产生ID，而且确保不重复。甚至可以更进一步，SEED由一个中心服务器生成。使用9个分隔符号隔开SEED和IncrementID，好处是SEED是变长，而不是使用固定位数来保存SEED，这样产生的ID会更短，可读性更好。

举例，34915，其中34时SEED，15是IncrementID，9是分隔符，SEED部分采用九进制表示法，确保不出现9，第一个9之后的内容属于IncrementID。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/happyflystone/archive/2007/11/27/1903854.aspx

要想从一名普通程序员发展成为优秀的架构师，“个人特性”与“技术技能”缺一不可；而“技术专业能力”、“人际关系能力”和“业务能力”更是优秀架构师重要的三种能力。

文 / 周爱民（《程序员》2008年4月刊）

引子

究竟是什么让你在同一个位置上——例如程序员或技术负责人——工作了三年、五年或者更久，而 仍然得不到任何的发展空间？你觉得自己已成为技术圈中的大牛，并信心满满地去拿明天就要颁发的某某大奖，然而却仍然停留在同样的技术职位上，去年到今年涨 的薪水甚至填不平物价升幅？于是，你开始对老板不满，对员工不满，对昨天升职的那个同事不满……你开始计划明天就要跑单，或者准备考虑提出加薪却又心怀忐 忑。

如果技术人员有发展的轨迹，那么他要么“看透工具的本质，把关注点转移到‘团队’的圈子里去 ”，要么“顺着代码铺就的道路，亦步亦趋地成为良匠大师”。仅以技术方向而言，你大概可以做到架构师、总架构师甚至首席架构师；但问题是：你现在还只是一 个程序员。那要如何才能踏上通往架构师之路呢？本文为你解析一个架构师的能力模型。

你能不能做一个好的架构师？

架构师不是界定一个技术高下的职位名称，而是一个职务。所谓职务，包括职——职位，务——工作。前者决定了你具备哪些资源，可以影响到怎样的范围，以及面向的机构，后者则简单地是你需要完成的工作列表。

所以我说“架构师”不是指“一个能做架构的人”。前者是把架构师当职能，后者是当工人。能做 一份工作列表中的事，并不等于就成为相应职位上的人。在管理体系里面，你的个人特性决定了你在哪个位置，而技术技能只是做事实施的必需。架构师这个职务， 同时要求较高的个人素质和技术能力，因此它的进取之路总结起来就是：做人、做事，做架构师。

因此“模型”由“个人特性”和“技术技能”两个方面构成，在第一张图中，我特别说明“个人特性”既包括人际关系的能力，也包括（具体）业务能力；“技术技能”也是如此。所以个人特性主要与“做人”有关，部分地也包含“做事”的要素。

                                            图1 架构师能力模型

“有效沟通”以及“学会谈判”与做具体的事无关，是个人能力特性的公共方面。前者是过程，后 者是知道如何定目标与求结果。而“风险与防备”是做事过程控制的关键，与前面两项正好构成了一个做事基本能力的完整体系。基本上，这三项个人特性都是一个 “普通程序员”所不具备的，甚至在大多数情况下，普通程序员并不愿意去具备这样的个人特性，因为在许多陷于技术泥淖的开发人员看来：沟通总是会使事情变得 更加麻烦，谈判则徒耗时间而无济于事。然而事实上，在整个的架构决策过程中，架构师需要不停地沟通与谈判。将“架构”变成“决策”的过程，其实就是对各个 技术角色（及其思想）兼容并包的过程，你需要不断地协调需求、实现之间的各种问题，也需要面对各种投资者（时间、资金、人才等方面的决策者）进行谈判，以 确定项目的规模——没有规模也就没有范围，没有范围如何展开设计呢？

一部分开发人员会认为上述过程是“项目经理”的事情，但真的如此吗？当你作为一个更高级别的架构师，以至于要影响到多个项目的决策时，你就全然不会有这种感受了。因为这种情况下，你的决策将先于项目的启动，或者说你已经不单单是一个技术角色了。

设计是架构能力的一部分，但架构师不是设计师——看清楚二者之间的不同，你才真正迈出了架构师职业生涯的第一步。

抽象是思维能力、模型化是表达能力

个人特性中另一个非常重要的方面是“抽象思维”，而这是与架构师角色直接相关的一种能力。这种能力既有职业技能特征，又是普遍性的能力。

所谓普遍性的能力，是指“抽象”在我们——作为人这种个体的——生活中无处不在。例如我们说 花、草，说桌、椅……我们用语言去指称任何一个既已存在的（可以脱离我们的语言而自然存在的）事物时，就用到了抽象。说“桌子”的时候，既没有描述桌子的 具体形式，也没有说明它的规格，但我们用这个名词时，所有人都知道“桌子是什么”。所以，名词概念是整个抽象逻辑系统中的主体。如果失去了这些名词定义， 我们基本上不能说话，也不能描述任何东西——那便到了“只可意会不可言传”的境地。

用现有的成熟语汇去描述你的系统时，大多数人会理解你所表达的含义，例如我们说“这个系统设 计为一个三层结构”。然而架构师面临的系统在许多细节上并不见得能够用成熟的语汇去描述，因此必须自已构建一个抽象系统，这就需要概念抽象能力、概念表达 能力和基于概念的逻辑表达能力。

概念抽象能力是一种思维能力。简单地说，就是“把目标分解或概括清楚”：你要么概而言之“它 是什么”，要么详细地说明“它包括什么”。必须使用大量的语汇来陈述这个“什么”，这不单单是表达为文字，也表达为你在思想过程中的一个完整系统。通常用 的方法是“映射系统”。例如你可以用数学中的“数轴”来映射“实数域”。将目标系统形式化为一个概念化的、可讨论的结构系统后，你的抽象过程就基本结束 了。

                                            图2 能力模型中的个人特性

然而这个“抽象系统”可能只构建在你的思维意识里，还必须把它描绘出来。因为不能只是你自己思考清楚，系统就能设计完成。这个“描绘”就依赖于后面两种表达能力，一种是描绘概念实体，一种是描绘实体上的逻辑——有趣的是，这似乎又回到了“程序＝结构＋算法”。

现在大家回过头来看看UML，或者更多种类的ML（建模语言），他们就用于表达这两个方面的东西：要么是概念实体（例如用一个框表明系统边界），要么是实体上的逻辑（例如用箭头表明逻辑时序）。

所以大家应该清楚，我们再如何称赞UML，它也只是一种对模型化系统的“表达能力”，你只能把它当一种辅助表达的工具去使用，它本身既不能帮助思考，也不见得能作为抽象过程中的或抽象思维环境中的参考。

任何一个优秀的架构师都有自己独特的思考方式，这决定了他如何抽象系统，以及如何“创造性地 ”设计与构画这个系统。这种“独特的思考方式”贯彻他从孩童开始的整个成长过程，直至他形成独立的社会观、人生观与世界观。他认识世界的方式和接受世界的 能力决定于他如何思考，也反映了他这种思考方式的“独特性”。但这并不表明他有特立独行的行为特性（我们这里只说他的思考方式），我们不应介意他是否用某 种语言（例如UML或者形式化编程语言）来表达他的思考结果。

推动：设计做大，实施做小

架构师首先是把问题的真正目标确定下来，然后变成系统设计、平台设计或架构设计。而在此之后 设计输出将会有两个方向的发展，一是被忠实地贯彻下来，二是被变形地发展下去。两个方向都存在致命的危险：架构最终能否被完整实现。对前者来说，可能是架 构设计过度，或设计本身出现了错误；后者则是对架构直接的伤害。

所以架构师必须参与实施的全程——尤其是在架构被映射为目标系统的前期。在这个阶段中，架构 师的任务就是推动架构实施，以保证在项目全程的设计／架构／体系的一致性。除了直接跟设计师或设计团队沟通，以保证他们的设计在你可以控制的范围之内以 外，架构师还必须有阶段化设计的能力。这种能力用于将一个原本规模宏大的架构设计，变成较小的、易于实施的、对开发团队来说可控的关键点。例如在体系层次 的规划上，设计可能是独立、异质的、可迁移的存储框架来实现数据层，但在（前期的）实施上，这里可能被表达为本地数据库，并要求前端开发人员必须通过一个 清晰的数据交互层来访问——例如一组数据存取接口，或一个独立数据服务组件。开发人员可能在这里遇到障碍：因为要通过这些中间层来访问本地数据库，纯粹是 多余的。然而，正是这“多余的工作”提供了系统弹性，为并行团队开发公共存储服务争取了周期，也为将来的灵活部署与数据迁移提供了可能。

这里的关键就在于，无论原始系统设定有多大，实施时总是在“做小”。每一个局部的实施块都是 可控的，并为它在整个体系空间中留下了位置和接口，这样才可能由“小的部分”做大。一个大系统的架构师可能同时在考虑许多个项目中的、不同位置的架构，并 且清楚这些项目最终的总体规模。而这，就是平台架构师和体系架构师所涉的领域。

                                            图3 架构师模型图中的“实现能力”

架构真的是“好不好”的问题吗？如同我对工程的理解一样，架构问题的根本，也并不在于它是否 完美或漂亮，而是在于是否合用。因此架构师必须对实施架构的团队以及实施过程有充分了解，知道他们的能力缺陷，知道实现过程要消耗的资源，清楚每个环节可 能的故障以及先兆。只有这样，架构师才能设计一个让这个团队能实现，而且在实现过程中能受控的架构。

要知道，你作为架构师被请来，不是画几张图纸交给项目经理，说：你们去做吧，做不出来是你们 不会做。即使你可以身体力行，在这个团队中教大家、培养大家，那么公司的开销呢？风险呢？这些东西难道就不考虑了？项目的周期因为实现的复杂程度而无法控 制时，项目就死掉了。那么，追根究底来说，是不是架构师的问题？是啊，你为什么会做了一份“不合用”的架构呢？——你都不知道项目如何开发、由谁实施、如 何管理等等，又如何能面对这些实际环境去设计架构呢？

所以这一部分能力，是要在你的开发经验、团队经验以及用人识人的经验中去找的。参考模型图的“实现能力”下的“设计能力→了解你的主要沟通对象”和“架构推行”等分支，对你或有一些可用的提示。

局部与全局

架构是一个从全局到局部的过程，而实施正好反过来，是从局部到全局。这也正是“设计做大，实施做小”的另一个层面的含义。设计大才可以见到全局，才知道此全局对彼全局的影响；实施小才可能关注细节，才谈得上品质与控制。

事实上，大多数情况下架构是在为“当前项目之外”去考虑，这可以看成全局关注的一个组成部分。因此我们需要界定所谓“全局”的范围：超出公司或整个产品系列、产品线或规划的范围才是多余的。

所以当架构决策谈及“全局”时，其目标并不见得是“保障当前项目”，而又必须由当前项目去完成。

一个经常被用到的例子是：如果仅为当前项目考虑，那么只需要做成DLL模块；如果为产品线考虑，可能会是“管道＋插件”的结构形式。而“管道＋插件”的形式显然比做成DLL模块更费时，这个时间成本（以及其它成本）就变成了当前项目的无谓开销。

这种全局策略对局部计划的影响是大多数公司不能忍受的，也被很多团队所垢病。然而这却是架构 师角色对体系的“近乎必然”的影响——如果你试图在体系中引用架构师这个角色的话。一些情况下，体系能够容纳这种影响，例如“技术架构师”试图推动某种插 件框架，而正好开发人员对这项技术感兴趣，那就顺其自然地花点工夫去实现了。但如果不是这样，实施者或实施团队看不到“多余的部分”对他们的价值时，来自 局部的抵触就产生了。

这种情况下，平衡这些抵触就成了架构推行的实务之一。在我看来，“平衡”是全局的艺术和局部 的技术。也就是说，一方面架构师要学会游说，另一方面也要寻求更为简洁的、成本更小的实现技术。只有当整个体系都意识到（你所推行的）架构的重要性，而且 实施成本在他们可以接受的范围之内时，他们才会积极行动起来。

所以所谓平衡，其实也是折衷的过程。构架师只有眼中见大，才知道哪些折衷可以做，而哪些不 能。所谓设计评估（模型图中的实现能力->设计能力->设计评估分支）并不是去分析一个设计结果好或不好，而是从中看到原始的需求，看到体系 全局的意图，然后知道在将设计变得更为“适当”时可以做哪些折衷。同样的原因，架构师也必须知道自己的决策会产生的影响，才能控制它们，以防它们变成团队 的灾难。有些时候，架构师甚至需要抛弃一些特性，以使得项目能够持续下去。因为产品的阶段性产出只是整个战略中的一个环节，而不是全部。

其它

“怎么做一个架构师”这个问题得分成两个部分来看，一个是“做到”，一个是“做好”。由于架构师本身不过是一个技术职位，所以时机成熟了自然会做得到。但问题是，真有一天你被放在这个位置上了，你能做得好吗？

我浏览过几套所谓培训机构的有关架构师的教程，也翻阅过一些讲架构的书。我发现他们普遍地是 将架构作为一种“职业技术”来讲，就像培养程序员或者缝纫工一样来教育。但就我的经验来说，架构并不是一件纯粹表现技术能力的工作，所以并不是翻几本书学 几种方法就可以投入“实战”的。更深层的问题是，架构师其实不是“战”出来的。昨天跟同事讨论这个话题，他把我们这几年来的一些思考用了三句话来概括，非 常精彩：从无到有的，是架构；从表到里的，是抽象；从粗到细的，是设计。

那么到底什么是架构呢？从上面的概括中你是看不到答案的。到底如何做架构呢？从本文中你也是 看不到答案的。然而我说，“你看不到答案”的根源其实是在于你的眼光与心性——后面这个词换成现代白话，就是“思想”。真正阻碍了你成为优秀架构师的，也 许正是你既有的知识与思想方法，扔掉它们，接受一些全然有别的信息，也许正是良好的开端。

或许你现在正愤愤然：这篇文章怎么空洞无物？——我甚至能想象到一些读者的表情。然而请在问题面前停下来，不要急于给出答案。正如你将“?”稍微变下形，它就成为了“!”一样，问题的本身，就是答案。

作者简介

周爱民（aimingoo），具有十余年的软件开发、项目管理和团队建设的经验，现担任盛大网络的平台架构师，著有《大道至简》、《Delphi源代码分析》等。

原文地址： http://vipnews.csdn.net/newscontent.aspx?pointid=2008_05_30_150239242

目前比较常用的负载均衡技术主要有：
　　1. 基于DNS的负载均衡
　　通过DNS服务中的随机名字解析来实现负载均衡，在DNS服务器中，可以为多个不同的地址配置同一个名字，而最终查询这个名字的客户机将在解析这个名字时得到其中一个地址。因此，对于同一个名字，不同的客户机会得到不同的地址，他们也就访问不同地址上的Web服务器，从而达到负载均衡的目的。

　　2. 反向代理负载均衡 （如Apache+JK2+Tomcat这种组合）
　　使用代理服务器可以将请求转发给内部的Web服务器，让代理服务器将请求均匀地转发给多台内部Web服务器之一上，从而达到负载均衡的目的。这种代理方式与普通的代理方式有所不同，标准代理方式是客户使用代理访问多个外部Web服务器，而这种代理方式是多个客户使用它访问内部Web服务器，因此也被称为反向代理模式。

　　3. 基于NAT（Network Address Translation）的负载均衡技术 （如Linux Virtual Server，简称LVS）
　　网络地址转换为在内部地址和外部地址之间进行转换，以便具备内部地址的计算机能访问外部网络，而当外部网络中的计算机访问地址转换网关拥有的某一外部地址时，地址转换网关能将其转发到一个映射的内部地址上。因此如果地址转换网关能将每个连接均匀转换为不同的内部服务器地址，此后外部网络中的计算机就各自与自己转换得到的地址上服务器进行通信，从而达到负载分担的目的。

介绍完上面的集群技术之后，下面就基于Tomcat的集群架构方案进行说明：

上面是采用了Apache httpd作为web服务器的，即作为Tomcat的前端处理器，根据具体情况而定，有些情况下是不需要Apache httpd作为 web 服务器的，如系统展现没有静态页面那就不需要Apache httpd，那时可以直接使用Tomcat作为web 服务器来使用。使用Apache httpd主要是它在处理静态页面方面的能力比Tomcat强多了。
1、 用户的网页浏览器做完本地 DNS和企业授权的DNS之的请求/响应后，这时候企业授权的DNS（即21cn BOSS DNS）会给用户本地的DNS服务器提供一个NAT请求分配器（即网关）IP。

2、 NAT分配器，它会根据特定的分配算法，来决定要将连接交给哪一台内部 Apache httpd来处理请求。大多数的NAT请求分配器提供了容错能力：根据侦测各种WEB服务器的失效状况，停止将请求分配给已经宕掉的服务器。并且有些分配器还可以监测到WEB服务器机器的负载情况，并将请求分配给负载最轻的服务器等等。Linux Virtual Server是一个基于Linux操作系统上执行的VS-NAT开源软件套件，而且它有丰富的功能和良好的说明文件。商业硬件解决方案 Foundry Networks的ServerIron是目前业界公认最佳的请求分配器之一。

3、 Apache httpd + Mod_JK2在这里是作为负载均衡器，那为什么要做集群呢？如果集群系统要具备容错能力，以便在任何单一的硬件或软件组件失效时还能100%可用，那么集群系统必须没有单点故障之忧。所以，不能只架设一台有mod_jk2的Apache httpd，因为如果 httpd或mod_jk2失效了，将不会再有请求被会送交到任何一个Tomcat 实例。这种情况下，Apache httpd就是瓶劲，特别在访问量大的网站。

4、 Mod_JK2负载均衡与故障复原，决定把Apache httpd当成web服务器，而且使用mod_jk2将请求传送给Tomcat，则可以使用mod_jk2的负载均衡与容错功能。在集群系统中，带有mod_jk2的Apache httpd可以做的事情包括：
A、 将请求分配至一或多个Tomcat实例上
你可以在mod_jk2的workers.properties文件中，设定许多Tomcat实例，并赋于每个实例一个lb_factor值，以作为请求分配的加权因子。

B、 侦测Tomcat实例是否失败
当Tomcat实例的连接器服务不再响应时，mod_jk2会及时侦测到，并停止将请求送给它。其他的Tomcat实例则会接受失效实例的负载。

C、 侦测Tomcat实例在失效后的何时恢复
因连接器服务失效，而停止将请求分配给Tomcat实例之后，mod_jk2会周期性地检查是否已恢复使用性，并自动将其加入现行的Tomcat实例池中。

5、 Tomcat中的集群原理是通过组播的方式进行节点的查找并使用TCP连接进行会话的复制。这里提示一下就是，对每个请求的处理，Tomcat都会进行会话复制，复制后的会话将会慢慢变得庞大。

6、 Mod_jk2同时支持会话亲和和会话复制。在tomcat 5中如何实现会话亲和和会话复制？把server.xml中的标签去掉就实现会话亲和，把标签加上就实现会话复制。

7、 会话亲和：就是表示来自同会话的所有请求都由相同的Tomcat 实例来处理，这种情况下，如果Tomcat实例或所执行的服务器机器失效，也会丧失Servlet的会话数据。即使在集群系统中执行更多的Tomcat实例，也永远不会复制会话数据。这样是提高集群性能的一种方案，但不具备有容错能力了。

8、 使用会话复制，则当一个Tomcat实例宕掉时，由于至少还有另一个Tomcat实例保有一份会话状态数据，因而数据不会丧失。但性能会有所降低。

　　在Eric Raymond的坚持下，这群人同意他们所缺乏的是市场营销活动，这个活动的目的是赢得思想，而不仅仅是市场份额。最后讨论的结果产生了一个新的术语来描述他们所推进的软件：Open Source(开烦扰软件)。他们制定了一系列的指导原则，用来描述哪些软件可以有资格被称为开源软件。

　　Bruce Perens 为制定开源软件的定义做了很多基础性的工作。GNU工程的正式目标之一就是创造一个自由可用的操作系统，以作为平台来运行GNU软件。从软件引导（softwera boottstrapping）的传统观点来看，Linux已经成为那个平台，L inux是在GNU工具的帮助下创造出来的。Perens曾经是Debian工程的领导者，它所管理的Linux发行版本，只包括那些符合GNU精神的软件。Perens已经在“Debian社会契约”（Debian Social Contract）中明确地阐明了这一立场。开源软件的定义是“Debian社会契约”的直接产物，因此开源软件是与GNU的精神一脉相承的。

　　与GPL相比，开源软件的定义允许更大授权自由。特别是当软件中混合了专有软件和开源软件时，开源软件的定义允许在它们的基础上生成更大的混合。

　　结果是，开源软件许可证能令人信服地允许使用和再分开开源软件，而不必考虑补偿或者信用问题。举例来讲，你可以得到伟大的Netscape浏览器的源代码，并且把它作为连同另一个软件（可能是专有软件）一起发布出去，而用不着去通知网景（Netscape）公司。网景为什么会希望如此呢？原因很多，最引人注目的是，这样做可以为他们的客户端代码赢得更大的市场份额。这些代码与他们的商业软件一起工作得的非常好。从这个角度来说，奉送源代码是建立平台的一个很好的方式。这也是网景的人不使用GPL的原因之一。

　　这在社团中可不是小事一桩。1998年下半年，曾经有一场重要的争论对Linux威胁极大，几乎Linux社团破裂。裂痕是因出现了两个软件系统GNOME和KDE而引发的，它们两者都试图建立一个面向对象的桌面界面。一方面，KDE利用了Troll Technology公司的Qt库，其中的一部分属于专有代码，但是很稳定、很成熟。另一方面，GNOME决定使用GTK+库，尽管它不如Qt成熟，但是它是完全自由的库。

　　过去，Troll Technology不得不在使用GPL和维持他们的专有软件立场之间进行选择。GNOME和KDE的裂痕本来会持续下去。然而，在开源软件出现后，虽然Troll仍然控制他们想要的技术，但是Troll可以为希望Qt符合开源软件定义的人改变他们的许可证。Linux社团两个重要部分的裂痕看来要弥合了。

　　开源软件的意义

　　在AMD追赶英特尔的漫漫长途中，一句广为流传的话是这样说的：“AMD的存在，不仅深受AMD客户的拥护，也是英特尔用户的福气，因为它打压了英特尔的高价垄断。”同样，开源软件相对于商业软件也是同样的道理，尤其是对那些具有垄断性质的软件来说，开源软件更显其深远意义。

　　君不见在IBM、Sun等公司推动OpenOffice系统成为业界标准的进逼下，顽固如微软者也不得不把MS Office拿出来充公。显然，随着开源软件的流行，商业软件不仅被压缩了发展空间，同时也促使软件商们不断地降低软件价格，给消费者带来了显而易见的利益。

　　身兼开放源代码应用基金会(OSAF)总裁和主席以及Mozilla基金会主席的Kapor先生就表示，这两个基金会并不是要创建新的杀手程序，而是要利用开源软件的模式削弱微软在网络浏览器和电子邮件软件领域的垄断地位。

　　事实上，对一些发展中国家，或者说那些软件业欠发达国家来说，开源软件还为他们制造了后发优势，提供了追赶和超越发达国家软件业的机会。毕竟，对于像中国这样的发展中国家，软件业的发展严重滞后，完全依靠国内的资金和人才要想赶超像美国这样的软件大国，几乎是没有机会的，充其量只能是一种理想。但是，如果能在基于开源软件的基础上加大投入的话，这种理想就有了实现的可能。

　　 当然，不得不提的是，业界也有人怀疑，开源软件是否会扼杀国内软件人士的努力。就像AMD前段时间向我们提供X86技术一样，有人担心会使国人失去研究龙芯的兴致。还有人认为，像MS Office这样的软件如果都开源的话，那么微软们就不可能再投入大量的资金进行开发和升级，从而也会间接地阻碍软件业的发展。这些言论有一定道理，但开源的意义就是为了挖掘新的产业模式，这种探索精神正是我们世代所鼓励的。

赢利模式是开源软件发展的根本

　　8月3日上午，以火狐(Firefox)浏览器闻名于世的Mozilla基金会，宣布成立一家子公司Mozilla Corporation，以便投入可创造收益的商业活动。作为一家著名的开源软件组织，Mozilla的行为招致大量质疑。人们之所以有这样的反应，就是因为认定开源软件出现的初衷就是免费和开放源代码，Mozilla的行为看起来无疑是违背了二大法条之一的免费。

　　但是，开源软件的免费说至少就目前看来，可能是人们的一种误解。让我们简单地扫描一下当前开源软件的运营模式：第一种，软件完全免费，后续服务收费。像当前的Red Hat Linux就是使用这样的模式。但是，这种模式并不是每一家开源企业都能使用的，也只有像Red Hat这样的行业领先者才有这样的资本。第二种，软件免费，没有售后服务，在软件市场成熟后，靠出售专利谋生。这种方式的代表是Foxmail。第三种，应用服务提供模式。在这种模式下，软件和服务都是免费，企业按时间交纳使用费。最主要的运营模式也就是这几种，其他种类的模式其实都是这几种模式的演化和变种。从中我们可以看出，开源软件本身的确是免费的，但开发者最初的意图其实是为了通过后续服务或出售专利等方式获利。从这个层面来说，天下的确没有免费的误餐。

　　当然，不排除一些真正的免费的开源软件，不过这只能是一些小型的软件。这些软件不需要集中太多人的就能开发出来，后续也不需要太多人的来维护和升级。而对一些大型软件诸如操作系统等，当前不可能成为免费的开源软件。因此说，如果开源软件找不到自己的赢利模式的话，就很难生存下去，更别提发展了。上海中标软件有限公司常务副总经理秦勇就表示，“在中国国内Linux市场上，虽然现在起得很快，但是整个市场容量、整个市场还不够大，还不足以养活号称国内有9家企业的庞大的Linux家族。”这句话背后的潜台词，很显然企业还是要靠Linux赢利的。

　　在笔者看来，开源软件的意义就在意源代码的开源，免费只能说是它的一种说法，并不代表实质性意义。因此说，开源软件企业要想生存和发展下去，肯定得寻找自己的赢利模式。然而，就目前来说，能通过开源软件赢利的太少了，即使像Red Hat这样的业界巨头，2004年才实现2亿美金的营业额，别的企业业绩如何可想而知。

　　事实上，当前无论是国际还是国内的开源软件组织和企业都是少之又少，原因何在，就是因为这些组织和企业没有找到可行的赢利模式，从而没有足够的资金支持企业持续发展下去。

　　高级人才是开源软件发展的瓶颈

　　就像本文开篇时说的那样，国内外开源软件业都存在缺乏高级人才的问题。当前，开源软件业的一致观点就是：人才数量不缺，缺的是质量。实际上这句话更准确地表示应该是：人数不缺，缺的是人才。据业内人士分析，开源软件目前能够想到的赢利模式都是为企业服务的。但是，目前的开源企业总体上规模很小，由几个人到几十人公司都有，然而，大型企业对这样的小企业，包括几百人的软件企业，都会持不信任的态度。Novell中国区市场与渠道总监罗威就表示，在两年前，Novell之所以收购SUSE，一方面当然是业务发展的需要，另一方面其实也有扩大规模的动机。当前，Novell公司在全球已有数千人。Novell通过这种扩张，就是想把非常好的技术放到坚实的企业平台上，两者结合，探索出新的，为企业级支撑提供好的方法的盈利的比较好的道路。

　　然而，开源软件虽然发展几乎与商业软件同步，甚至可以说更早，但其真正以产业的形式问世，不过几十年时间。在这么短的时间里，又受限于规模的制约，不可能培养大批的开源软件人才，而缺乏开源软件人才又进一步制约着开源软件的发展，这就形成了开源软件当前面临的恶性循环。同时，由于开源软件本身的免费，对于刚起步的企业来说，就存在资金的瓶颈，在没有投资者注资的情况下，企业就很难持续提供高薪给企业员工，这实际上也是制约开源软件发展的重要原因。毕竟，高级管理人才是从普通员工培养而来的，没有大批的后备队伍，高级管理人才从何而来啊？

　　就目前来说，虽然开源软件的高级管理人才工资很高，但这只不过是极少数的人，对普通员工来说，工资其实并不高。所以说，从行业的角度分析，开源软件缺的可能不是人才，而是资金。大丈夫何患无妻，开源软件业有钱了又何患无人呢。

    俺们老大总是说一句话，叫“WEB 2.0", 让他很是郁闷的是很多叫不上口，摆不上桌面的网站也叫嚣自己是正宗的web2.0， 就像俺们街口的小贩前面放一个”正宗臭豆腐“ 牌子一样，只是俺写程序出身，从来看不清楚什么叫WEB2.0,或者说web2.0和所谓1.0 有什么不同， 因为按照他们归纳这个WEB2.0 包括博客，社区，等等我看来和CMS没有什么不一样， 后来俺和一个MM讨论社区的时候，发现一个人的思维是有一个定式的，而且你不太可能改变， MM认为BBS和社区不是同一个东西，BBS是需要登陆，注意这个mm她从来都是用TELNET的方式上清华bbs，然后用IE上sohu社区看减肥，在她的思维观念中， 这是两个完全不同的世界，我怎么说，也无法说服她，最后只能放弃，而她男友在旁边幸灾乐祸，估计他早料到这结果，让俺这个傻乎乎的鸡蛋去碰石头。从这个文科MM或者说他们这种文科的思维方式，是形式决定内容的方式。
  
   看来我需要转换一个观点，从形式来看这个WEB2.0, 这些产品的特征都是发的人众多，博客，社区，都是这样，2。0是把写作从一个少数人权力变成全天下都能使用的权力， 就像演戏一样，李亚朋这种视觉的噩梦能让普通人代替，虽然他们未必出彩，但起码能够让俺们怎么看都不会吐。由于这种特征，可见2.0更多的体现的是一种平民参与的意识，就是说在能控制的范围内，你能做以前只有少数所谓精英人群才能做的事情。从这个方面来看，RSS基本不太能算到2.0里面去，他只能算是1.0的扩展表现形式。而博客是淋漓尽至的体现。  并且将一种人群扩大了，就是演员，因为观众越来越多，演员也需要越来越多，从而能够从不同的方面来吸引的越来越多的人来参与。茅台开封是香飘万里，俺们习惯了让人喜欢都是香的，对于臭豆腐，或者怪味豆都理所当然认为不好，却不知道这些东西喜欢的也是众多的， 所以在这里束缚我们发展的，更多的是我们自己的观点。
  
    而2.0的好处就是说你的观点无法约束这些表现形式，他只是一个平台，一个展示的平台，舞的好不好，标准是观众，而不是一个审判台好不好是掌握在少数，或者说一个人手里手里。所以为什么俺们老大不停的说这个WEB2.0, 就是想改变这种公司的网站象审判台感觉，希望更多选择权力能让大众参与，从社区战略， 博客战略，都是这种思维，所以最大的老大提出技术回归也是这个道理，毕竟平台的制作需要的是技术，说的明白一点就是需要一群好工人，搭一个足够大的架子，制作一个规则，然后起码能装下全北京的人，让后让这帮人在里面HAPPY.

     而这个时候，俺发现这个时候，从来都是位于最后面一层的技术开始面对直接面对用户了，以前都是编辑，销售什么的，而技术面对直接用户最大的问题仍然是一个思维方式，就是是技术观点约束我们自己的发展，可见这个时候如此多的人和内容的时候，如何组织就成了一个巨大的问题，就像网路上讨论航空母舰一样，有人说，按照我们造船能力，造一个航母不成问题， 只是如何造和如何管理是一个巨大的问题， 换句话来说，到了2。0时候， 面对海量的内容和观众，这个规则就成了一个巨大的问题，一个大的规则来定义所有的内容和观众，肯定是不行，现在不是文革，个性话需求会越来越多，靠所谓的产品人员来想规则，则仍然回到了1.0的审判台时代，这一小群人来管理控制一个大的不可思亦的东西，就像恐龙头上一个小的可怜的大脑，最后结果当然和恐龙一样，就是绝种，如何让这个身躯庞大的东西运行起来，非需要一个超大智慧不可。 谁能解决这个问题，并且付足于现实，谁就能再次一统江湖
   
     于是就有了web3.0之说，这个很早是俺看的一个哥们提出的： 叫下一代WEB3.0是大家来定义规则，俺当时看的很是云里雾里，就像算命的说俺未来什么样子， 就说一个竭语，什么遇腊而擒， 个人认为又是某个弱智出来混淆视听，而今天看见"雅虎推四种新编程接口 能自行开发网络应用", 突然想到，我靠，那个WEB3.0好像也YAHOO的一个乌龟提出来的， 这个WEB3.0， 我在今年玩魔兽的时候体会很深，这好象不是一个弱智的呓语，而真的是一个可以实现的东西，作为世界游戏的王者，暴雪，从来不缺天才的想法和创意，在星际中，就有地图编辑器，我当时还不明白为什么， 到了魔兽的编辑器出来，发现在魔兽最好玩的地图，都是网友开发出来的，很多地图，如：幻想群侠传，  玩着玩着， 我都很惊诧， 这帮人是怎么想到的， 还有三国系列， 超级金字塔， 真的让人叹为观止， 而这些，我想， 如果说GAME能够这么分，暴雪已经实现了GAME 3.0。

     而web 3.0 也是需要仿照他一样， 就是说我们的程序规则也需要有一个方式让普通人能够参与进来，从而我们不是搭一个台子让这些人进行游戏，而是给这些人工具，让他们帮我们搭一个足够大的世界， 来容纳下足够大的内容和观众，想一下，一个平台能容纳多少人来搭建， WEB1.0时代，我们需要编辑，最多有多少，1000个? 2.0时代，社区每天发贴的人是5－7万，多一点就能上十万，博客甚至能包括象徐进雷这样的名记， 同样，在3.0 时代，我们能够建立建立规则能够让普通网友参与这个平台的建设，就像我们在全世界各地有无数工程师一样， 而且是无数天才的工程师～ ，想想看，普通的写文章，通过平台，就能产生这么大的能量， 号称现代工业社会之魂的工程师协助我们建设这个平台，将是怎样的一种盛况。

   这个YAHOO就走在前面，作为互联网的始坐勇者， 搜索是他最早提出的，却因为没有坚持，这个不知道会怎么样？

1.      软件是在系统里工作的吗？

       NO1. 软件在网络环境下工作

    软件工程40年的尴尬，一直以自我为中心。

2.      需求是软件生命周期中的一个阶段吗？

       NO2. 软件工程向需求工程倾斜

       (软件是服务业)

3.      软件工程是分层结构吗？

       NO3. 软件结构可以用网络拓扑来表示。

       软件最重要的是其交互。

       网络上软件的交互一般有三种：单向消息，双向数据交互，方法调用

4.      软件是强结构好，还是弱结构好？

       NO4. 问题形式化向本体描述方向发展

       体系结构(architecture) 不如 Framework

5. 软件是开发出来的吗？

       NO5. 软件在演化中生长完善。

资源与服务： 资源是所拥有的，服务是用户所需求的。

软件工程和其他工程其实没有什么不同，只是因为软件是无形的，所以更难以测试。

http://citeseer.ist.psu.edu/
http://dblp.uni-trier.de/
http://www.computer.org/portal/site/ieeecs/index.jsp
http://smealsearch2.psu.edu/index.html/
http://portal.acm.org/portal.cfm
http://www.vldb.org/

事业部制最早是由美国通用汽车公司总裁斯隆于1924年提出的，故有“斯隆模型”之称，也叫“联邦分权化”，是一种高度（层）集权下的分权管理体制。它适用于规模庞大，品种繁多，技术复杂的大型企业，是国外较大的联合公司所采用的一种组织形式，近几年我国一些大型企业集团或公司也引进了这种组织结构形式。
事业部制是分级管理 、分级核算、自负盈亏的一种形式，即一个公司按地区或按产品类别分成若干个事业部，从产品的设计，原料采购，成本核算，产品制造，一直到产品销售，均由事业部及所属工厂负责，实行单独核算，独立经营，公司总部只保留人事决策，预算控制和监督大权，并通过利润等指标对事业部进行控制。也有的事业部只负责指挥和组织生产，不负责采购和销售，实行生产和供销分立，但这种事业部正在被产品事业部所取代。还有的事业部则按区域来划分。这里就产品事业部和区域事业部做些简单的介绍。

(1)产品事业部（又称产品部门化）
按照产品或产品系列组织业务活动，在经营多种产品的大型企业中早已显得日益重要。产品部门化主要是以企业所生产的产品为基础，将生产某一产品有关的活动，完全置于同一产品部门内，再在产品部门内细分职能部门，进行生产该产品的工作。这种结构形态，在设计中往往将一些共用的职能集中，由上级委派以辅导各产品部门，做到资源共享。

产品部门化的优点是：
①有利于采用专业化设备，并能使个人的技术和专业化知识得到最大限度的发挥；
②每一个产品部都是一个利润中心，部门经理承担利润责任，这有利于总经理评价各部门的政绩；
③在同一产品部门内有关的职能活动协调比较容易，比完全采用职能部门管理来得更有弹性；
④容易适应企业的扩展与业务多元化要求。
 
产品部门化的缺点是：
①需要更多的具有全面管理才能的人才，而这类人才往往不易得到；
②每一个产品分部都有一定的独立权力，高层管理人员有时会难以控制；
③对总部的各职能部门，例如人事、财务等，产品分部往往不会善加利用，以至总部一些服务不能获得充分的利用。

(2)区域事业部制（又称区域部门化）
对于在地理上分散的企业来说，按地区划分部门是一种比较普遍的方法。其原则是把某个地区或区域内的业务工作集中起来，委派一位经理来主管其事。按地区划分部门，特别适用于规模大的公司，尤其是跨国公司。这种组织结构形态，在设计上往往设有中央服务部门，如采购 、人事、财务、广告等，向各区域提供专业性的服务。

部门化的优点是：
①责任到区域，每一个区域都是一个利润中心，每一区域部门的主管都要负责该地区的业务盈亏；
②放权到区域，每一个区域有其特殊的市场需求与问题，总部放手让区域人员处理，会比较妥善、实际；
③有利于地区内部协调；
④对区域内顾客比较了解，有利于服务与沟通；
⑤每一个区域主管，都要担负一切管理职能的活动，这对培养通才管理人员大有好处。

其缺点是：
①随着地区的增加，需要更多具有全面管理能力的人员，而这类人员往往不易得到；
②每一个区域都是一个相对独立的单位，加上时间，空间上的限制，往往是“天高皇帝远”，总部难以控制；
③由于总部与各区域是天各一方，难以维持集中的经济服务工作。
总体来说，事业部必须具有三个基本要素：即相对独立的市场；相对独立的利益；相对独立的自主权。
事业部制的好处是：总公司领导可以摆脱日常事务，集中精力考虑全局问题；事业部实行独立核算，更能发挥经营管理的积极性，更利于组织专业化生产和实现企业的内部协作；各事业部之间有比较，有竞争，这种比较和竞争有利于企业的发展；事业部内部的供、产、销之间容易协调，不像在直线职能制下需要高层管理部门过问；事业部经理要从事业部整体来考虑问题，这有利于培养和训练管理人才。
事业部的缺点是：公司与事业部的职能机构重叠，构成管理人员浪费；事业部实行独立核算，各事业部只考虑自身的利益，影响事业部之间的协作，一些业务联系与沟通往往也被经济关系所替代。甚至连总部的职能机构为事业部提供决策咨询服务时，也要事业部支付咨询服务费。

矩阵式结构

矩阵式结构的出现是企业管理水平的一次飞跃。当环境一方面要求专业技术知识，另一方面又要求每个产品线能快速做出变化时，就需要矩阵式结构的管理。职能式结构强调纵向的信息沟通，而事业部式结构强调横向的信息流动，矩阵式就是将这两种信息流动在企业内部同时实现。

在实际操作中，这种双重管理的结构建立和维持起来都很困难，因为有权力的一方常常占据支配地位。因此比较成熟的矩阵式管理模式为带有项目／产品小组性质的职能型组织。职能部门照常行使着管理职能，但公司的业务活动是以项目的形式存在的。项目由项目经理全权负责，他向职能经理索要适合的人力资源，在项目期间，这些员工归项目经理管理。而职能经理的责任是保证人力资源合理有效的利用。

与前两种结构不同，矩阵式结构很少能从组织结构图中判断出来，需要根据企业具体的管理行为加以判断。而企业是否应该实行矩阵式管理，应该依据下面三个条件加以判断：

条件一：产品线之间存在着共享希缺资源的压力。该组织通常是中等规模，拥有中等数量的产品线。在不同产品共同灵活地使用人员和设备方面，组织有很大压力。比如，组织并不足够大，不能为每条产品线安排足够的工程师，于是工程师以兼职项目服务的形式被指派承担产品服务。

条件二：环境对两种或更多的重要产品存在要求。例如对技术质量和产品快速更新的要求。这种双重压力意味着在组织的职能和产品之间需要一种权力的平衡。为了保持这种平衡就需要一种双重职权的结构。

条件三：组织所处的环境条件是复杂和不确定的。频繁的外部变化和部门之间的高度依存，要求无论在纵向还是横向方面要有大量的协调与信息处理。

根据上面的条件可以看出，提供咨询服务的公司最适合采用矩阵式结构。例如中型规模的咨询公司，这样的公司规模在几十人至上百人，咨询顾问可以根据业务专业划分为不同的职能团队，例如财务咨询，生产、工程咨询，管理咨询小组。由于咨询顾问的成本较高，优秀的咨询顾问资源相对稀缺，而咨询公司没有统一的产品，需要根据客户的具体情况进行二次设计，每一个项目都是一个全新的产品，无法通过流水线作业完成。而且，产品的质量需要由项目经理和职能经理共同控制。矩阵式的结构能最好的满足以上的条件。

矩阵式结构的优势在于它能使人力、设备等资源在不同的产品／服务之间灵活分配，组织能够适应不断变化的外界要求。这种结构也给员工提供了获得职能和一般管理的两方面技能。在矩阵式组织里，关键组织成员的角色定位非常重要。这些关键组织成员包括：高层领导者、矩阵主管和员工。

　　高层领导者的主要职责是维持职能经理和产品经理之间的权力平衡。高层领导者也必须愿意进行决策委托，鼓励职能经理和产品经理直接接触，共同解决问题，这将有助于信息共享和协调。

矩阵主管的问题在于如何控制他们的下属。由于下属接受两个主管同时领导，不自觉的员工会利用这个机会钻空子，造成主管对他的管理真空化。因此，职能和产品主管必须一起工作，解决问题。职能主管主要解决下属的技术水平问题，而项目主管则具体管下属在这个项目上的行为、工作结果和绩效。这些活动需要大量的时间、沟通、耐心以及和别人共同工作的技巧，这些都是矩阵管理的一部分。

员工接受双重领导，经常能体会到焦虑与压力。他的两个直接经理的命令经常会发生冲突。这时双重主管的员工必须能够面对产品经理和职能经理的指令，形成一个综合决策来确定如何分配他的时间。员工们必须和他的两个主管保持良好关系，他们应该显示出对这两个主管的双重忠诚。

矩阵式结构最早应用于飞机制造和航天器械的生产项目中。职能部门包括研发、工程、安装、测试等等。每一个项目都需要全新的产品，例如新型飞机、宇宙火箭等。现在，矩阵式结构已经在跨国公司里普遍使用，最有代表性的公司要数“世界电器巨人ABB公司。ABB公司全球拥有25万员工，在每一个国家都采取矩阵式结构，将公司按区域和业务维度划分。这样做是为了既保证公司产品的本土化特点，又保证规模效应和技术的领先性。ABB本土的经理负责自行开发新产品，开发市场与政府攻关，而业务经理负责全球的产品战略决策。根据这样的结构，ABB在全球范围成立合资企业，每个合资企业规模都很小（ABB全球有1200个合资公司），但大约1100个合资公司的总经理都同时向区域经理汇报，也向全球业务经理汇报。通过这样的管理，ABB仍然作为一个有整体战略的公司，成为世界电气巨人。通过矩阵式结构，ABB有效地将全球化战略和本地化产品相结合，将跨国公司的规模优势和小公司的灵活、低成本优势相结合，但双重管理需要的沟通难度可想而知。ABB大部分管理文件的内容在描述区域经理和业务经理的职责和相互关系上，并通过不断地培训使经理们明白他们的角色。同时，他们还开发新的信息管理系统，加强信息共享。即便这样，沟通问题现在依然是ABB最迫切解决的问题。 近些年来，IBM、HP等著名的外国企业都采用矩阵式的组织结构。尽管在管理学的教科书上看到过对矩阵组织优劣的探讨，但很难有切身的感受。这次听叶成辉先生谈起自己经历着的IBM公司的矩阵组织，感到获益不浅。

　　1987年，加州伯克利大学电子工程专业出身的叶成辉在美国加入IBM旧金山公司，成为一名程序员。因为不喜欢编程等技术类的工作，梦想着做生意(DOBUSINESS)、当经理(比较喜欢跟人沟通)，他便主动请缨到销售部门去做，经过了差不多5年时间的努力，获得提升，成为一线的经理。随后，叶先生回到IBM香港公司，做产品经理。由于个人“斗志旺盛”，业绩不错，而且“官运亨通”，差不多每两年他都能够蹦一个台阶，如今，叶成辉已经是IBM大中华区服务器系统事业部AS/400产品的总经理。

　　从旧金山到香港，再到广州到北京；从普通员工到一线经理，再提升到现在做三线经理；从一般的产品营销，到逐步专注于服务器产品，再到AS/400产品经理，10多年来，叶成辉一直在IBM的“巨型多维矩阵”中不断移动，不断提升。他认为，IBM的矩阵组织是一个很特别的环境，“在这个矩阵环境中，我学到了很多东西。”IBM是一个巨大的公司，很自然地要划分部门。单一地按照区域地域、业务职能、客户群落、产品或产品系列等来划分部门，在企业里是非常普遍的现象，从前的IBM也不例外。“近七八年以来，IBM才真正做到了矩阵组织。”这也就是说，IBM公司把多种划分部门的方式有机地结合起来，其组织结构形成了“活着的”立体网络--多维矩阵。IBM既按地域分区，如亚太区、中国区、华南区等；又按产品体系划分事业部，如PC、服务器、软件等事业部；既按照银行、电信、中小企业等行业划分；也有销售、渠道、支持等不同的职能划分；等等，所有这些纵横交错的部门划分有机地结合成为一体。对于这个矩阵中的某一位员工比如叶成辉经理而言，他就既是IBM大中华区的一员，又是IBM公司AS/400产品体系中的一员，当然还可以按照另外的标准把他划分在其他的部门里。

　　IBM公司这种矩阵式组织结构带来的好处是什么呢？叶成辉先生认为，非常明显的一点就是，矩阵组织能够弥补对企业进行单一划分带来的不足，把各种企业划分的好处充分发挥出来。显然，如果不对企业进行地域上的细分，比如说只有大中华而没有华南、华东、香港、台湾，就无法针对各地区市场的特点把工作深入下去。而如果只进行地域上的划分，对某一种产品比如AS/400而言，就不会有一个人能够非常了解这个产品在各地表现出来的特点，因为每个地区都会只看重该地区整盘的生意。再比如按照行业划分，就会专门有人来研究各个行业客户对IBM产品的需求，从而更加有效地把握住各种产品的重点市场。

　　“如果没有这样的矩阵结构，我们要想在某个特定市场推广产品，就会变得非常困难。”叶成辉说。比如说在中国市场推广AS/400这个产品吧，由于矩阵式组织结构的存在，我们有华南、华东等各大区的队伍，有金融、电信、中小企业等行业队伍，有市场推广、技术支持等各职能部门的队伍，以及专门的AS/400产品的队伍，大家相互协调、配合，就很容易打开局面。

　　“首先，我作为AS/400产品经理，会比较清楚该产品在当地的策略是什么。在中国，AS/400的客户主要在银行业、保险业，而不像美国主要是在零售业和流通业；在亚太区，AS/400的产品还需要朝低端走，不能只走高端；中国市场上需要AS/400的价位、配置以及每个月需要的数量等，只有产品经理，才能比较清楚。从产品这条线来看，我需要跟美国工厂订货，保证货源供应。从产品销售的角度看，AS/400的产品部门需要各相关地区的职能部门协助，做好促销的活动；然后需要各大区、各行业销售力量把产品销售出去。比如，我需要在媒体上做一些访问，就要当地负责媒体公关的部门协助。再如，我认为“莲花宝箱”(为中国市场量身定制的AS/400)除了主打银行外，还要大力推向中小企业市场，那么就需要跟中国区负责中小企业的行业总经理达成共识。当然，“莲花宝箱”往低端走，还需要分销渠道介入，这时，就需要负责渠道管理的职能部门进行协调。从某种意义上讲，我们之间也互为“客户”关系，我会创造更好的条件让各区、各行业更努力推广AS/400。”叶成辉说。

　　任何事情都有它的“两面性”。矩阵组织在增强企业产品或项目推广能力、市场渗透能力的同时，也存在它固有的弊端。显然，在矩阵组织当中，每个人都有不止一个老板，上上下下需要更多的沟通协调，所以，“IBM的经理开会的时间，沟通的时间，肯定比许多小企业要长，也可能使得决策的过程放慢。”叶成辉进一步强调，“其实，这也不成为问题，因为大多数情况下还是好的，IBM的经理们都知道一个好的决定应该是怎样的。”另外，每一位员工都由不同的老板来评估他的业绩，不再是哪一个人说了算，评估的结果也会更加全面，“每个人都会更加用心去做工作，而不是花心思去讨好老板。”同时运用不同的标准划分企业部门，就会形成矩阵式组织。显然，在这样的组织结构内部，考核员工业绩的办法也无法简单。在特定客户看来，IBM公司只有"唯一客户出口"，所有种类的产品都是一个销售员销售的；产品部门、行业部门花大气力进行产品、客户推广，但是，对于每一笔交易而言，往往又是由其所在区域的IBM员工最后完成；等等。问题是，最后的业绩怎么计算？产品部门算多少贡献，区域、行业部门又分别算多少呢？叶成辉说：“其实，IBM经过多年的探索，早已经解决这个问题了。现在，我们有三层销售--产品、行业和区域，同时，我们也采取三层评估，比如说经过各方共同努力，华南区卖给某银行10套AS/400，那么这个销售额给华南区、AS/400产品部门以及金融行业部门都记上一笔。”当然，无论从哪一个层面来看，其总和都是一致的。比如从大中华区周伟锟的立场来看，下面各分区业绩的总和，大中华区全部行业销售总额，或者大中华区全部产品(服务)销售总额，三个数字是一样的，都可以说明他的业绩。

　　在外界看来，IBM这架巨大的战车是稳步前进的，变化非常缓慢。叶成辉认为，这其实是一种误会。对于基层的员工，对于比较高层的经理，这两头的变化相对比较小，比较稳定。比如说一名普通员工进入IBM，做AS/400的销售，差不多四五年时间都不会变化，然后，可能有机会升任一线经理。再比如亚太区的总经理，也可能好多年不变，因为熟悉这么大区域的业务，建立起很好的客户关系，也不太容易。所以，外界就觉得IBM变动缓慢。“但是，在IBM矩阵内部的变化还是很快的。中间层的经理人员差不多一两年就要变化工作，或者变化老板，变化下属，这样就促使整个组织不断地创新，不断地向前发展。”叶成辉说，“我在IBM公司10多年，换了10多位老板。每一位老板都有不同的长处，从他们那里我学到了很多。其实，IBM的每一位员工都会有这样的幸运。”矩阵组织结构是有机的，既能够保证稳定地发展，又能保证组织内部的变化和创新。所以，IBM公司常常流传着一句话：换了谁也无所谓。

07年已经是陈皓在程序员行业里的第十个年头了。总结这十年，毕业的头两年，陈皓在银行中昏昏沉沉中度过，“这是我最失败的时候，两年的时间几乎完全白费了。”后来在上海的两年，我拼命地学习看书，并不断总结所做的项目，这个阶段是我补课的阶段，也是我量变的阶段。到了北京的这五年，是我从量变向质变转换的阶段。

拼命看书

刚毕业的时候，陈皓也像很多刚毕业的学生一样，根本没有对自己的职业进行过比较好的规划。“还记得当时什么都没有想，就是想做一些实际的事情，好好的钻研一些技术。实在没有别的什么想法。”在毕业头三年中（1998年到2001年），不要说是对未来的职业有所规划，对所学的技术也是毫无规划。

离开银行后到上海加入了一家专做银行的系统集成的公司，发现自己和别人的差距非常的大，所以开始拼命地看书和学习，在到上海的头一年中，看了四、五十本书，研究的技术包括PB, delphi, SQL, HTML, CSS, DHTML, java, Perl, CGI, ASP, PHP, JSP, XML, UML, MFC, Lotus Notes, Unix, Oracle, Informix, C++, ActiveX, ODBC, ADO, .NET, COM, 乃至CISCO路由器的配置，Photoshop, 3DMAX……陈皓学得很杂很泛，完全没有目的，只是觉得别人懂的自己也要懂。

“看了许多许多的书，完全没有好好想想自己应该走什么方向。现在回头看来也不知道是好还是不好。”

也许是看的书太多，懂的东西太多，后来有机会参与了一次全国性质的项目。后台是AIX+Informix用C开发，前台是用PB的PFC做界面，通过IBM的CICS这个中间件连通前后台。在开发这个项目的一年时间里，陈皓对Unix/C/C++以及分布式系统有了非常深刻地认识，并深深地迷上了它们，同时对大型软件工程的流程和管理有了非常深刻的了解。

这个项目对陈皓的影响非常大，除了技术上的收获之外，更让陈皓逐渐确定了自己的规划。

技术之外

2002年底，北京一家做分布式计算/网格计算平台的加拿大公司对我产生了兴趣，经过5轮面试陈皓拿到了offer，又一次开始了我的奔走——从上海来到了北京。

新的公司让陈皓的Unix/C/C++得到了非常大的巩固，“这个公司也让我这个土狼学到了很多很多，特别是认识和观念上。”特别是在带领一个team对公司欧洲用户做Customer Service方面的工作时，陈皓学到了很多客户管理的知识，英语能力、与人沟通的能力以及对软件的认识得到了完全的升华。

陈皓开始使用一种和以前完全不一样的方法去思考问题——从用户的角度对问题进行思考。“此时，技术方向对我来说已不重要，技术对我来说已经变得非常简单，因为技术只需要看书看文档就可以获取。”陈皓开始用全新的方式思考如何管理一个团队，如何制造一个成功的软件，如何管理客户。并由此有了更进一步的职业规则——成为一个成功的技术主管、建立一个成功的团队、开发一个成功的软件产品。

给新人程序员的八点建议

走过弯路，有过迷茫，回首九年陈皓感慨万千。“今天，我对许多刚上路的朋友都会说，人生的规则很重要，从上大学时就要好好规划。”他结合自身经历，对许多刚踏入程序员行列的新人程序员，他给出了以下八点建议：

1.在大学的时候尽量多地进入公司参与实际工作，一方面积累工作经验，另一方面，提前认识工作和自己，以便毕业时更准确地把握自己的方向。

2.从毕业开始到毕业后至少5年内，踏踏实实地专研技术，这是一个积累过程，千万不要把心思放在钱和职位上。钱和职位只是能力的附属品，不要让其喧宾夺主。

3.从毕业后3年到7年的时间，注意学习工作当中的方法以及相关的管理和流程，不但要知其然，还要知其所以然。

4.30岁以前，踏踏实实地学习。学技术，学做人，学做事。30岁以后再谈自己的发展。

5.毕业后的前5年主要是量的积累，要不停地积累知识和方法。毕业后的5到10年主要是质变，应该着重于思维和想法的更新。后五年应该有很强的包容能力和接受新东西的能力，千万不要太过固执和坚持自己的想法。

6.换工作要“承前启后”，前面的工作会成为后面工作的一个基础，而后面的工作又会成为前面工作的一个很自然的延续。

7.不要只把心思放在技术上，技术是hard skill，只要下工夫就一定会掌握。更要注意与人沟通等为人处事的soft skill上。hard skill像一个大树的根，而soft skill则像一个大树的枝叶。树根是你的根基，能让你站得很稳，而枝叶能让你向天空伸展，获得发展。

8.对于程序员来说，应该始终记住，技术不是主要的，主要的是通过技术能够解决什么样的问题。一定经常想要解决什么的问题，要满足什么样的需求，而不是要用什么样的技术

期刊名称                                         影响因子

计算机学报        　　                        0.921
软件学报        　　　　　        　  0.919
计算机集成制造系统一CIMS         0.855
计算机研究与发展                             0.806
计算机辅助设计与图形学学报        0.692
中文信息学报　                               0.635
中国图象图形学报                          0.616
计算机应用研究                       0.428
计算机测量与控制                0.406
模式识别与人工智能             0.39
计算机与应用化学                0.388
J COMPUT SCI＆TECH          0.33
计算机应用              0.329
计算机工程与应用                0.28
计算机科学　           0.28
小型微型计算机系统             0.275
物探化探计算技术        0.239
计算机工程与科学　　　　　 0.234
计算机工程　                            0.232
计算机仿真                            0.206
计算机工程与设计        0.203
微型电脑应用　　        0.134
数值计算与计算机应用          0.123
计算机辅助工程                   0.098
微型机与应用                0.096
微计算机应用                            0.034

国内计算机类学术期刊投稿指南

计算机科学与技术 英文版: 《Journal of Computer Science and Technology》 （双月刊）   
  SCI-E源期刊，中文重要期刊，EI Compendex源期刊，中文核心期刊
主办单位：中国科学院计算技术研究所
地址：北京2704信箱
邮编：100080
邮发代号：2-578
E-mail: jcst@ict.ac.cn 
          jcst@ns.ict.ac.cn 
http://jcst.ict.ac.cn/
 
 

.

《计算机学报》(Chinese Journal of Computers) （月刊）
  中文重要期刊，EI Compendex源期刊，中文核心期刊
主办单位：中国计算机学会 中国科学院计算技术研究所
地址：北京2704信箱 中国科学院计算技术研究所 《计算机学报》编辑部
邮编：100080
邮发代号：2-833
E-mail: cjc@ict.ac.cn
http://www.ict.ac.cn/cjc/cjc.html 
  
 

《软件学报》(Journal of Software) （月刊）  
  中文重要期刊，EI Compendex源期刊，中文核心期刊
主办单位：中国计算机学会 中国科学院软件研究所
地址：北京8718信箱 北京海淀区中关村《软件学报》编辑委员会
邮编：100080
邮发代号：82-367
E-mail:jos@iscas.ac.cn
http://www.jos.org.cn/
  
 

《计算机研究与发展》 (Journal of Computer Research and Development)（月刊）  
  中文重要期刊，EI Compendex源期刊，中文核心期刊
主办单位：中国科学院计算技术研究所 中国计算机学会
地址：北京2704信箱 中国科学院计算技术研究所 《计算机研究与发展》 编辑委员会
邮编：100080
邮发代号：2-654
 E-mail: crad@ict.ac.cn
http://crad.ict.ac.cn/ 
 

《电子学报》（中文版）（Acta Electronica Sinica）（月刊）
    电子学报  英文版：《Chinese Journal of Electronics》（双月刊）
   SCI-E检索源期刊，中文重要期刊，EI Compendex源期刊，中文核心期刊
通信地址: 北京165信箱          邮政编码: 100036
电话: 86-10-68279116,   86-10-68285082
传真: 86-10-68173796
E-mail: cje@elecjournal.org
http://www.elecjournal.org/
 
 

《自动化学报》 （双月刊）
    中文重要期刊，EI Compendex源期刊，中文核心期刊
 期刊外文名： 　 Acta Automatica Sinica 
创办日期： 　 1963.01.01 
主办单位： 　 中国自动化学会、中国科学院自动化所
编辑部通信地址： 　 北京市中关村东路95号中科院自动化研究所 
邮政编码： 　 100080
联系电话： 　 (010) 82614566 
编辑部E-mail： 　 aas@mail.ia.ac.cn 
网  址： 　 http://www.aas.net.cn/ 
国内邮发代号： 　 2-180 
出版日期： 　 单月20日 

电话：010-62565763（日常咨询和稿件处理）010-82614566（录用后稿件处理）
传真：010-82614571
编辑部办公时间：上午：8:00-12:00 下午：13:30-17:30 (法定节假日休息)
 
 
 

《计算机工程 》（Computer Engineering）（半月刊）
   EI 源期刊，中文核心期刊
主办单位：华东计算技术研究所 上海市计算机学会
地址：上海市漕河泾桂林路418号 《计算机工程》编辑部
邮编：200233
电话：（021）54972331 , 64704678-10341
邮发代号：4-310
 E-mail: hdsce@china.com
 http://www.ecice06.com/ 
 

《电子与信息学报》（中文版）（月刊）
    电子与信息学报  英文版：《Journal of Electronics》 （季刊）
 中文重要期刊，EI Compendex源期刊，中文核心期刊
原刊名：电子科学学刊
地址：北京市北四环西路19号
通信：北京2702信箱《电子与信息学报》编辑部
电话：010-62551772
投送中英文修改稿件 Email：wbzhou@mail.ie.ac.cn
查询稿件E-mail邮箱：
        中文稿件查询 Email：ywwu@mail.ie.ac.cn
        英文稿件查询 Email: gliu@mail.ie.ac.cn
http://journaleit.ie.ac.cn/
 
 

《信息与控制》（Information and Control）（双月刊）
  中文重要期刊，EI Compendex源期刊，中文核心期刊
地址：辽宁沈阳市三好街90号（中科院沈阳自动化所） 　　邮编：110003
电话：（024）23893591-2455
网址：http://xxbjb.gongkong.com/
Email：xxbjb@gongkong.com
  
 

《控制理论与应用》（双月刊）（Control Theory & Applications）
    控制理论与应用  英文版：《Journal of Control Theory and Applications》
   中文重要期刊，EI Compendex源期刊，中文核心期刊
主办单位：华南理工大学
地　　址：广州市五山华南理工大学内
邮政编码：510640
电　　话：020-87111464
传　　真：020-87111464
电子邮件：aukzllyy@scut.edu.cn
 
 

 
《控制与决策》 （Control and Decision）（月刊）
   中文重要期刊，EI Compendex源期刊，中文核心期刊
地址：沈阳市和平区文化路3号巷11号东北大学125信箱
邮编：110004
电话：024-23906437，83687766
Email：kzyjc@mail.neu.edu.cn
http://www.kzyjc.net/
  
 

《系统仿真学报》（JOURNAL OF SYSTEM SIMULATION）（半月刊）
   中文重要期刊，EI Compendex源期刊，中文核心期刊
编辑部电话：010-88527147
主任办电话：010-68388709
通信地址：北京142信箱13分箱        邮编：100854
电子邮件：simu-xb@vip.sina.com
http://www.china-simulation.com/ 
  
 
《模试识别与人工智能》 （季刊） ISTIC收录
   中文重要期刊，EI Compendex源期刊，中文核心期刊
主办单位：中国自动化学会 国家智能计算机研究开发中心
地址：合肥1130信箱 中国科学院合肥智能机械研究所 《模式识别与人工智能》编辑部
邮编：230031
邮发代号：26-69
E-mail:bjb@mail.iim.ac.cn 
  
 

《计算机科学》（Computer Science）（月刊） 
    中文核心期刊
主办单位：国家科技部西南信息中心

地址：重庆市渝中区胜利路132号 《计算机科学》杂志社
邮编：400013
E-mail:  jsjkx@swic.ac.cn

通信地址：重庆市北部新区洪湖西路18号重庆天旭科技信息有限公司 《计算机科学》杂志社
邮政编码：401121
邮发代号：78-68
电话： (023) 63500828 ddd67039612 dd67039625
传真： (023) 63500828
E-mail ： jsjkx12@163.com
 http://www.jsjkx.com/
 
 
 

《系统工程理论与实践》（月刊）
  中文重要期刊，EI Compendex源期刊，中文核心期刊
地址：北京中关村东路55号    邮编：100080　
电话: 010-62541828　
Email: xtll@chinajournal.net.cn
http://www.sysengi.com/
 

《系统工程学报》（Journal of Systems Engineering ）（双月刊）
   中文重要期刊，EI Compendex源期刊，中文核心期刊
主办单位：中国系统工程学会
地　　址：天津市津卫路92号天津大学18教学楼411室
邮政编码：300072
电　　话：022-27403197
传　　真：022-27403197
电子邮件：jsetju@263.net   zowang@tju.edu.cn
 

《系统工程与电子技术》（Systems Engineering and Electronics）（月刊）
    系统工程与电子技术  英文版：《Journal of Systems Engineering and Electronics》（季刊）
    EI Compendex源期刊，中文核心期刊
主办单位：中国航天科工集团公司二院 中国宇航学会 中国系统工程学会
地址：北京142信箱32分箱
邮编：100854
电话：010-68388406
传　　真：010-68388406
电子邮件：xtydz@126.com
 

《小型微型计算机系统》（Mini-Micro Systems） （月刊）
     中文核心期刊
主办单位：中科院沈阳计算技术研究所
地址：沈阳市和平区三好街100号 中科院沈阳计算技术研究所 《小型微型计算机系统》编辑部
邮编：110004
邮发代号：8-108
电话:  024-23892547
E-mail: xwjxt@sict.ac.cn
http://www.sict.ac.cn/
 

《数值计算与计算机应用》（Journal on Numerical Methods and Computer Applications） （季刊）
   中文核心期刊，ISTIC收录
主办单位：中国科学院计算数学与科学工程计算研究所
地址：北京市2719信箱 《数值计算与计算机应用》编辑部
邮编：100080
邮发代号：2-413
E-mail:SZJS@chinajournal.net.cn
http://www.chinainfo.gov.cn/periodical 
 

《计算机工程与应用》（Computer Engineering and Applications） （旬刊）
  中文核心期刊，ISTIC收录
主办单位：华北计算技术研究所
地址：北京市北四环中路211号 北京619信箱26分箱《计算机工程与应用》杂志社
邮编：100083
邮发代号：82-605
电话：010-51615542
投稿信箱：tjit@public2.bat.net.cn
              cea@163bj.com
 http://www.ceaj.org/
 

《计算机应用研究》（Application Research Of Computers） （月刊）
  中文核心期刊， ISTIC收录
主办单位：四川省电子计算机应用研究中心
通讯地址：成都市成科西路3号 《计算机应用研究》编辑部            邮编：610041
邮发代号：62-68
编辑部电话：028-85249567       电话: 028-85210177，85221946
 E-mail: srcca@sichuan.net.cn;  arocmag@163.com
 http://www.arocmag.com/
 

《中文信息学报》 （双月刊）
    中文核心期刊，ISTIC收录
主办单位：中国科学院软件研究所 中国中文信息学会
地址：北京8718信箱 《中文信息学报》编辑部
邮编：100080
  E-mail:cips@admin.iscas.ac.cn
 

《计算机应用》（Computer Appliocations） （月刊） 
  中文核心期刊，ISTIC收录
主办单位：中科院成都计算机应用研究所 四川省计算机学会
地址：成都市人民南路四段九号 成都237信箱《计算机应用》编辑部
邮编：610041
编辑部地址：成都市237信箱 《计算机应用》编辑部　　邮编：610041
邮发代号：62-110
电话：（028）85224283-601
传真：（028）85222239
E-mail:bjb@computerapplications.com.cn  
http://www.computerapplications.com.cn/
 

《计算机辅助设计与图形学学报》（Journal of Computer-Aided Design & Computer Graphics） （月刊）
   中文核心期刊，ISTIC收录
主办单位：中国计算机学会
地址：北京2704信箱 中国科学院计算技术研究所
邮编：100080
邮发代号：82-456
  E-mail: jcad@ict.ac.cn 
  E-mail: jcad@ns.ict.ac.cn
  http://jcad.ict.ac.cn/
 

《计算机工程与设计》（Computer Engineering and Design） （月刊）
    中文核心期刊
主办单位：中国航天科工集团二院706所
地址：北京142信箱406分箱 《计算机工程与设计》编辑部
邮编：100854
邮发代号：82-425
 E-mail: ced@httx.com.cn 
 http://www.china-ced.com/
 

 微电子学与计算机（Microellectronics & Computer）（月刊）
    中文核心期刊
主办单位：中国航天科技集团公司西安微电子技术研究所
地址：西安市81号信箱 《 微电子学与计算机》编辑部
邮编：710054
邮发代号：52-16
电　　话：029-82262687
传　　真：029-82262771
电子邮件：mc771@163.com
 

计算机仿真（Computer Simulation） （月刊）
   中文核心期刊
主办单位：中国航天科工集团公司第十七研究所
地　　址：北京海淀阜成路14号
邮政编码：100037
电　　话：010-68767186
传　　真：010-68373574
电子邮件：kwcoltd@public.bta.net.cn    jsjfz@compusimu.com
  http://www.compusimu.com/
 

 计算机应用与软件 （Computer Applications and Software）（月刊）
  中文核心期刊
主办单位：上海市计算技术研究所 上海计算机软件技术开发中心
地　　址：上海市愚园路546号《计算机应用与软件》编辑部
邮政编码：200040
电　　话：021-62520070-505
传　　真：021-62254715
电子邮件：cas@sict.stc.sh.cn
 

微计算机信息（CONTROL & AUTOMATION）（旬刊）
  中文核心期刊
主办单位: 中国计算机用户协会自动控制分会
通信地址: 北京海淀区皂君庙14号鑫雅苑6号楼601室     邮编:100081
电话: 010-62192616，62132436
在线投稿：http://www.autocontrol.com.cn/
 

微型机与应用（Microcomputer & Its Applications）（月刊）
  中文核心期刊

创办日期： 　 1982.01.01 
主办单位： 　 信息产业部电子第六研究所
编辑部通信地址： 　 北京市海淀区清华东路25号(927信箱) 
邮政编码： 　 100083
联系电话： 　 (010)82306084    65157887
传 真：   010-65157886
编辑部E-mail： 　 pcapps@infopo.lshs.ac.cn    pca@ncse.com.cn 
国内邮发代号： 　 82-417 

微型计算机（半月刊）
  中文核心期刊
主办单位：科技部西南信息中心
创刊日期：1980.8
出刊日期：每月1日、15日
 

数据采集与处理（Journal of Data Acquisition ＆ Processing）（月刊）
  EI统计源期刊，中文核心期刊
主办单位: 南京航空航天大学. 信号处理学会.微弱信号检测学会
地址：南京市御道街29号(南京航空航天大学内)
邮编：210016
电话：025-84892742, 84892744
电话：025-4492492-2726
传真：025-4494880
电报挂号：南京市3057
 

中国图象图形学报（Journal of Image and Graphics）（月刊）
 中文核心期刊
主办单位：中国科学院遥感应用研究所、中国图象图形学学会 、北京应用物理与计算数学研究所
地　　址：北京海淀中关村东路95号（北京2728信箱） 
邮政编码：100080
电　　话：010-82614429
传　　真：010-82614429
Email：jig@irsa.ac.cn
http://www.cjig.cn/
 

机器人（Robot）（双月刊）
EI统计源期刊，中文核心期刊
主办单位：中国科学院沈阳自动化研究所
邮政编码：110003
地　　址：沈阳市南塔街114号
邮政编码：110016
电　　话：024-23970050
电子邮件：qr@sia.cn
http://robot.sia.cn/
http://www.robotschina.com/
 

计算机集成制造系统（Computer Integrated Manufacturing Systems）
EI统计源期刊，中文核心期刊
通信地址：北京市2413信箱34分箱（100089）
电  话：（010）68962468
传  真：（010）68962468
E-mail： Bamt@onet.com.cn
http://www.amtech.org.cn/
 

航空计算技术（Aeronautical Computer Technique）（季刊）  ISTIC收录
 

创办日期： 　 1971.01.01 
主办单位： 　 中国航空工业第六三一研究所
编辑部通信地址： 　 陕西省西安市太白南路(西安90信箱) 
邮政编码： 　 710068
联系电话： 　 029-88151098 
编辑部E-mail： 　 act631@163.com 
国内统一刊号： 　 61-1276/TP 
国际标准刊号： 　 1671-654X 
国内邮发代号： 　 52-79 
出版日期： 　 季末月30日 

微计算机应用 （Microcomputer Applications）
  中文核心期刊
  主办单位： 中国科学院声学研究所 
  编辑出版 ：《微计算机应用》编辑部
  地址： 海淀区北四环西路21号     邮编：100080
  E--mail：  weiji@dsp.ac.cn
  电    话：  010-62554573
  国内总发行： 北京市邮政局
  订购 处：全国各地邮局
  国内统一刊号：CN11-2204/TP  
  国内邮发代号：2-304
  国外发行代号：BM5550
 

电光与控制（Electronics Optics & Control）（双月刊）
  中文核心期刊
  主办单位：中国航空工业洛阳电光设备研究所
  通讯地址：河南洛阳017信箱16分箱《电光与控制》编辑部　    　　　邮编：471009
  电话：0379－63327293      传真：0379－63938146
  E-mail：eoei@public2.lyptt.ha.cn
             eoei@vip.sina.com　　
  Website: http://dgkq.chinajournal.net.cn
 

《计算机工程与科学》（Computer Engineering and Science） （双月刊）
   ISTIC收录
主办单位：国防科技大学计算机学院
地址：湖南长沙砚瓦池正街47号 《计算机工程与科学》编辑部
邮编：410073
邮发代号：42-153
E-mail：cchunxi@163.net
 

电子计算机与外部设备（Computer & Peripherals）      E-mail: OK HOPE@mail.hz.zj.cn

计算机辅助工程（Computer Aided Engineering）            E-mail: smucad@163.net

计算机与现代化（Computer and Modernization）           E-mail: jict@public.nc.ix.cn

计算机与应用化学 Computers and Applied Chemistry

计算机自动测量与控制 Computer Automated Measurement & Control

微型电脑应用

计算机技术与发展

机器人技术与应用

说明：检索系统摘引情况选定如下系统：

SCI (科学引文索引)
中文重要期刊（研究生教育与学位重要期刊）
EI(工程索引)
中文核心期刊
ISTIC (中国科技期刊引证报告统计源期刊)
未注明者为非统计源期刊。