语源科技BlogJava-zhb8015

版本代码扫盲

zhb8015 — Fri, 01 Mar 2013 06:05:00 GMT

Alpha：是内部测试版,一般不向外部发布,会有很多Bug.一般只有测试人员使用。

Beta：也是测试版，这个阶段的版本会一直加入新的功能。在Alpha版之后推出。

RC：(Release　Candidate) 顾名思义么 ! 用在软件上就是候选版本。系统平台上就是发行候选版本。RC版不会再加入新的功能了，主要着重于除错。

GA:General Availability,正式发布的版本，在国外都是用GA来说明release版本的。

RTM：(Release to Manufacture)是给工厂大量压片的版本，内容跟正式版是一样的，不过RTM版也有出限制、评估版的。但是和正式版本的主要程序代码都是一样的。

OEM：是给计算机厂商随着计算机贩卖的，也就是随机版。只能随机器出货，不能零售。只能全新安装，不能从旧有操作系统升级。包装不像零售版精美，通常只有一面CD和说明书(授权书)。

RVL：号称是正式版，其实RVL根本不是版本的名称。它是中文版/英文版文档破解出来的。

EVAL：而流通在网络上的EVAL版，与“评估版”类似，功能上和零售版没有区别。

RTL：Retail(零售版)是真正的正式版，正式上架零售版。在安装盘的i386文件夹里有一个eula.txt，最后有一行EULAID，就是你的版本。比如简体中文正式版是EULAID:WX.4_PRO_RTL_CN，繁体中文正式版是WX.4_PRO_RTL_TW。其中：如果是WX.开头是正式版，WB.开头是测试版。_PRE，代表家庭版；_PRO，代表专业版。

α、β、λ常用来表示软件测试过程中的三个阶段，α是第一阶段，一般只供内部测试使用；β是第二个阶段，已经消除了软件中大部分的不完善之处，但仍有可能还存在缺陷和漏洞，一般只提供给特定的用户群来测试使用；λ是第三个阶段，此时产品已经相当成熟，只需在个别地方再做进一步的优化处理即可上市发行。

zhb8015 2013-03-01 14:05 发表评论

how to write psedocode(reprint)

zhb8015 — Wed, 24 Oct 2012 10:16:00 GMT

PSEUDOCODE STANDARD

original:

http://users.csc.calpoly.edu/~jdalbey/SWE/pdl_std.html

Pseudocode is a kind of structured english for describing algorithms. It allows the designer to focus on the logic of the algorithm without being distracted by details of language syntax. At the same time, the pseudocode needs to be complete. It describe the entire logic of the algorithm so that implementation becomes a rote mechanical task of translating line by line into source code.

In general the vocabulary used in the pseudocode should be the vocabulary of the problem domain, not of the implementation domain. The pseudocode is a narrative for someone who knows the requirements (problem domain) and is trying to learn how the solution is organized. E.g.,

Extract the next word from the line (good)
set word to get next token (poor)
Append the file extension to the name (good)
name = name + extension (poor)

FOR all the characters in the name (good)
FOR character = first to last (ok)

Note that the logic must be decomposed to the level of a single loop or decision. Thus "Search the list and find the customer with highest balance" is too vague because it takes a loop AND a nested decision to implement it. It's okay to use "Find" or "Lookup" if there's a predefined function for it such as String.indexOf().

Each textbook and each individual designer may have their own personal style of pseudocode. Pseudocode is not a rigorous notation, since it is read by other people, not by the computer. There is no universal "standard" for the industry, but for instructional purposes it is helpful if we all follow a similar style. The format below is recommended for expressing your solutions in our class.

The "structured" part of pseudocode is a notation for representing six specific structured programming constructs: SEQUENCE, WHILE, IF-THEN-ELSE, REPEAT-UNTIL, FOR, and CASE. Each of these constructs can be embedded inside any other construct. These constructs represent the logic, or flow of control in an algorithm.

It has been proven that three basic constructs for flow of control are sufficient to implement any "proper" algorithm.

SEQUENCE is a linear progression where one task is performed sequentially after another.
WHILE is a loop (repetition) with a simple conditional test at its beginning.
IF-THEN-ELSE is a decision (selection) in which a choice is made between two alternative courses of action.

Although these constructs are sufficient, it is often useful to include three more constructs:

REPEAT-UNTIL is a loop with a simple conditional test at the bottom.
CASE is a multiway branch (decision) based on the value of an expression. CASE is a generalization of IF-THEN-ELSE.
FOR is a "counting" loop.

SEQUENCE

Sequential control is indicated by writing one action after another, each action on a line by itself, and all actions aligned with the same indent. The actions are performed in the sequence (top to bottom) that they are written.

Example (non-computer)

Brush teeth
Wash face
Comb hair
Smile in mirror

Example

READ height of rectangle
READ width of rectangle
COMPUTE area as height times width

Common Action Keywords

Several keywords are often used to indicate common input, output, and processing operations.
Input: READ, OBTAIN, GET
Output: PRINT, DISPLAY, SHOW
Compute: COMPUTE, CALCULATE, DETERMINE
Initialize: SET, INIT
Add one: INCREMENT, BUMP

IF-THEN-ELSE

Binary choice on a given Boolean condition is indicated by the use of four keywords: IF, THEN, ELSE, and ENDIF. The general form is:

IF condition THEN
sequence 1
ELSE
sequence 2
ENDIF

The ELSE keyword and "sequence 2" are optional. If the condition is true, sequence 1 is performed, otherwise sequence 2 is performed.

Example

IF HoursWorked > NormalMax THEN
Display overtime message
ELSE
Display regular time message
ENDIF

WHILE

The WHILE construct is used to specify a loop with a test at the top. The beginning and ending of the loop are indicated by two keywords WHILE and ENDWHILE. The general form is:

WHILE condition
sequence
ENDWHILE

The loop is entered only if the condition is true. The "sequence" is performed for each iteration. At the conclusion of each iteration, the condition is evaluated and the loop continues as long as the condition is true.

Example

WHILE Population < Limit
Compute Population as Population + Births - Deaths
ENDWHILE

Example

WHILE employee.type NOT EQUAL manager AND personCount < numEmployees
INCREMENT personCount CALL employeeList.getPerson with personCount RETURNING employee
ENDWHILE

CASE

A CASE construct indicates a multiway branch based on conditions that are mutually exclusive. Four keywords, CASE, OF, OTHERS, and ENDCASE, and conditions are used to indicate the various alternatives. The general form is:

CASE expression OF
condition 1 : sequence 1
condition 2 : sequence 2
...
condition n : sequence n
OTHERS:
default sequence
ENDCASE
The OTHERS clause with its default sequence is optional. Conditions are normally numbers or characters

indicating the value of "expression", but they can be English statements or some other notation that specifies the condition under which the given sequence is to be performed. A certain sequence may be associated with more than one condition.

Example

        CASE  Title  OF
                Mr      : Print "Mister"
                Mrs     : Print "Missus"
                Miss    : Print "Miss"
                Ms      : Print "Mizz"
                Dr      : Print "Doctor"
        ENDCASE

Example

        CASE  grade  OF
                A       : points = 4
                B       : points = 3
                C       : points = 2
                D       : points = 1
                F       : points = 0
        ENDCASE

REPEAT-UNTIL

This loop is similar to the WHILE loop except that the test is performed at the bottom of the loop instead of at the top. Two keywords, REPEAT and UNTIL are used. The general form is:

REPEAT
sequence
UNTIL condition

The "sequence" in this type of loop is always performed at least once, because the test is peformed after the sequence is executed. At the conclusion of each iteration, the condition is evaluated, and the loop repeats if the condition is false. The loop terminates when the condition becomes true.

FOR

This loop is a specialized construct for iterating a specific number of times, often called a "counting" loop. Two keywords, FOR and ENDFOR are used. The general form is:

FOR iteration bounds
sequence
ENDFOR

In cases where the loop constraints can be obviously inferred it is best to describe the loop using problem domain vocabulary.

Example

FOR each month of the year (good)
FOR month = 1 to 12 (ok)
FOR each employee in the list (good)
FOR empno = 1 to listsize (ok)

NESTED CONSTRUCTS

The constructs can be embedded within each other, and this is made clear by use of indenting. Nested constructs should be clearly indented from their surrounding constructs.

Example

SET total to zero
REPEAT
READ Temperature
IF Temperature > Freezing THEN
INCREMENT total
END IF
UNTIL Temperature < zero
Print total

