Journeyman是小工吗?不是!

compactset
2009-09-26 看过
   书名:The Pragmatic Programmer: From Journeyman to Master。

   Master的意思很好理解,那什么是Pragmatic?在本书前言里,作者对Pragmatic Programmer应该具有的品质进行了枚举(care about your craft, Think about your work, Early/fast adopter, inquisitive, critical thinker, realistic, jack of all trades),总之都是很形而上很高的要求。Journeyman在英文里是什么意思? 难道真是指本书中文副标题中的“小工”? 在软件开发领域,什么样的程序员是Journeyman? 是不是一般的代码民工就是journeyman呢?我想大多数读过本书(不管是中文版或英文版)的都没有深入思考过(我第一次读到最近为止也没有)。

  做软件开发,都喜欢跟建筑行业类比。Kent Beck, GoF的模式思想受到亚历山大的建筑设计思想的启发;架构师在英文里则干脆跟建筑师是同一个单词;Code complete和Programming Pearls里将软件里没有考虑特殊的异常情况比作不了解桥梁附近的涡旋气流的建筑师没有对大桥的安全系数进行冗余设计,等等。是不是出自建筑上的类比,将一般水平的软件开发人员比作建筑行业的小工?这本书译者(或编辑)把journeyman翻译为小工,和把Code Complete翻译成代码大全,都是错误的,目的可能是为了提高书的销量,毕竟把副标题改为“从熟手”到“大师”会吓退不少人,而用从小工到专家则平易近人的多,也更符合中国it浮躁落后的国情。

  建筑行业的小工我也当过(自家盖房),因为有技术含量的不会,做的是没有技术含量的拌混凝土、筛黄沙、搬砖之类的重体力活,根本不要动脑子,只要听从指挥多流汗就可以了;而具体的架构设计(梁、墙、地基多深、高度、水平度、楼板、钢筋多粗、承重、利用经验对需要多少包水泥黄沙用量进行封底计算以便确定采购量和估算工程费用、工期估算、如何避免雨季对工程的影响,地震活动对水泥标号选择的影响等)则一点也不懂,也不需要懂。

   英文里的Journeyman到底是不是小工的意思? 在google字典里,Journeyman的意思是:
      (in the past) a person who was trained to do a particular job and who then worked for sb else (旧时)学徒期满的工匠,出师的学徒工
      a person who has training and experience in a job but who is only average at it 熟练工;熟手
      In former times, a journeyman was a worker who had finished learning a trade and who was employed by someone rather than working on his or her own.
      If you refer to someone as a journeyman, you mean that they have the basic skill which their job requires, but are not very talented or original.

    显然,小工只能算是学徒期的工人,而不是学徒期满的工匠,journeyman是已经经过培训对工作有一定经验的一般水平的工匠,能完成工作,但是缺乏天分或原创精神。journeyman能盖普通的遮风挡雨的房子,但是让他建造奔向天国的教堂则肯定不行。

在“上古卷轴”游戏里里,不同经验等级划分如下:
http://www.uesp.net/wiki/oblivion:spells
技能熟练等级 技能等级
新手(Novice) 0-24
学徒(Apprentice) 25-49
熟手(Journeyman) 50-75
专家(Expert) 76-99
大师(Master) 100

而研究所里的职称序列为:
研究实习员
助理研究员
副研究员
三级研究员
二级研究员
一级研究员

   从上面的序列可以直观的看出,journeyman至少是中级水平的,因为比journeyman高一级的是专家了,应该相当于软件公司的CTO,架构师,首席DBA之类的,或者医院里的专家门诊的主任或副主任医师,那比专家低了一级的应该是技术主管层次的。所以这本书的定位是给有一定项目开发经验的软件开发技术人员。从书后习题答案可以看出,读者需要熟悉Perl,Awk, C++, C, Java, Refactoring, Shell, DBC, RegEx, OO, lex/yacc之类的相关知识,这个要求说高不高,说低也不低,但肯定不是小工的水平了。英文副标题的本意是从熟手到大师,却被翻译成从小工(学徒工)到专家,相当于本意是从副研究员到一级研究员,却被翻译成从助理研究员到三级研究员,硬生生被降了级,难道是译者根据国内it落后现状做的意译?
 

