• 回帖整理


    原帖

    既然你觉得你说的不带劲,我说点带劲的。不过随大流就是最佳策略的同行们就不用看了(对个人职业生涯来说大多数是这样的),这个回复和你们无关。

    //update,更带劲的删了。我确实不是原来没注册的我了。

    只是我说,即便那些关注具体点的小品文章确有借鉴价值,我认为你给出的评价有点过高。



    先是对我的一贯攻击对象、既方法推广者的大多数作者及其作品:

    对人不对事地说,热衷于发表这些的个人和组织,似乎没有一个真正一流的程序员和一流的软件作品,我不是下论断,而是举事实。那么一帮二流甚至不入流的家伙写的东西,到底谁应该读?

    谁也不会因为几个偏方有用,就让江湖术士代替了医生,可这在我们的行业一直在发生。从大企业里的江湖术士(比如瀑布模型、这并不因为他们是什么地位就能装裱成医生)到现在。

    说实话,DHH这样乳臭未干、没写过几行代码的毛头小子都比他们强的多;而且他们自己似乎也承认:从DHH身上我们还能看到,谁、什么东西有抬头的趋势,整个圈子就捧谁(最后就是《伤仲永》的故事)。

    这些一直在发生的事情,恐怕不用我多说,睁眼看看世界就能看到。就好比Erlang的作者所言,某些人创造了一个“工业”,我想这话比我说的有分量。



    其次是笼统地看一看各种经验介绍和方法介绍(仅限你评论的这类)的必要性:

    这一点,进行一个这样的比较:那些不断产生地真正优秀的软件,他们的作者又如何呢?

    比如John Carmack,我们不提他在游戏和图形界的成就:90年代他就在产品中采用了现在Android上这样的打包形式、就采用了脚本程序运行时载入的方式、就提供了配置文件定制行为的方法。架构、重用?CS是HL的Mod,而HL又来自于Q1和Q2的混合引擎。

    他平时关心的是什么?别说号称动辄就得琢磨三年五年的程序设计、项目管理的方法论了,即便那些我这样的反社会的主儿都夸奖的有价值的经验介绍类,即便在菜鸟时期的他、在学习中能占有多大重心?

    也许这个问题看起来比较难回答,因为我又不是他的跟班。但只要考虑到他成长的年代就知道根本没有多少类似东西可看;再看看他的设计和代码,就知道他当年几乎没有什么东西是从书中学习:首先他们没有遵循什么特定方法;其次对于具体代码经验他们自身的水平就远超这些书的作者。

    (同样的还有苹果共同创始人Woz、卡特勒、Anders基本都是这样。Woz也明确地说过基本就是闭门造车,虽然Woz的工作量似乎和其它几个人没法比,但在当时他也不算是落后于同辈工程师的)。

    我们关心的又是什么?当前这个年代,有什么人超过他们这样的人的进步速度吗?Carmack实现的那些东西,对他来说只是一种需求导致的实现,而我们却成天在类似东西的更低层面上讨论和评价,并以为脱离了菜鸟层。

    我觉得这很说明了一些什么:似乎优秀的程序员总是在解决应该解决的问题,越来越多的,他们就掌握了问题解决之道。没有事先学习似乎并不成为一个障碍。

    要想得到相同的能力,我认为恰恰只有放弃某些所谓的“学习”才能做得到。因为我们需要时间和精力直接进行锻炼。

    最终,人总能得到一个自己的风格,而这个风格绝对比这些书中的经验更加适用(无论是否一致)。对于一个上进者来说,即便从来不关心从来不看这类读物,也不会降低一个人的进步、和创造价值的速度。

    另一方面,那些真正优秀的程序员和组织的经验,看起来也很难总结成书,让每个人都可以遵循。为什么。因为写程序、设计,实际上是一个非常随意、个人的事情;而管理则大多具有强烈的组织个性(这一点也至关重要!)。

    不能套用甚至完全无用,这在那儿、做的什么项目、在项目中处于什么位置,都是一样的。因为我们做的是靠一群人的脑力、和感情的工作。就进来发展的20年我们根本就不可能有足够的标本,在一些方面总结出什么对每个人都具有哪怕是最基本的价值的东西。[1]

    也就是说,想成为优秀程序员,不必要也不应该关心这类读物:很多书对我们根本没用,因为它们进行的讨论就是无用的;而另一些实际上除了在一些方面具有有限的提示作用、只能用来消遣。

    实际上似乎那些最杰出的人,都是那些从一开始就只要有个参考手册备查足以开始项目就够了的人。他们跟着一个又一个的项目一起成长,最终超越了所有的人。唯一不变的是,他们乐此不疲。

    ---------

    (此段属于个人交流,删除)

    当然也许是我不切实际,就这个(成为优秀程序员的)目标来说,在起跑线上还是在中途成为Loser(以我的标准我个人几乎可以肯定的做不到),并不重要。可能活着还不如多折腾当前能折腾的,图个Happy就完了。

    在你这里留言,就像很久以前匿名时一样。包括路过的、如果我也不小心扫到了你们,我声明这些只是我的一家之言,当然要是说中了反正您得想想。

    说实话,我也不知道我能从你对这些书的评价引出这么多,实际上也和你最近关注和实践的东西在我看来不重要害有关。不想私下里交流了,因为希望别人也看看我这种观点,而且可能是最后一次大张旗鼓的说。

    要是确实大家总能为自己找到理由支撑自己当前所见所闻所说(包括我),那就各信各的吧。也许我就是一个脑子有病、偏激、浅薄的人;但如果确实各自情况不同或者目标不同,我也懂得求同存异的礼貌。

    ---------

    [1]:敏捷恶心就恶心在扭扭捏捏,一方面他们认识到统一处理样板化的方法不能成功(继续宣传下去只会让某些人丢掉饭碗);一方面,某些人不愿意承认我说的这个情况、并仅仅把关注点在很小的问题-方法对上,那样他们价值和价格的不相符这一点就会迅速显露。

    题外话:就“测试是没有用处的”的这样的话,Knuth也说过。你是不是认为他太“学院派”了?

    Knuth说,他仅仅在不知道自己干什么、会有什么结果的时候才使用测试。(以下部分不是他老人家金口玉言是我的屁股想的)到了组织里,组织很难知道个体在干什么、会有什么结果,那么组织当然就要想办法(虽然测试不是唯一)。

    也许你说,你看,这就是现实实践,而且某某总结了,这不是很好吗?

    问题是,这种事情应该局限在每个很具体的情况下讨论,而根本不是想办法拔高成什么东西四处推销,然后成就这个某某“思想家、意见领袖”的地位。

    这要是在传统的工科环境里,可不就是一些工程师发表一些工程论文的事情吗:一般倾向于,仅仅把这些总结看作不能卖钱的资料,而不是某种形式的强烈推荐(因为它们不能被证明是大范围适用的),现在在我们的行当,又倾向于作为什么呢?

    难怪当年程序员自称是工程师,引起了工程师协会的严重不满呢...

    另外一个例子:就流行过一阵子的“约定大于配置”这样的废话,简直是根本不值一提的。如果我们不约定if (这里写条件),我们怎么写程序的?main()是怎么来的?这他妈还用人说不成?

    (关键不是什么情况下约定合适、什么情况下配置合适,这又有多少经验是可以总结传递的?有谁说清楚了?)

    对了,我们现在的社区就是必须得有人说,不说我们还真就不知道。因为我们已经被一波一波喷的头晕转向了!也许某些人不承认这一点,总觉得只要学下去、实践下去就没错。

    (有的人还认为自己作为普通观众,比某些杰出程序员还“客观”,可以博采众家之长。这可能吗?退一万步说即便如此,为什么更优秀的是别人呢?)

    关键是你学的是什么、你如何实践的。说实话无论是我的还是某些人的工作环境,好多东西想要真正弄清楚价值那是妄谈:因为你手头那些事的成败跟对这些东西的选择关系不大(往往造成怎么干都能肯定出道理来)。

    唉唉唉,我都成了祥林嫂了。谁爱沉思谁沉思去吧,谁自认为自己卓有成效却习惯的过着没有*真正*创造的日子就继续修炼吧。

    我还是那话:我不是什么正经程序员,不过看着大量程序员和真正杰出者在行为上的差别,我都替你们着急。越说越生气,我TM太愤青了,自己滚蛋了。

  • 相关阅读:
    win 8系统:System.IO.FileNotFoundException: 未能加载文件或程序集“CefSharp.Core.dll”或它的某一个依赖项。找不到指定的模块
    shell 调试脚本设置
    shell 变量相关的命令
    shell 多行注释
    web site optimization
    centos7 yum install timeout
    centos7 update network time
    centos7 update docker
    centos7 install fastdfs nginx
    centos7 install rabbtimq
  • 原文地址:https://www.cnblogs.com/guaiguai/p/1589695.html
Copyright © 2020-2023  润新知