In the above example, the IF construct is nested within the REPEAT construct, and therefore is indented.

INVOKING SUBPROCEDURES

Use the CALL keyword. For example:

CALL AvgAge with StudentAges
CALL Swap with CurrentItem and TargetItem
CALL Account.debit with CheckAmount
CALL getBalance RETURNING aBalance
CALL SquareRoot with orbitHeight RETURNING nominalOrbit

EXCEPTION HANDLING

    BEGIN
        statements
    EXCEPTION
        WHEN exception type
            statements to handle exception
        WHEN another exception type
            statements to handle exception
    END

Sample Pseudocode

"Adequate"

FOR X = 1 to 10
    FOR Y = 1 to 10
        IF gameBoard[X][Y] = 0
            Do nothing
        ELSE
            CALL theCall(X, Y) (recursive method)
            increment counter
        END IF
    END FOR
END FOR

"Better"

Set moveCount to 1
FOR each row on the board
    FOR each column on the board
        IF gameBoard position (row, column) is occupied THEN
            CALL findAdjacentTiles with row, column
            INCREMENT moveCount
        END IF
    END FOR
END FOR

(Note: the logic is restructured to omit the "do nothing" clause)

"Not So Good"

FOR all the number at the back of the array
    SET Temp equal the addition of each number
    IF > 9 THEN
        get the remainder of the number divided by 10 to that index
        and carry the "1"
    Decrement one
Do it again for numbers before the decimal

"Good Enough (not perfect)"

SET Carry to 0
FOR each DigitPosition in Number from least significant to most significant

COMPUTE Total as sum of FirstNum[DigitPosition] and SecondNum[DigitPosition] and Carry

    IF Total > 10 THEN
        SET Carry to 1
        SUBTRACT 10 from Total
    ELSE
        SET Carry to 0
    END IF

STORE Total in Result[DigitPosition]

END LOOP

IF Carry = 1 THEN
RAISE Overflow exception
END IF

"Pretty Good" This example shows how pseudocode is written as comments in the source file. Note that the double slashes are indented.

public boolean moveRobot (Robot aRobot)
{
    //IF robot has no obstacle in front THEN
        // Call Move robot
        // Add the move command to the command history
        // RETURN true
    //ELSE
        // RETURN false without moving the robot
    //END IF
}

Example Java Implementation

source code statements are interleaved with pseudocode.
comments that correspond exactly to source code are removed during coding.

public boolean moveRobot (Robot aRobot)
{
    //IF robot has no obstacle in front THEN
    if (aRobot.isFrontClear())
    {
        // Call Move robot
        aRobot.move();
        // Add the move command to the command history
        cmdHistory.add(RobotAction.MOVE);
        return true;
    }
    else // don't move the robot
    {
        return false;
    }//END IF
}

zhb8015 2012-10-24 18:16 发表评论

IBM架构智能机器人

zhb8015 — Thu, 16 Aug 2012 05:32:00 GMT

http://www.tektalk.org/wp-content/uploads/2012/06/%E6%9E%B6%E6%9E%84%E5%8E%9F%E7%90%86%EF%BC%8D%E6%9E%B6%E6%9E%84%E5%B8%88%E7%9A%84%E4%BF%AE%E7%82%BC-v1.2-%E8%89%BE%E9%A3%9E.pdf

zhb8015 2012-08-16 13:32 发表评论

IBM总架构师寇卫东：话说程序员的职业生涯(转)

zhb8015 — Thu, 16 Aug 2012 05:13:00 GMT

作者：IBM 软件集团大中华区总架构师寇卫东

有一些年轻的程序员向我咨询，将来的路应该怎么走？俗话说，条条大路通罗马。不同的路都能走向成功。到底选哪条路，取决于自己的兴趣。可能有程序员会问：如果还没找到自己的兴趣怎么办？我的建议是多尝试，努力做，这是职业生涯的必经之路。当你积累了一定的技术和经验之后，就会面临多种选择。选择哪条路，因人而异。

如果对某一种或几种技术非常感兴趣，并且能够持续钻研，经过一定时期的积累，你可以逐渐成长为专家级程序员。专家级程序员对于所掌握的专业技术的熟练程度非一般程序员能及，各类常见编程问题在他们手中都能迎刃而解，可以说这类专家“越老越值钱”。但是这类专家也有一定的风险性：随着经验的增加和年龄的增长，这些人的工资会越来越高，当公司改变技术路线而不再需要专家级程序员所掌握的专业技术时，或者想降低做事的成本，他们就可能面临失业或者另找工作的局面。

资深培训专家也是个不错的发展方向。成为培训专家，不仅需要深厚的技术功底，同时还要具备优秀的沟通和表达能力，因为他们的主要工作不再是研发某种技术，而是传播技术知识。这条路很宽，有一些优秀的技术培训师除了担任本职工作，还会兼职到大学里讲课。虽然培训专家的技术可能达不到专家程序员的水平，但是工作内容相对更为丰富，接触的人也更多。

成为公司的技术总监是很多程序员的梦想。这条路线是从初级程序员成长为高级程序员之后，以做项目为工作重点，进而发展成项目经理、开发经理，最终成为技术总监甚至公司副总裁。这些程序员走的是技术管理路线，从做项目开始，逐渐积累管理经验，然后成长为优秀的技术管理者。技术总监在公司甚至技术界的影响力非同一般，对于那些有志于成为公司领导层的程序员，是个很大的诱惑。但是权力大、管的人多，就意味着更大的压力，技术总监不仅要保持对新技术的敏感，还要抽出精力做管理。比起成为纯技术专家，这条路也许更为艰难。

还有一些程序员职业发展的终点是总架构师、总设计师。这类程序员的兴趣，不是某种特定的技术，而是偏重对软件产品或者软件应用项目的设计。如果将软件项目开发团队比作一个乐队，那么程序员就相当于一名乐手（比如小提琴手、长笛手等），他们负责将自己的乐器演奏好；项目经理是乐队指挥，负责指挥和协调这个乐队的配合；架构师则相当于作曲家。从入门的架构师开始，逐渐成为资深架构师乃至总架构师。如同历史上伟大的作曲家，杰出的架构师能够在各种软件中谱写出旋律优美的“曲子”。

另外一些程序员心怀创业的理想，等到自己有了一定的技术积累，再掌握一些市场需求以及管理方法，他们会开始创业之路。一旦成功，这类人的影响力会非常大，像Google和雅虎的创始人，都是技术创业的成功典范。但是这条路也是最艰辛的，有句话叫做“不当家不知柴米贵”，不亲自创业的人也很难体会它的艰辛。创业涉及方方面面，稍有差池就会功亏一篑，投身创业的程序员并不少，但是真正能成功的少之又少。踏上这条路不仅需要过人的勇气和魄力，更需要坚韧不拔的毅力，以及深度的商业智慧，再加上市场机会，才能够赢到最后。

很多程序员会走上技术支持路线，进而发展成为精通业务的技术和行业咨询专家。这类程序员会在成为高级程序员之后加入销售团队，直接面对客户，负责技术层面的问题。如果对某一行业（比如银行、电信）非常熟悉，久而久之，就成为精通这个行业技术的专家；如果对于某一类解决方案（比如ERP、CRM、 SCM）非常擅长，就可以发展成为跨行业的技术专家。

还有一部分程序员会成为IT专栏作家和自由职业者。这些人通常对写作比较感兴趣，文字表达能力也不错，他们会将自己从事技术工作的内容或心得写出来，然后发表文章赚取稿费。只要对技术足够精通，这类人是很受杂志欢迎的。在北美还有一种自由职业者叫做合同工，就是不定期的承接项目，在项目开始前签订协议，项目完成后结束合作。虽然这种职业目前在中国还不太多，但是其自由性对于很多程序员来讲，也非常有吸引力。

上文提及的若干条路，程序员可以根据自己的兴趣进行选择，但是一般来说，无论走哪条路，都有一个前提条件：从初级程序员进阶为高级程序员。因为在这之前，你甚至没有选择的机会。从初级进阶到高级，通常需要2~5年的时间，因个人素质而异。大家都说，程序员要耐得住寂寞和枯燥，年轻的程序员更要克服浮躁的心态。在职业生涯的起步阶段，很多人总会摸不着头脑，这时一定要静下心来，多向资深程序员求教，慢慢熟悉技术、熟悉开发流程和行业。有时你会感觉掉进了一个知识海洋，身边全是陌生的事物，很难抓住。所以就更要四处探路，逐渐寻找到方向，在寻找中进步。