各行业的Journeyman
    在游戏里,中级英雄,而不是低级炮灰,不砍人的时候不练功而是发呆,没有必杀技,能砍低级兵,自己也经常挂;

   在研究所里,通常为副研究员职称,手下有干活的助理研究员研究实习员若干,上百万、上千万的科研项目负责人,做过95,105,863,973,正在做115,享受一定的国家津贴,在国内期刊能通过付版面费发表论文以便将来评研究员职称,没科研经费很高的项目做时不读论文提高内功而是整点几十万的小项目或把以前的项目改个fancy name继续在网上孜孜不倦的申请课题或报奖,但其实数学基础创新能力很差,靠玩弄国外技术概念吃饭,从未(将来也不会)发表sci/ei的论文;
   
    在软件公司,项目技术带头大哥,对J2EE或.Net技术体系内的常用框架熟悉,数据库、Web开发熟练,Corba/COM/Web Service, 懂得封装继承多态,会多线程/Socket开发,会用Rose/PowerDesigner;能设计好后让一群代码民工编写模块,没活干的时候不知道提高自己和下属的技术能力读C++ report /CUJ/MSJ /DDJ/SDM,而是上csdn争论java和.Net的前途或者偷菜,只会玩三层架构,其实只是会熟练查MSDN或JavaDoc;

    在医院, 副主任医师或主管医师,看过很多病人,开药方非常熟练,药方上的密码龙飞凤舞,平均每个病人3分钟,喜用审犯人口气询问病情,热衷于开最新一代光谱抗生素,每月初都能在医院厕所里拿到上万医药代表回扣,平时一般忙着看病人没空研究技术写论文,最多玩玩医院买的数百万的医疗设备弄个技术引进奖,其实只是背熟了药典而已;

    在建筑行业,盖普通居民住房的包工头,造过很多房子,但是没有资质,只能盖3层以下的房子高了会楼脆脆,有时没活也接些装修的活,纯粹是剥削农民工的包工头,只是对购买黄沙水泥原材料接项目比较熟悉。

    言而总之,总而言之,翻译成小工是不对的,小工应该是Novice或Apprentice的水平。

    这本书后面的习题答案非常棒,问题规模都很小,不是很难,但很有启发作用。 本书两位作者都是consultant, 这种人精都有很多行业的20年左右的it项目经验,给开发团队当顾问教练,都是master,书中的tips因此是他们多年的经验总结best-practices。在cba混的运动员看不起郭士强,却不会看不起nba的哈里斯;而有的评价这本书的人小看这本书的作者,岂不是连四肢发达头脑简单的运动员都不如?

   amazon上有人批评此书“1英里长,但是只有1英尺深”,并推荐Code Complete,殊不知两本书都是BFS类型的,而不是DFS类型的。Code Complete固然很厚很全,但是作者还是在书末推荐了很多书籍杂志,如果够全够深,那他还用的着推荐这些书杂志吗? 虽说治大国若烹小鲜,半部论语就可治天下,但是在软件开发中光靠KISS是不可能的,看看Code Complete末尾的令人望而生畏的参考文献, 他的初中高级推荐书目或作者网站上的程序员职业发展路线Construx Professional Ladder(http://www.construx.com/Page.aspx?hid=952)就知道了。
   
     确实,书中每个主题都点到为止, 不够深入;但书中每个主题都可以写一本书, 如DBC, 如Testing, 如Code Generation, 如重构, Use Case, 算法。如果递归深入下去, 那用Code Complete的篇幅也不够。其实The Pragmatic Programmer和Code Complete 2虽然厚薄差别很大,但作者的写作思路都是BFS而不是DFS,对读者进行软件开发的通识教育, 因为具体的DFS工作已经有汗牛充栋的CS书在那里了。经过这种通识教育的人,如果不知道自己去DFS, 那么就只能怪自己了,师傅领进门,修行在个人。书中作者提到的领域都有经典著作, 如DBC和OO可以读Bertrand Meyer的Object-oriented Software Construction 2rd, 重构有Martin Fowler和Kent Beck的Refactoring/Smalltalk Best Priactices,Unit Testing实战有JUnit in Action, JUnit Recipes, 理论性的测试书有Foundations of Software Testing, Code generation可以读Common Lisp, Haskell之类的函数式语言的书中的例子/The art of Unix Programming中的MIni Language和DSL章节/code generation in action,用例有经典的Writing Effective Use Cases,算法书更多,远有Knuth, Bentley, Sedgewick, CLRS的经典,近有Algorithms, Algorithm Design, The Algorithm Design Manual。好书很多,我DFS不过来,所以现在还是个跑龙套的。

---------------------------------------------------------------------------------------
2009-10-02 更正:
娶了双胞胎姐妹之一的P.J.Plauger在澳大利亚悉尼给学生上软件工程课程时,没有给学生讲授软件分析设计技术、CASE工具和SEI的最新进展.,因为他认识到:
  No point in leading students to the mountain top if they haven't learned their way around the foothills adequately. My goal was to make sure they at least knew about all the low-level terrain. They could climb their own hills later, if they chose.
Hunt和Thomas应该也是类似想法.大师都是受人以渔的.

Meilir Page-Jones(Practical Guide to Structured Systems Design一书作者)将专业技术等级分为7类(http://www.waysys.com/ws_content_al_sse.html),应该比较权威,比游戏里或我臆想的要严谨的多:
Stage 1: Innocent

A Stage 1 may not have heard of Software-Engineering techniques. Or — more likely nowadays — he may be vaguely aware of their existence but may not see their possible relevance to his situation. Indeed, he may be only dimly aware that there are any software-development problems in his shop. You may find it incredible that Stage 1s could exist in the 1990s, but they do. And the reason stems from the way in which software complexity evolved.

Software became insidiously more and more complex in the 1970s and 1980s as users demanded more and more sophisticated systems be installed on the more and more powerful hardware that became available. Yet there was no sharp transition. The earth was not hit by a Complexity Asteroid in 1975 that suddenly made software three orders of magnitude more complex and cast our reptilian development techniques into extinction.

I call the way in which software complexity actually increased “Frog in the Pan.” This is because although a frog will jump out of a pan of hot water, a frog that is placed in a pan of cold water and slowly heated will fail to leap forth and will actually boil to death. The temperature gradient is so gradual that there will never be a point at which the frog declares: “Boy, it’s suddenly gotten hot in here! I think I should hop out.” (Before I get into deeper trouble from animal-rights folks, I hasten to add that this analogy is apocryphal. I’ve never tried the experiment and I don’t recommend that you do so either !)

Many Stage 1s are experiencing “Frog in the Pan” and are trying to tackle problems of the 1990s with approaches of the 1960s and 1970s, without realizing that the problems they’re facing are the very ones that modern Software-Engineering techniques were created to alleviate.

Stage 2: Exposed

Stage 2s have noticed that the water is getting decidedly warm, if not downright hot. So they are actively seeking Software-Engineering techniques that will get them out of the pan or at least reduce the heat. Stage 2s may survey magazines, confer with colleagues or attend one-day overviews of the techniques. Their interest level is high but their knowledge level is low, being limited to a few terms and definitions and not based on any practical Software-Engineering experience.

Stage 3: Apprentice

Stage 3s have attended one or two 5-day workshops on Software-Engineering techniques. In these workshops they tackled small but realistic case studies that resembled their own projects in miniature. The case studies provided valuable kinesthetic reinforcement of the formal lecture material and were thus indispensable. However, the case studies’ apparent realism conveyed to the Stage 3 a confidence that is often unwarranted.

If a Stage 3 absorbs everything from a seminar, then he is minimally equipped to tackle a true, full-sized project in the corporate jungle. Usually, however, a Stage 3 does not grasp everything or has difficulty scaling the techniques up from a case study to a real project. You could say that most Stage 3s know just enough to be dangerous!

Stage 4: Practitioner

The rite of passage to Stage 4 is the use of Software-Engineering techniques on at least one significant project. Achieving “Stage 4-hood” is for many people the most difficult transition of the six transitions between stages. The fledgling Stage 4 is asked to take untried (by him) techniques and apply them to a corporate project with the usual demonic cocktail of politics, deadlines and changing requirements. At the same time, he is attempting to recall what he learned in class and scale up the examples 10- or 100-fold. He continually needs consulting advice, without which he will encounter a series of minor setbacks or major failures. Since many people throw up their hands at this point and revert to their old mediocre but familiar ways, a large proportion of Stage 3s never make it to Stage 4. If an entire project is peopled with Stage 3s, then it’s highly likely that the project itself will fail and the Software-Engineering techniques will be publicly pilloried and then abandoned.

Stage 5: Journeyman

Stage 5s have made it. Their experience of Software-Engineering is “latched” in place and there is little risk of their reverting to the past. In the Stage 5 the Software-Engineering techniques yield for the first time the productivity the marketing folks promised; and on each successive project a Stage 5 further hones his skill and enhances his productivity. A Stage 5 is self-sufficient - more often the source of Software-Engineering advice than its recipient.

Stage 6: Master

The Stage 6 not only is an adept technician, but also possesses a profound methodological foundation. Beyond the “whats” and “hows”, the Stage 6 knows the “whys” of Software Engineering. This depth allows him sometimes to break a surface rule, while adhering to a more fundamental methodological principle. The Stage 6 is a good instructor because his theoretical and practical knowledge give him the wherewithal to tackle difficult student questions.

Stage 7: Researcher

The Stage 7 is concerned with delivering the latest developments in Software Engineering to a wider audience, via books, articles and conference appearances. The Stage 7 looks out for flaws in contemporary Software-Engineering techniques and for consequent ways to improve the techniques. He also scans the horizon for new problems towards whose solution Software Engineering can be extended and generalized. The Stage 7 is at a methodological pinnacle.


A couple of our clients measured the length of time from Stages 3 to 5. Depending on the individual person, Stage 3 to Stage 4 took 6 to 18 months (about the length of a project or phase) and Stage 4 to Stage 5 took 18 to 36 months.

Never attempt a crucial project solely with Stage 3s and below. Seed each project with Stage 4s and allow access to Stage 5s and 6s if possible.

If you don’t have a Stage 5, beg, borrow, steal, buy, kidnap, ... one. External consultants are valuable as a short-term measure. (从这句话就可以看出stage5也就是Journeyman地位之高)

Page-Jones眼中的Jurneyman对于公司的作用是这样的:
"Stage 5 the Software-Engineering techniques yield for the first time the productivity the marketing folks promised." it项目延期或失败的概率很高, 因此能做到这一点的人水平肯定是很高的。




 此外,在Software Craftsmanship The New Imperative这本书的第12章和第13章专门用整章的篇幅讨论了Apprentice Developer和Journeymem Developer.
7 有用
1 没用

查看更多豆瓣高分好书

评论 10条

查看全部10条回复·打开App

程序员修炼之道的更多书评

推荐程序员修炼之道的豆列

了解更多图书信息

豆瓣
免费下载 iOS / Android 版客户端