成功进阶为高级程序员，也并不意味着前途一片光明。如果说从初级到高级需要的是学习，那么从高级到专家，需要的是不断地尝试和坚持。比起前一个阶段，这个过程更为漫长，通常需要5~8 年。在这期间，因为有了之前的积累，并且已经取得一定的成就，人会更加自信，同时也会更加彷徨，有一个问题会时常盘旋在脑中：将来的路到底要怎么走？这时就可以利用自己所积累的资源，多做一些尝试，尝试不同角色、不同的项目，与不同的客户打交道，时间长了，自然会找到最适合自己的发展方向。

总结起来，初级程序员和高级程序员时期，都属于职业生涯发展的第一阶段，我们可以称之为黄金时期。这阶段程序员的年龄在20~35岁之间，因为年轻，所以更善于学习，而且体力充沛，很多走过这个阶段的程序员有过通宵工作的经历。在这个时期，你有大把的时间学习提高，为将来的事业打下坚实的基础。而一旦超过了30 岁，无论从体力还是精神上，都会有所改变，从30~40 岁是转型时期。这时的程序员（很多人已经不再编程）已经明确了自己的发展方向，并且向着目标努力，让自己有所建树。40~60岁是专家时期，至此，一名优秀的程序员会彻底实现“破茧成蝶”的愿望，成长为专家。

程序员的职业很精彩，同时也很艰苦。享受高工资，掌握最新的技术，有可能成为创业成功的富豪，甚至有机会改变人类的生活方式（例如互联网浏览器的开发、电子商务的应用、手机短信等），这就是别人眼中程序员的生活，也许正因此，每年都会有很多新人加入这个庞大的队伍，体验向往已久的精彩生活。但是大多数人却忽略了光鲜背后的艰辛，高工资的代价是工作强度高，学习新技术的代价是工作压力大，成为富豪的代价是心力交瘁，而若想改变人类的生活方式，那就要耐得住日复一日的枯燥和寂寞。酸甜苦辣都要自己品尝，程序员的发展道路有很多条，就看你怎么选。

zhb8015 2012-08-16 13:13 发表评论

（转）熊节：用五年的时间跨越鸿沟

zhb8015 — Fri, 20 Jul 2012 08:22:00 GMT

（本文发表于《程序员》2007年第2期，发表时有删节。）

用五年时间跨越鸿沟
——“大学未毕业程序员”的流水帐
禅宗说学佛有渐修顿悟之分。说到“跨越鸿沟”，总让人觉得像是习武之人一夜间打通任督二脉，霎时间神清气爽身轻如燕，原本百思不得其解的大难题突然就迎刃而解。这般境界着实令人神往，可惜我从参加工作以来五年有余，回想起来竟然没有这么一个天人合一的顿悟时刻。遗憾之余，只能安慰自己说：这就是所谓“资质”吧。没有当下开悟的聪颖天资，所以也难以体会跨越鸿沟的愉悦了。

不过想想五年前的自己，却也不是全无变化——不管技术、写作还是待人接物，就连头顶冒出的几根白发，都见证着自己的成长。不过最大的变化还是在自己心里：当年背着书包和无法完成的学业黯然离开校园的男孩，现在已经可以淡然地拿自己这段经历打趣了。能够坦然面对自己心中最不堪回首的往事，这也算是跨过一道鸿沟了吧。

北京理工大学，我的母校，是一所有着严谨学风的高校。在受她严格的理工科基础训练而获益匪浅的同时，我终于也没能达到她期望的标准。2001年，在学业还剩下一年尚未完成时，我不得不选择了离开母校—— 以一个失败者的身份。从那时候开始，我常常会做一个梦，梦见自己正在高三的教室里复习准备高考，一边还鼓励自己说“这次终于有机会把大学读完了”。能够顺理成章地拿到本科文凭的大多数人，恐怕是体会不到这种怅然若失的缺憾感的。

如果说梦中的缺憾感只是令人心绪不宁的话，白天需要面对的就是更加现实的问题了：一个机械工程系的肄业生要如何找到一份工作来养活自己？虽然一直热衷于编程，在学校里也有些小小的实践经验，但我实在没有自信能靠这样的背景留在IT圈里。好在当时供职联想的孟岩热心相助、《程序员》杂志蒋涛总编不拘一格、再加上当时创刊刚一年的杂志正需要青壮劳力，我的提前退学反倒成了因祸得福，早早地就给自己找到了一份工作。

这“因祸得福”之说并不纯是发扬阿Q精神：虽说薪水不高加班不少，但《程序员》杂志编辑部仍然是一个难得的优秀团队；更重要的是，在这里可以接触到前沿的技术和高端的视野，这对于正在渴求知识的我来说无疑是天赐良机。而且做杂志编辑还能近水楼台先得月地接触到图书出版机构，我的《重构》、《最后期限》、《与熊共舞》等几本译作都是在这段时间里完成的——对我而言，从事翻译工作最大的受益者还是我自己，因为翻译的过程让我真正将一本书读得通通透透。试想一下，这些书籍都是Martin Fowler、Tom DeMarco等前辈的心血凝粹，能将它们读懂又怎会不大有裨益？

但作为杂志编辑的一个缺陷也逐渐显露出来：虽然能够看到到很多技术文章和案例分析，但毕竟没有机会亲手开发一个真正的软件。每天只是高谈阔论，毕竟站着说话不腰疼，一来二去就成了个眼高手低的毛病。就算自己尝试写些程序，但一如温伯格所说，不从事专业的软件开发，就永远只是业余选手，对于“专业”的问题终归想不明白。况且媒介传播——纵令是关于“软件开发”的媒介传播——与软件开发始终是两码事，所需的心理状态和技能是截然不同的。于是在2003年初非典肆虐的日子里，我那颗程序员的心又开始躁动起来。要去做一些真正的软件，我才会知道软件究竟应该怎么做，模模糊糊中这就是我对自己说的话。

想要去做真正的软件也不是那么容易的，我的学历问题仍然是求职路上的拦路虎——我甚至不知道该如何在简历里写自己的教育背景，只好含糊其词地写上“曾就读于北京理工大学机械工程学院”。这样一份简历铁定入不了HR主管们的法眼，我这样告诉自己，所以还得另辟蹊径。这时候一位老友，在BBS上认识的石一楹成了我的贵人：此人经验丰富，技术精湛，做着某公司的技术总监和好几家公司的顾问，而且正好还在我素来向往的人间天堂杭州。于是几番电话之后，我便定下了前往杭州的机票。

石一楹给我第二大的帮助——最大的帮助自然是帮我在杭州找到一份工作——是教给我敏捷开发的理念。尚在北京时，我曾经通过电话问他：需要准备哪些背景知识。他既没有叫我去学J2EE，也没有让我补习SQL，只是要我把《解析极限编程》再读一遍。（当然我是刻苦的好学生，我把整套XP丛书都买来重读了一遍。）到了杭州以后，除了西湖的迷人风光之外，他的工作方式同样令我震惊：测试驱动、持续集成、故事卡、结对编程……这些似乎只有在书里、在老外的办公室里才可能出现的东西，就这么活生生地出现在我眼前。这让我第一次产生了一种朦胧的感觉：我们也可以用正确的方式做优秀的软件。

后来由于种种原因，这些敏捷的因素在我们的项目中出现得越来越少。到最后，除了一套尽管谈不上完备、但至少还频繁执行的测试和时常进行的重构之外，我们的项目已经基本回到大家更熟悉的、“普通”的工作方式了。这个现象引发了我的很多思考：为什么明明知道敏捷是更好的方式，我们却无法做到呢？说来有趣，最后解开我这个疑惑的竟然是《坛经》中一段禅宗典故。

五祖弘忍座下大弟子神秀偈云：

身是菩提树

心如明镜台

时时勤拂拭

勿使惹尘埃

更多人记得的是六祖慧能与之针锋相对的那一偈。但很多人似乎忘记，以一目不识丁的獦獠之身，能听人颂《金刚经》而有所悟，六祖的根性不是常人能比的。这世上有圣人能凭过人灵性而顿悟成佛，但更多凡夫俗子做不到这一点。这根性愚钝的凡夫俗子，难道就不用修行、无须上进了么？别忘了，五祖读了神秀的偈，也说“依此偈修，免堕恶道；依此偈修，有大利益”呢。

于是我开始观察，观察身边的同事，也观察自己。我观察到一个有趣的现象：很多同行（也包括我自己）想要偷懒、想要逃避那些严格的纪律时常用两个借口。其一曰“但求顿悟”——“Stallman/Linus/Gates……写emacs /Linux/Basic……的时候做单元测试了吗？”（所以我也不用做单元测试。）其二曰“不耐渐修”——“昨天就有一块代码没有单元测试了。”（所以今天这块代码不写测试也不算太糟。）亲爱的读者，不妨和我一道来摸着胸口拷问一下自己，这是不是我们常用的两套说词？

回答其实很简单：第一我们不是Stallman/Linus/Gates，他们是天才而我们不是；第二我们的工作还得继续做下去，而且我们希望把它做得出色。熵增加是宇宙的定律，为了让我们的程序、我们的项目、我们的团队、我们的工作环境有序而不混乱，我们就必须不断地向其中注入能量——既然还做不到“菩提本无树，明镜亦非台”，我们就必须“时时勤拂拭，勿使惹尘埃”。（两年后，当我成为一名ThoughtWorker之后，我才真正明白了这件事。这是后话，暂且按下不表。）

在杭州的日子里，除了与软件开发的技术和经验之外，我的另一大收获是开始信佛。照着佛经所说“观身如身，观心如心”的修行方法，我学会了如何去观察——当然包括观察别人、观察外界，但更重要的是观察自己。观察自己的身体感受和心理活动，并时时调节身体与心理状态，使自己身心平和安定。（除了别的好处之外，这种练习让我近两年很少生病，偶染小恙也心知肚明该如何调理痊愈，这算是信佛之后的一个意外收获。）就这样带着一些经验、一些思索和一些收获，2004年，在离开学校正好三年的那一天，我再次拨通了蒋涛的电话。

这次回到北京、回到传媒的原因有二。其一，我已经亲眼见到好的经验能够如何有效地帮助软件开发，我希望创造条件让更多好的经验被传递给更多的人；其二，除了软件开发之外，我仍然对麦克卢汉的大众传播理论怀着一份向往——有些事，你知道自己不会一直去做，但如果没有过足瘾就会一直惦念。媒体工作于我，就是这样的一件事。此时蒋涛的工作重心已经从《程序员》杂志转到了CSDN网站，我也就成了网站的技术主编——在Web 2.0热潮到来之时为一个拥有超过100万用户的网站工作，谁又能说这不是一种幸运呢？

在他的代表作《理解媒介》中，麦克卢汉提出了一个影响整个大众传播领域的理论：媒介即是内容。从一个非常狭窄的意义上来说，这就意味着经营媒体的重点不是制造内容，而是打造一个传播平台，让内容的生产者与消费者在这个平台上互通有无、各取所需。在根源上，这正是我重新回到传媒领域的原因：除了开发软件、享受编程的乐趣之外，我一直向往成为一名“技术传播者”——通过我的工作让更多人了解软件开发的知识和最佳实践，用我的思想去帮助别人获得成功，这给我带来的满足感丝毫不亚于解决一个技术难题。但与此同时，我也越来越清楚自己的个性并不适于从事媒体工作：对技术的热爱使我无法中立地对待各种不同观点，而“中立”却是媒体的一大要素；而且我喜欢解决具体问题胜于人际交往，这也决定了我无法成为一个优秀的记者或主编。就在不断努力和认识自我的过程中，又是半年时间过去了。Martin Fowler来了。

直到现在，每当被问到“最尴尬的事”时，我总会讲这个故事。我们跟上海交大借了一间大教室，我们拉出了醒目的横幅和招贴，我们邀请了三百位客人和十多位知名专家，这全都是冲着Martin的面子。但就在讲座开始前4个小时，Sidney Pinney（时任ThoughtWorks中国公司总经理）在电话里告诉我：“Martin因病不能来现场，我很抱歉……”尽管事后有各种关于我当时如何镇定自若的传言，不过说实话，我脑子里冒出的第一个念头是“赶快刮台风全城戒严吧……”也许又是一次因祸得福，这桩倒霉事让我和 ThoughtWorks一下子对彼此有了更多的认识。回到北京以后，郭晓（现任ThoughtWorks中国公司总经理）告诉我：也许我真正想做的是咨询。那么好吧，还能有比ThoughtWorks更让我心仪的咨询公司么？

但即便如此，当时的我其实也没想到，自己究竟会有多么心仪 ThoughtWorks这家公司——也来不及想，唯一的想法就是“终于可以尽享编程的快乐了”。第一个项目对我来说熟稔多过生疏：卡片墙、大白板、圆桌和随意滑动的椅子、免费的可乐、两人一台电脑……正是我寤寐以求的工作环境啊。2006年春节刚过，公司又派我去印度参加了ThoughtWorks University的学习。拿到毕业证的那一刻，泪都几乎要下来——好歹是张文凭啊，哪怕并不是真正的大学呢。

在 ThoughtWorks的时间稍长，特别是先后拜访了印度班加罗尔和澳大利亚墨尔本两处办公室之后，我渐渐明白了一件事：这世界上的天才比我们通常想象的要少得多，但凡人所能达到的成就却也比我们通常想象的要伟大得多。没错，我的意思就是：ThoughtWorks并不是“天才幼儿园”，这里的800多名员工都是有七情六欲、食人间烟火的凡人。这些凡人做出了令人刮目相看的事情、营造了令人向往的环境，仅仅是因为他们保持着自己向上的心。

拿 ThoughtWorkers常用的一个比喻，每个人都是一个热气球，在地心引力的作用下总想往下掉——累了，病了，心情不好了，打球受伤了……无数的理由让我们想躺在沙发上度过又一个无所事事的安闲夜晚。要让气球越飞越高，唯一的办法就是不断地给它加火。个人是如此，项目的运转、企业的环境也莫不如此。良好的项目不会自然而然地永远良好下去，它要靠每个人不断改进它的质量；振奋人心的工作环境不是从天而降的，它是靠每个人从一张贴纸、一个玩具开始积累出来的。有些热气球飞得那么高，也许只是因为它们一直没有放弃向上飞。

于是我真正释然了。五年的时间，我已经走到了这里。尽管自己还是那么微不足道——我学习新技术总是很笨，我到现在还不懂编译原理，我的英文口语结结巴巴……但我知道自己会一直向上飞。哪怕只有一点点进步，只要每天都比前一天更好一点点，我就不会再让自己失望。不过生活总是这么充满戏剧性：当我为自己的学历问题担忧时，其实从来没有人因此歧视过我；而当我能够坦然地拿这个话题开玩笑时，却着实被歧视了一把——因为没有本科学历，美国大使馆根本不考虑给我发放工作签证。在未来的若干年里，这也会是我的一个有趣谈资吧。

回想这五年来的经历，曾经有过好多次的因祸得福、好多次的贵人相助。我很愿意说这是因为自己命好，不过另一种解释也多少有些意思：每件事情的“意义”，其实是我们在事后给它加上的；如果用平和的眼光看待已经发生的事实，用积极的态度迎接即将到来的明天，也许所有的塞翁失马都可以变成焉知非福。是的，这似乎与因果律不符，但宗教信仰原本就不同于因果律。我信所有的事情都是神祗的安排，所以我欣然接受。

但听天命并非无须尽人力。神会给你祈求的一切，前提是你知道自己想要什么。关于“发现自己的兴趣和特长”，已经有无数人讲过无数次，实在不必再作强调。我想说的是，仅仅知道“了解自己”的重要性还是远远不够的，我们需要做更细致的工作来真正了解自己。借助一些专业而全面的心理、性格测试，你可以找到自己的性格特质和缺陷；然后你可以制订出具有可操作性的计划，充分发挥自己的长处，同时避免性格缺陷造成严重损失——举例来说，假如你害怕演讲，你不必费心（也不太可能）把自己培养成口若悬河的天才演说家，但可以（并且应该）想办法避免因为紧张而忘词；而且你还可以发挥自己善于收集资料的特长来帮别人准备讲稿，让别人替你去演讲。当然，最重要的还是自己的感受：花一点时间让自己静下来，然后问自己到底喜欢什么、想要什么。做自己喜欢的事情更容易做出成绩；而每天浪费8小时来做自己深恶痛绝的工作，不啻是在慢性自杀。

尽管辍学这件事困扰了我数年，但我并不因此而愤恨——甚至有些感激。因为没有文凭，让我比别人少了一道可以依靠的墙，因此也逼迫着我不断努力前进，不敢须臾懈怠。虽说自认为已经跨过了这条鸿沟，但我并不想忘记那种害怕一觉醒来一无所有的危机感。就让那个怅然若失的梦一直伴随着我吧，做一个“大学未毕业程序员”，我已经习惯了这种状态，感觉还真不错。

zhb8015 2012-07-20 16:22 发表评论

8个Java人物(转自CSDN)

zhb8015 — Mon, 25 Jun 2012 06:31:00 GMT

original:http://sd.csdn.net/a/20120625/2806851.html

本文列举了8个Java人物，他们创建了对Java社区贡献很大的框架、产品、工具和图书，也因此改变了Java的编码方法。一起来认识下吧。

8.Tomcat和Ant创办人

James Duncan Davidson，1997年到2001年在Sun公司工作，他创建了Tomcat应用服务器，这是使用最为广泛的Java Web服务器，同时还创建了Ant构建工具，Ant使用XML来描述项目的构建以及依赖关系，目前仍是Java Web项目构建的事实标准。

相关链接

7.测试驱动开发和JUnit的创办人

Kent Beck是极限编程和测试驱动开发方法论的创始人，此外他还开发了JUnit工具，这是使用最为广泛的Java单元测试框架，而且还有多种语言的变种都是基于该框架开发的。

相关链接

新闻和访谈

Kent Beck图书

6.Java集合框架创办人

Joshua Bloch领导了很多Java平台特性的设计和实现，包括JDK 5.0语言增强以及屡获殊荣的Java集合框架。2004年6月他离开了SUN公司并成为Google的首席Java架构师。此外他还因为《Effective Java》一书获得著名的Jolt大奖。

相关链接

新闻和访谈

Joshua Bloch图书

5.JBoss创办人

Marc Fleury在2001年创办了JBoss，这是一个开源的Java应用服务器，后来该软件卖给了红帽公司，然后加入红帽公司继续JBoss的开发，直到2007年2月。

相关链接

新闻和访谈

4.Struts创始人

Craig Mcclanahan是Struts框架的创始人，相信每个Java程序员都会知道Struts这个最为著名的MVC框架。

相关链接

新闻和访谈

3.Spring创始人

Rod Johnson是Spring框架的创始人，而后创办了SpringSource公司并任CEO。此外他还写了一本书《Expert One-on-One J2EE Design and Development (2002)》

相关链接

新闻和访谈

Rod Johnson图书

2.Hibernate创始人

Gavin King是Hibernate项目的创始人，这是注明的Java的ORM框架，同时他还创建了Seam项目，另外参与了EJB 3.0和JPA设计，并在其中起非常重要的作用。

相关链接

新闻和访谈

Gavin King 图书

1.Java语言之父

詹姆斯·高斯林（James Gosling，1955年5月19日－，出生于加拿大），软件专家，Java编程语言的共同创始人之一，一般公认他为“Java之父”。

在他12岁的时候，他已能设计电子游戏机，帮忙邻居修理收割机。大学时期在天文系担任程式开发工读生，1977年获得了加拿大卡尔加里大学计算机科学学士学位，1983年获得了美国卡内基梅隆大学计算机科学博士学位，博士论文的题目是："The Algebraic Manipulation of Constraints"。毕业后到IBM工作，设计IBM第一代工作站NeWS系统，但不受重视。后来转至Sun公司。1990年，与Patrick Naughton和Mike Sheridan等人合作“绿色计划”，后来发展一套语言叫做“Oak”，后改名为Java。1994年底，James Gosling在硅谷召开的“技术、教育和设计大会”上展示Java程式。2000年，Java成为世界上最流行的电脑语言。

相关链接

新闻和访谈

英文出自：Top 8 Java People You Should Know

译文来自：OSCHINA

zhb8015 2012-06-25 14:31 发表评论

细数25个硅谷最热创业公司寻找创业灵感(转)

zhb8015 — Thu, 10 May 2012 06:51:00 GMT

http://news.csdn.net/a/20120329/313713_2.html

zhb8015 2012-05-10 14:51 发表评论

如何将maven项目导入myeclipse中

zhb8015 — Tue, 17 Apr 2012 09:06:00 GMT

在mvn的项目中 pom.xml 文件所在目录， 运行   mvn eclipse:clean eclipse:eclipse ,会自动将mvn工程转成eclipse工程， 然后在eclipse中  “在myEclipse的Package Explorer 下点击右键，菜单中有个Import 再点开General 里面有个Existing Projects into Workspace 点击后 有个Select root directory 点击后面 Browse找到你的项目所在位置

zhb8015 2012-04-17 17:06 发表评论

源程序就是设计---By Jack Reeves (转)

zhb8015 — Fri, 13 Apr 2012 07:46:00 GMT

original:
http://blog.renren.com/share/333505459/7406458537

至今，我仍能记起当我顿悟并最终产生下面文章时所在的地方。那是1986年的夏天，我在加利福尼亚中国湖海军武器中心担任临时顾问。在这期间，我有幸参加了一个关于Ada的研讨会。讨论当中，有一位听众提出了一个具有代表性的问题，“软件开发者是工程师吗？”我不记得当时的回答，但是我却记得当时并没有真正解答这个问题。于是，我就退出讨论，开始思考我会怎样回答这样一个问题。现在，我无法肯定当时我为什么会记起几乎10年前曾经在Datamation杂志上阅读过的一篇论文，不过促使我记起的应该是后续讨论中的某些东西。这篇论文阐述了工程师为什么必须是好的作家（我记得该论文谈论就是这个问题——好久没有看了），但是我从该论文中得到的关键一点是：作者认为工程过程的最终结果是文档。换句话说，工程师生产的是文档，不是实物。其他人根据这些文档去制造实物。于是，我就在困惑中提出了一个问题，“除了软件项目正常产生的所有文档以外，还有可以被认为是真正的工程文档的东西吗？”我给出的回答是，“是的，有这样的文档存在，并且只有一份——源代码。”

把源代码看作是一份工程文档——设计——完全颠覆了我对自己所选择的职业的看法。它改变了我看待一切事情的方式。此外，我对它思考的越多，我就越觉得它阐明了软件项目常常遇到的众多问题。更确切地说，我觉得大多数人不理解这个不同的看法，或者有意拒绝它这样一个事实，就足以说明很多问题。几年后，我终于有机会把我的观点公开发表。C++ Journal中的一篇有关软件设计的论文促使我给编辑写了一封关于这个主题的信。经过几封书信交换后，编辑Livleen Singh同意把我关于这个主题的想法发表为一篇论文。下面就是这篇文章。

——Jack Reecves, December,22,2001

什么是软件设计？
Jack W.Reeves, 1992

面向对象技术，特别是C++，似乎给软件界带来了不小的震动。出现了大量的论文和书籍去描述如何应用这项新技术。总的来说，那些关于面向对象技术是否只是一个骗局的问题已经被那些关于如何付出最小的努力即可获得收益的问题所替代。面向对象技术出现已经有一段时间了，但是这种爆炸式的流行却似乎有点不寻常。人们为何会突然关注它呢？对于这个问题，人们给出了各种各样的解释。事实上，很可能就没有单一的原因。也许，把多种因素的结合起来才能最终取得突破，并且这项工作正在进展之中。尽管如此，在软件革命的这个最新阶段中，C++本身看起来似乎成为了一个主要因素。同样，对于这个问题，很可能也存在很多种理由，不过我想从一个稍微不同的视角给出一个答案：C++之所以变得流行，是因为它使软件设计变得更容易的同时，也使编程变得更容易。

虽然这个解释好像有点奇特，但是它却是深思熟虑的结果。在这篇论文中，我就是想要关注一下编程和程序设计之间的关系。近10年来，我一直觉得整个软件行业都没有觉察到做出一个软件设计和什么是真正的软件设计之间的一个微妙的不同点。只要看到了这一点，我认为我们就可以从C++增长的流行趋势中，学到关于如何才能成为更好的软件工程师的意义深远的知识。这个知识就是，编程不是构建软件，而是设计软件。

几年前，我参见了一个讨论会，其中讨论到软件开发是否是一门工程学科的问题。虽然我不记得了讨论结果，但是我却记得它是如何促使我认识到：软件业已经做出了一些错误的和硬件工程的比较，而忽视了一些绝对正确的对比。其实，我认为我们不是软件工程师，因为我们没有认识到什么才是真正的软件设计。现在，我对这一点更是确信无疑。

任何工程活动的最终目标都是某些类型的文档。当设计工作完成时，设计文档就被转交给制造团队。该团队是一个和设计团队完全不同的群体，并且其技能也和设计团队完全不同。如果设计文档正确地描绘了一个完整的设计，那么制造团队就可以着手构建产品。事实上，他们可以着手构建该产品的许多实物，完全无需设计者的任何进一步的介入。在按照我的理解方式审查了软件开发的生命周期后，我得出一个结论：实际上满足工程设计标准的惟一软件文档，就是源代码清单。

对于这个观点，人们进行了很多的争论，无论是赞成的还是反对的都足以写成无数的论文。本文假定最终的源代码就是真正的软件设计，然后仔细研究了该假定带来的一些结果。我可能无法证明这个观点是正确的，但是我希望证明：它确实解释了软件行业中一些已经观察到的事实，包括C++的流行。

在把代码看作是软件设计所带来的结果中，有一个结果完全盖过了所有其他的结果。它非常重要并且非常明显，也正因为如此，对于大多数软件机构来说，它完全是一个盲点。这个结果就是：软件的构建是廉价的。它根本就不具有昂贵的资格；它非常的廉价，几乎就是免费的。如果源代码是软件设计，那么实际的软件构建就是由编译器和连接器完成的。我们常常把编译和连接一个完整的软件系统的过程称为“进行一次构建”。在软件构建设备上所进行的主要投资是很少的——实际需要的只有一台计算机、一个编辑器、一个编译器以及一个连接器。一旦具有了一个构建环境，那么实际的软件构建只需花费少许的时间。编译50 000行的C++程序也许会花费很长的时间，但是构建一个具有和50 000行C++程序同样设计复杂性的硬件系统要花费多长的时间呢？

把源代码看作是软件设计的另外一个结果是，软件设计相对易于创作，至少在机械意义上如此。通常，编写（也就是设计）一个具有代表性的软件模块（50至100行代码）只需花费几天的时间（对它进行完全的调试是另外一个议题，稍后会对它进行更多的讨论）。我很想问一下，是否还有任何其他的学科可以在如此短的时间内，产生出和软件具有同样复杂性的设计来，不过，首先我们必须要弄清出如何来度量和比较复杂性。然而，有一点是明显的，那就是软件设计可以极为迅速地变得非常庞大。

假设软件设计相对易于创作，并且在本质上构建起来也没有什么代价，一个不令人吃惊的发现是，软件设计往往是难以置信的庞大和复杂。这看起来似乎很明显，但是问题的重要性却常常被忽视。学校中的项目通常具有数千行的代码。具有10 000行代码（设计）的软件产品被它们的设计者丢弃的情况也是有的。我们早就不再关注于简单的软件。典型的商业软件的设计都是由数十万行代码组成的。许多软件设计达到了上百万行代码。另外，软件设计几乎总是在不断地演化。虽然当前的设计可能只有几千行代码，但是在产品的生命期中，实际上可能要编写许多倍的代码。

尽管确实存在一些硬件设计，它们看起来似乎和软件设计一样复杂，但是请注意两个有关现代硬件的事实。第一，复杂的硬件工程成果未必总是没有错误的，在这一点上，它不存在像软件那样让我们相信的评判标准。多数的微处理器在发售时都具有一些逻辑错误：桥梁坍塌，大坝破裂，飞机失事以及数以千计的汽车和其他消费品被召回——所有的这些我们都记忆犹新，所有的这些都是设计错误的结果。第二，复杂的硬件设计具有与之对应的复杂、昂贵的构建阶段。结果，制造这种系统所需的能力限制了真正能够生产复杂硬件设计公司的数目。对于软件来说，没有这种限制。目前，已经有数以百计的软件机构和数以千计的非常复杂的软件系统存在，并且数量以及复杂性每天都在增长。这意味着软件行业不可能通过仿效硬件开发者找到针对自身问题的解决办法。倘若一定要说出有什么相同之处的话，那就是，当CAD和CAM可以做到帮助硬件设计者创建越来越复杂的设计时，硬件工程才会变得和软件开发越来越像。

设计软件是一种管理复杂性的活动。复杂性存在于软件设计本身之中，存在于公司的软件机构之中，也存在于整个软件行业之中。软件设计和系统设计非常相似。它可以跨越多种技术并且常常涉及多个学科分支。软件的规格说明往往不固定、经常快速变化，这种变化常常在正进行软件设计时发生。同样，软件开发团队也往往不固定，常常在设计过程的中间发生变化。在许多方面，软件都要比硬件更像复杂的社会或者有机系统。所有这些都使得软件设计成为了一个困难的并且易出错的过程。虽然所有这些都不是创造性的想法，但是在软件工程革命开始将近30年后的今天，和其他工程行业相比，软件开发看起来仍然像是一种未受过训练（undisciplined）的技艺。

一般的看法认为，当真正的工程师完成了一个设计，不管该设计有多么复杂，他们都非常确信该设计是可以工作的。他们也非常确信该设计可以使用公认的技术建造出来。为了做到这一点，硬件工程师花费了大量的时间去验证和改进他们的设计。例如，请考虑一个桥梁设计。在这样一个设计实际建造之前，工程师会进行结构分析——他们建立计算机模型并进行仿真，他们建立比例模型并在风洞中或者用其他一些方法进行测试。简而言之，在建造前，设计者会使用他们能够想到的一切方法来证实设计是正确的。对于一架新型客机的设计来说，情况甚至更加严重；必须要构建出和原物同尺寸的原型，并且必须要进行飞行测试来验证设计中的种种预计。

对于大多数人来说，软件中明显不存在和硬件设计同样严格的工程。然而，如果我们把源代码看做是设计，那么就会发现软件工程师实际上对他们的设计做了大量的验证和改进。软件工程师不把这称为工程，而称它为测试和调试。大多数人不把测试和调试看作是真正的“工程”——在软件行业中肯定没有被看作是。造成这种看法的原因，更多的是因为软件行业拒绝把代码看作设计，而不是任何实际的工程差别。事实上，试验模型、原型以及电路试验板已经成为其他工程学科公认的组成部分。软件设计者之所以不具有或者没有使用更多的正规方法来验证他们的设计，是因为软件构建周期的简单经济规律。

第一个启示：仅仅构建设计并测试它比做任何其他事情要廉价一些，也简单一些。我们不关心做了多少次构建——这些构建在时间方面的代价几乎为零，并且如果我们丢弃了构建，那么它所使用的资源完全可以重新利用。请注意，测试并非仅仅是让当前的设计正确，它也是改进设计的过程的一部分。复杂系统的硬件工程师常常建立模型（或者，至少他们把设计用计算机图形直观地表现出来）。这就使得他们获得了对于设计的一种“感觉”，而仅仅去检查设计是不可能获得这种感觉的。对于软件来说，构建这样一个模型既不可能也无必要。我们仅仅构建产品本身。即使正规的软件验证可以和编译器一样自动进行，我们还是会去进行构建/测试循环。因此，正规的验证对于软件行业来说从来没有太多的实际意义。

这就是现今软件开发过程的现实。数量不断增长的人和机构正在创建着更加复杂的软件设计。这些设计会被先用某些编程语言编写出来，然后通过构建/测试循环进行验证和改进。过程易于出错，并且不是特别的严格。相当多的软件开发人员并不想相信这就是过程的运作方式，也正因为这一点，使问题变得更加复杂。

当前大多数的软件过程都试图把软件设计的不同阶段分离到不同的类别中。必须要在顶层的设计完成并且冻结后，才能开始编码。测试和调试只对清除建造错误是必要的。程序员处在中间位置，他们是软件行业的建造工人。许多人认为，如果我们可以让程序员不再进行“随意的编码（hacking）”并且按照交给他们的设计去进行构建（还要在过程中，犯更少的错误），那么软件开发就可以变得成熟，从而成为一门真正的工程学科。但是，只要过程忽视了工程和经济学事实，这就不可能发生。

例如，任何一个现代行业都无法忍受在其制造过程中出现超过100%的返工率。如果一个建造工人常常不能在第一次就构建正确，那么不久他就会失业。但是在软件业中，即使最小的一块代码，在测试和调试期间，也很可能会被修正或者完全重写。在一个创造性的过程中（比如：设计），我们认可这种改进不是制造过程的一部分。没有人会期望工程师第一次就创建出完美的设计。即使她做到了，仍然必须让它经受改进过程，目的就是为了证明它是完美的。

即使我们从日本的管理方法中没有学到任何东西，我们也应该知道由于在过程中犯错误而去责备工人是无益于提高生产率的。我们不应该不断地强迫软件开发去符合不正确的过程模型，相反，我们需要去改进过程，使之有助于而不是阻碍产生更好的软件。这就是“软件工程”的石蕊测试。工程是关于你如何实施过程的，而不是关于是否需要一个CAD系统来产生最终的设计文档。

关于软件开发有一个压倒性的问题，那就是一切都是设计过程的一部分。编码是设计，测试和调试是设计的一部分，并且我们通常认为的设计仍然是设计的一部分。虽然软件构建起来很廉价，但是设计起来却是难以置信的昂贵。软件非常的复杂，具有众多不同方面的设计内容以及它们所导致的设计考虑。问题在于，所有不同方面的内容是相互关连的（就像硬件工程中的一样）。我们希望顶层设计者可以忽视模块算法设计的细节。同样，我们希望程序员在设计模块内部算法时不必考虑顶层设计问题。糟糕的是，一个设计层面中的问题侵入到了其他层面之中。对于整个软件系统的成功来说，为一个特定模块选择算法可能和任何一个更高层次的设计问题同样重要。在软件设计的不同方面内容中，不存在重要性的等级。最低层模块中的一个不正确设计可能和最高层中的错误一样致命。软件设计必须在所有的方面都是完整和正确的，否则，构建于该设计基础之上的所有软件都会是错误的。

为了管理复杂性，软件被分层设计。当程序员在考虑一个模块的详细设计时，可能还有数以百计的其他模块以及数以千计的细节，他不可能同时顾及。例如，在软件设计中，有一些重要方面的内容不是完全属于数据结构和算法的范畴。在理想情况下，程序员不应该在设计代码时还得去考虑设计的这些其他方面的内容。

但是，设计并不是以这种方式工作的，并且原因也开始变得明朗。软件设计只有在其被编写和测试后才算完成。测试是设计验证和改进过程的基础部分。高层结构的设计不是完整的软件设计；它只是细节设计的一个结构框架。在严格地验证高层设计方面，我们的能力是非常有限的。详细设计最终会对高层设计造成的影响至少和其他的因素一样多（或者应该允许这种影响）。对设计的各个方面进行改进，是一个应该贯穿整个设计周期的过程。如果设计的任何一个方面内容被冻结在改进过程之外，那么对于最终设计将会是糟糕的或者甚至无法工作这一点，就不会觉得奇怪了。

如果高层的软件设计可以成为一个更加严格的工程过程，那该有多好呀，但是软件系统的真实情况不是严格的。软件非常的复杂，它依赖于太多的其他东西。或许，某些硬件没有按照设计者认为的那样工作，或者一个库例程具有一个文档中没有说明的限制。每一个软件项目迟早都会遇到这些种类的问题。这些种类的问题会在测试期间被发现（如果我们的测试工作做得好的话），之所以如此是因为没有办法在早期就发现它们。当它们被发现时，就迫使对设计进行更改。如果我们幸运，那么对设计的更改是局部的。时常，更改会波及到整个软件设计中的一些重要部分（莫非定律）。当受到影响的设计的一部分由于某种原因不能更改时，那么为了能够适应影响，设计的其他部分就必须得遭到破坏。这通常导致的结果就是管理者所认为的“随意编码”，但是这就是软件开发的现实。

例如，在我最近工作的一个项目中，发现了模块A的内部结构和另一个模块B之间的一个时序依赖关系。糟糕的是，模块A的内部结构隐藏在一个抽象体的后面，而该抽象体不允许以任何方法把对模块B的调用合入到它的正确调用序列中。当问题被发现时，当然已经错过了更改A的抽象体的时机。正如所料，所发生的就是把一个日益增长的复杂的“修正”集应用到A的内部设计上。在我们还没有安装完版本1时，就普遍感觉到设计正在衰退。每一个新的修正很可能都会破坏一些老的修正。这是一个正规的软件开发项目。最后，我和我的同事决定对设计进行更改，但是为了得到管理层的同意，我们不得不自愿无偿加班。

在任何一般规模的软件项目中，肯定会出现像这样的问题，尽管人们使用了各种方法来防止它的出现，但是仍然会忽视一些重要的细节。这就是工艺和工程之间的区别。如果经验可以把我们引向正确的方向，这就是工艺。如果经验只会把我们带入未知的领域，然后我们必须使用一开始所使用的方法并通过一个受控的改进过程把它变得更好，这就是工程。

我们来看一下只是作为其中很小一点的内容，所有的程序员都知道，在编码之后而不是之前编写软件设计文档会产生更加准确的文档。现在，原因是显而易见的。用代码来表现的最终设计是惟一一个在构建/测试循环期间被改进的东西。在这个循环期间，初始设计保持不变的可能性和模块的数量以及项目中程序员的数量成反比。它很快就会变得毫无价值。

在软件工程中，我们非常需要在各个层次都优秀的设计。我们特别需要优秀的顶层设计。初期的设计越好，详细设计就会越容易。设计者应该使用任何可以提供帮助的东西。结构图表、Booch 图、状态表、PDL等等——如果它能够提供帮助，就去使用它。但是，我们必须记住，这些工具和符号都不是软件设计。最后，我们必须创建真正的软件设计，并且是使用某种编程语言完成的。因此，当我们得出设计时，我们不应该害怕对它们进行编码。在必要时，我们必须应该乐于去改进它们。

至今，还没有任何设计符号可以同时适用于顶层设计和详细设计。设计最终会表现为以某种编程语言编写的代码。这意味着在详细设计可以开始前，顶层设计符号必须被转换成目标编程语言。这个转换步骤耗费时间并且会引入错误。程序员常常是对需求进行回顾并且重新进行顶层设计，然后根据它们的实际去进行编码，而不是从一个可能没有和所选择的编程语言完全映射的符号进行转换。这同样也是软件开发的部分现实情况。

也许，如果让设计者本人来编写初始代码，而不是后来让其他人去转换语言无关的设计，就会更好一些。我们所需要的是一个适用于各个层次设计的统一符号。换句话说，我们需要一种编程语言，它同样也适用于捕获高层的设计概念。C＋＋正好可以满足这个要求。C++是一门适用于真实项目的编程语言，同时它也是一个非常具有表达力的软件设计语言。C++允许我们直接表达关于设计组件的高层信息。这样，就可以更容易地进行设计，并且以后可以更容易地改进设计。由于它具有更强大的类型检查机制，所以也有助于检测到设计中的错误。这就产生了一个更加健壮的设计，实际上也是一个更好的工程化设计。

最后，软件设计必须要用某种编程语言表现出来，然后通过一个构建/测试循环对其进行验证和改进。除此之外的任何其他主张都完全没有用。请考虑一下都有哪些软件开发工具和技术得以流行。结构化编程在它的时代被认为是创造性的技术。Pascal使之变得流行，从而自己也变得流行。面向对象设计是新的流行技术，而C++是它的核心。现在，请考虑一下那些没有成效的东西。CASE工具，流行吗？是的；通用吗？不是。结构图表怎么样？情况也一样。同样地，还有Warner-Orr图、Booch图、对象图以及你能想起的一切。每一个都有自己的强项，以及惟一的一个根本弱点——它不是真正的软件设计。事实上，惟一一个可以被普遍认可的软件设计符号是PDL，而它看起来像什么呢？

这表明，在软件业的共同潜意识中本能地知道，编程技术，特别是实际开发所使用的编程语言的改进和软件行业中任何其他东西相比，具有压倒性的重要性。这还表明，程序员关心的是设计。当出现更加具有表达力的编程语言时，软件开发者就会使用它们。

同样，请考虑一下软件开发过程是如何变化的。从前，我们使用瀑布式过程。现在，我们谈论的是螺旋式开发和快速原型。虽然这种技术常常被认为可以“消除风险”以及“缩短产品的交付时间”，但是它们事实上也只是为了在软件的生命周期中更早地开始编码。这是好事。这使得构建/测试循环可以更早地开始对设计进行验证和改进。这同样也意味着，顶层软件设计者很有可能也会去进行详细设计。

正如上面所表明的，工程更多的是关于如何去实施过程的，而不是关于最终产品看起来的像什么。处在软件行业中的我们，已经接近工程师的标准，但是我们需要一些认知上的改变。编程和构建/测试循环是工程软件过程的中心。我们需要以像这样的方式去管理它们。构建/测试循环的经济规律，再加上软件系统几乎可以表现任何东西的事实，就使得我们完全不可能找出一种通用的方法来验证软件设计。我们可以改善这个过程，但是我们不能脱离它。

最后一点：任何工程设计项目的目标是一些文档产品。显然，实际设计的文档是最重要的，但是它们并非惟一要产生的文档。最终，会期望某些人来使用软件。同样，系统很可能也需要后续的修改和增强。这意味着，和硬件项目一样，辅助文档对于软件项目具有同样的重要性。虽然暂时忽略了用户手册、安装指南以及其他一些和设计过程没有直接联系的文档，但是仍然有两个重要的需求需要使用辅助设计文档来解决。

辅助文档的第一个用途是从问题空间中捕获重要的信息，这些信息是不能直接在设计中使用的。软件设计需要创造一些软件概念来对问题空间中的概念进行建模。这个过程需要我们得出一个对问题空间中概念的理解。通常，这个理解中会包含一些最后不会被直接建模到软件空间中的信息，但是这些信息却仍然有助于设计者确定什么是本质概念以及如何最好地对它们建模。这些信息应该被记录在某处，以防以后要去更改模型。

对辅助文档的第二个重要需要是对设计的某些方面的内容进行记录，而这些方面的内容是难以直接从设计本身中提取的。它们既可以是高层方面的内容，也可以是低层方面内容。对于这些方面内容中的许多来说，图形是最好的描述方式。这就使得它们难以作为注释包含在代码中。这并不是说要用图形化的软件设计符号代替编程语言。这和用一些文本描述来对硬件科目的图形化设计文档进行补充没有什么区别。

决不要忘记，是源代码决定了实际设计的真实样子，而不是辅助文档。在理想情况下，可以使用软件工具对源代码进行后期处理并产生出辅助文档。对于这一点，我们可能期望过高了。次一点的情况是，程序员（或者技术方面的编写者）可以使用一些工具从源代码中提取出一些特定的信息，然后可以把这些信息以其他一些方式文档化。毫无疑问，手工对这种文档保持更新是困难的。这是另外一个支持需要更具表达力的编程语言的理由。同样，这也是一个支持使这种辅助文档保持最小并且尽可能在项目晚期才使之变成正式的理由。同样，我们可以使用一些好的工具；不然的话，我们就得求助于铅笔、纸以及黑板。

总结如下：
　　实际的软件运行于计算机之中。它是存储在某种磁介质中的0和1的序列。它不是使用C++语言（或者其他任何编程语言）编写的程序。
　　程序清单是代表软件设计的文档。实际上把软件设计构建出来的是编译器和连接器。
　　构建实际软件设计的廉价程度是令人难以置信的，并且它始终随着计算机速度的加快而变得更加廉价。
　　设计实际软件的昂贵程度是令人难以置信的，之所以如此，是因为软件的复杂性是令人难以置信的，并且软件项目的几乎所有步骤都是设计过程的一部分。
　　编程是一种设计活动——好的软件设计过程认可这一点，并且在编码显得有意义时，就会毫不犹豫的去编码。
　　编码要比我们所认为的更频繁地显现出它的意义。通常，在代码中表现设计的过程会揭示出一些疏漏以及额外的设计需要。这发生的越早，设计就会越好。
　　因为软件构建起来非常廉价，所以正规的工程验证方法在实际的软件开发中没有多大用处。仅仅建造设计并测试它要比试图去证明它更简单、更廉价。
　　测试和调试是设计活动——对于软件来说，它们就相当于其他工程学科中的设计验证和改进过程。好的软件设计过程认可这一点，并且不会试图去减少这些步骤。
　　还有一些其他的设计活动——称它们为高层设计、模块设计、结构设计、构架设计或者诸如此类的东西。好的软件设计过程认可这一点，并且慎重地包含这些步骤。
　　所有的设计活动都是相互影响的。好的软件设计过程认可这一点，并且当不同的设计步骤显示出有必要时，它会允许设计改变，有时甚至是根本上的改变，
　　许多不同的软件设计符号可能是有用的——它们可以作为辅助文档以及工具来帮助简化设计过程。它们不是软件设计。
　　软件开发仍然还是一门工艺，而不是一个工程学科。主要是因为缺乏验证和改善设计的关键过程中所需的严格性。
　　最后，软件开发的真正进步依赖于编程技术的进步，而这又意味着编程语言的进步。C++就是这样的一个进步。它已经取得了爆炸式的流行，因为它是一门直接支持更好的软件设计的主流编程语言。
　　C++在正确的方向上迈出了一步，但是还需要更大的进步。

后记

当我回顾几乎10年前所写的东西时，有几点让我印象深刻。第一点（也是和本书最有关的）是，现今，我甚至比那时更加确信我试图去阐述的要点在本质上的正确性。随后的一些年中，许多流行的软件开发方法增强了其中的许多观点，这支持了我的信念。最明显的（或许也是最不重要的）是面向对象编程语言的流行。现在，除了C++外，出现了许多其他的面向对象编程语言。另外，还有一些面向对象设计符号，比如：UML。我关于面向对象语言之所以得到流行是因为它们允许在代码中直接表现出更具表达力的设计的论点，现在看来有点过时了。

重构的概念——重新组织代码基础，使之更加健壮和可重用——同样也和我的关于设计的所有方面的内容都应该是灵活的并且在验证设计时允许改变的论点相似。重构只是提供了一个过程以及一组如何去改善已经被证实具有缺陷的设计的准则。

最后，文中有一个敏捷开发的总的概念。虽然极限编程是这些新方法中最知名的一个，但是它们都具有一个共同点：它们都承认源代码是软件开发工作中的最重要的产品。

另一方面，有一些观点——其中的一些我在论文中略微谈到过——在随后的一些年中，对我来说变得更加重要。第一个是构架，或者顶层设计的重要性。在论文中，我认为构架只是设计的一部分内容，并且在构建/测试循环对设计进行验证的过程中，构架需要保持可变。这在本质上是正确的，但是回想起来，我认为我的想法有点不成熟。虽然构建/测试循环可能揭示出构架中的问题，但是更多的问题是常常由于改变需求而表现出来的。一般来说，设计软件是困难的，并且新的编程语言，比如：Java或者C++，以及图形化的符号，比如：UML，对于不知道如何有效地使用它的人来说，都没有多大的帮助。此外，一旦一个项目基于一个构架构建了大量的代码，那么对该构架进行基础性的更改，常常相当于丢弃掉该项目并重新开始一个，这就意味着该项目没有出现过。即使项目和机构在根本上接受了重构的概念，但是他们通常仍然不愿意去做一些看起来就像是完全重写的事情。这意味着第一次就把它作对（或者至少是接近对）是重要的，并且项目变得越大，就越要如此。幸运的是，软件设计模式有助于解决这方面问题。

还有其他一些方面的内容，我认为需要更多地强调一下，其中之一就是辅助文档，尤其是构架方面的文档。虽然源代码就是设计，但是试图从源代码中得出构架，可能是一个令人畏惧的体验。在论文中，我希望能够出现一些软件工具来帮助软件开发者自动地维护来自源代码的辅助文档。我几乎已经放弃了这个希望。一个好的面向对象构架通常可以使用几幅图以及少许的十几页文本描述出来。不过，这些图（和文本）必须集中于设计中的关键类和关系。糟糕的是，对于软件设计工具可能会变得足够聪明，以至于可以从源代码的大量细节中提取出这些重要方面的内容这一点，我没有看到任何真正的希望。这意味着还得必须由人来编写和维护这种文档。我仍然认为，在源代码完成后，或者至少是在编写源代码的同时去编文档，要比在编写源代码之前去编写文档更好一些。

最后，我在论文的最后谈到了C++是编程——并且因此是软件设计——艺术的一个进步，但是还需要更大的进步。就算我完全没有看到语言中出现任何真正的编程进步来挑战C++的流行，那么在今天，我会认为这一点甚至要比我首次编写它时更加正确。

——Jack Reeves, 2002年1月1日

zhb8015 2012-04-13 15:46 发表评论

语源科技BlogJava-zhb8015

版本代码扫盲

how to write psedocode(reprint)

PSEUDOCODE STANDARD

Sample Pseudocode

推荐好文章（易学编程）

IBM架构 智能机器人

IBM总架构师寇卫东：话说程序员的职业生涯(转)

（转）熊节：用五年的时间跨越鸿沟

8个Java人物(转自CSDN)

细数25个硅谷最热创业公司 寻找创业灵感(转)

如何将maven项目导入myeclipse中

源程序就是设计---By Jack Reeves (转)

IBM架构智能机器人

细数25个硅谷最热创业公司寻找创业灵感(转)