著名程序员 Eric S. Raymond :用 SaaS 是一种危险的愚蠢行为

640?wx_fmt=gif

SaaS(Software as a Service)全称为软件即服务,是 21世纪开始兴起的一种完全创新的软件应用模式。对于供应商而言,其将应用软件统一部署在自己的服务器上,客户可以根据自己实际需求,通过互联网向自己定购所需的应用软件服务,在一定程度上,SaaS 可以降低供应商所消耗的成本;而对于客户而言,这种将业务关键交托于供应商手中,安全性该如何保证?

日前,著名程序员、黑客、《Unix编程艺术》作者埃里克·斯蒂芬·雷蒙发文强烈表示“使用 SaaS 是一种危险的愚蠢行为”,与此同时,他也呼吁开发者,如果想控制自己的项目,最好的方式还是去依赖于开源的软件。

640?wx_fmt=jpeg

作者 | Eric Raymond

译者 | 弯月,责编 | 屠敏

出品 | CSDN(ID:CSDNnews)

以下为译文:

最近有消息称,商业软件公司Saleforce.com宣布将不再为“销售军用枪支”的客户提供服务。

这项禁令让人感到惊讶的原因是,这是一家提供“软件即服务”的公司。也就是说,你运行的只是软件的客户端,而服务器则归供应商拥有和运营。如果供应商决定不为你提供服务,那么你可能连真正的追索权都没有。你可以就商业关系中的侵权干扰提出起诉,但这有点冒险,而且退一步讲,你根本不想卷入官司,你想好好做生意。

这就是为什么我认为“软件即服务”是一种危险的愚蠢行为,它对你的战略业务造成的风险甚至比老式的专有软件还高。你并没有拥有软件,而是软件拥有你。

时至2019年,我觉得我应该没有必要重申这个显而易见的事实:如果你想控制你的业务,那么还是考虑依赖开源的软件吧。而且最为重要的是,即使软件本身名义上是开源的,你也不能让它与服务供应商有任何瓜葛。

否则,你如何确保不会出现一些业界人士认为你的产品不干净,而将你的产品拦腰截断?

同时,你也无视了你的业务目标与供应商的不同而产生的所有风险。二十年来我一直在大力揭示这种风险,难道真的要我穿上江口名人(游戏《洛克人网络大战》系列中的人物)的斗篷去各地举办大肆宣传吗?

商业领导者应该了解每一种专有软件和“服务”带来的风险。如果Salesforce.com傲慢的禁令给了你一个大大的教训的话,那也称得上是一项服务了。

对此,网友也发表了自己的看法:

评论1:

毋庸置疑,由于商业以外的原因而被封禁是一个巨大的威胁。但我们还需要考虑一点:成本。自从转向SaaS和订阅模式以来,微软、Adobe和其他几家公司的利润曲线都呈现上升趋势。至少其中一些公司显示平均每个客户的利润有所增长。所以,很明显客户在软件上花了更多钱。虽然我们不是很确定,但Saas肯定为供应商节省了间接成本,或者可能每个客户购买了更多的许可证。然而,根据我的经验,在一年之内订阅的费用就会超过直接购买的价格,而且在供应商系统上运行的SaaS会因为各种费用(广告费之外)而变化得更快。

评论2:

不幸的是,大多数公司都无力朝着你所说的方向发展。虽然开源库和框架在美国公司蓬勃发展,但我们已经预见了联合协议的消亡。集中式专有服务更易于使用。使用SaaS意味着必须聘请IT人员来管理所有事情。坦白来讲,你找不到技术力很强的UNIX系统管理员,这些人都很稀有且昂贵。

我同意本文的看法,从长远来说,拥有基础设施和运行完全开源软件是整体上最好的解决方案,但很多企业都没有长远的打算。如今IaaS(基础设施即服务)很火热。如果做好了,就可以像商品一样出售。尽管AWS和Azure炙手可热,但是还有很多云服务器提供商可以提供Kubernetes、Terraform或其他的基础架构。但是,主要价值都在软件,而不是硬件。而这正是租赁软件非常危险的原因。

你怎么看?

原文:http://esr.ibiblio.org/?p=8338

45K!刚面完 AI 岗,这些技术必须掌握!

https://edu.csdn.net/topic/ai30?utm_source=csdn_bw

【END】

640?wx_fmt=jpeg

 热 文 推 荐 

 

为什么说 5G 是物联网的时代?

☞华为可折叠手机推迟发布;苹果获新专利可隔空操控iPhone;微软不放弃 IE | 极客头条

不止鸿蒙 OS,华为的备用操作系统还有“极光”?

Docker 存储选型,这些年我们遇到的坑

☞荔枝自由?朋友,你实现了吗?

开源要自立?华为如何“复制”Google模式

☞从制造业转型物联网,看博世如何破界

回报率850%? 这个用Python优化的比特币交易机器人简直太烧脑了...

☞老码农冒死揭开编程黑幕:这些Bug让我认输,谁踩谁服!

640?wx_fmt=gif点击阅读原文,即刻免费报名 5G 沙龙!

640?wx_fmt=png你点的每个“在看”,我都认真当成了喜欢

展开阅读全文

Eric Raymond对于几大开发语言的评价

01-06

[size=14px]【译注】:Eric Raymond是开源运动的领袖人物,对于UNIX开发有很深的造诣,主持开发了fetchmail。他的《大教堂与集市》被奉为开源运动的经典之作。下面对几大开发语言的评价非常中肯,是我近年来看到的比较出色的评论。特别是他评价中抱有的那种“简单就是好”的思想,很值得我们深思。rnrn C 语言rn虽说C语言在内存管理方面存在严重的缺陷,不过它还是在某些应用领域里称王称霸。对于那些要求最高的效率,良好的实时性,或者与操作系统内核紧密关联的程序来说,C仍然是很好的选择。rnC良好的可移植性也为它加了分。不过现在很多其他的语言可移植性越来越好,C在这方面的优势可能会逐渐丧失。rn现有的很多程序可以产生非常棒的C代码,比如语法分析器、GUI Builder等,这时候C语言也是有吸引力的,因为你所需要编写的代码只是整个程序的一小部分。rn再有,我们当然应该认识道,C语言对于程序员来说具有无可替代的价值。就我这里讨论的每一种语言而论,只要你发掘的足够深,到最后你会看到它们的内核都是用纯正的、可移植的C写成的。rn到了今天这个时候,我们最好把C看成是UNIX虚拟机上的高级汇编语言。rn就算是其他的高级语言完全可以满足你的工作需要,抽出时间来学习C语言也仍然有益,它能帮助你在硬件体系的层次上思考问题。rn即使到了今天,最好的C语言教程仍然是1988年出版的K&R第二版The C Programming Language.rn总结:C最出色的地方在于其高效和贴近机器,最糟糕的地方在它的内存管理地狱。rnrnC++rnC++最初发布于1980年代中期,当时面向对象语言被认为是解决软件复杂性问题的银弹。C++的面向对象特性看相去使其全面超越了C,支持者认为C++将迅速把上一代语言挤到陈列馆里去。rn但是历史并非如此。究其原因,至少有一部分归咎于C++本身。为了与C兼容,C++被迫作出了很多重大的设计妥协,结果导致语言过分华丽,过分复杂。为了与C兼容,C++并没有采用自动内存管理的策略,从而丧失了修正C最严重问题的机会。rn另外一部分原因,恐怕要算到面向对象身上。看起来OO并没有很好的达成人们当年的预期。我就这个问题调研过,我发现使用OO方法导致组件之间出现很厚的粘合层,并且带来了严重的可维护性问题。今天让我们来看看开放源码社区,你会发现C++的应用还是集中在GUI,游戏和多媒体工具包这些方面,在其他地方很少用到。要知道,面向对象也只是在这些领域被证明非常成功,而开放源码社区的选择,很大程度上体现了程序员的自由意志,而不是公司管理层的胡乱指挥。rn也许C++实现OO的方法有问题。有证据表明C++程序在整个生命周期的开销高于相应的C, Fortran和Ada程序。不过,究竟这是否应该归咎与C++的OO实现上,还不清楚。rn最近几年,C++加入了很多非OO的思想,其异常思想类似Lisp,STL的出现是非常了不起的。rn其实C++最根本的问题在于,它基本上只不过是另一种传统的语言。STL中的内存管理比先前的new/delete和C的方案要好的多,但是还是没有解决问题。对于很多应用程序而言,其OO特性并不明显,相比与C,除了增加复杂度之外没有获得很多好处。rn总结:C++优点在于作为编译型语言,把效率与泛型和面向对象特性结合起来,其缺点在于过于华丽复杂,倾向于鼓励程过分复杂的设计。rnrnJavarnJava的设计很聪明,它采用了自动内存管理,这是最大的改进,支持OO设计带来的好处虽然不那么突出,不过也很值得赞赏,相比C++,其OO设计规模小而且简单 。rn相对于Python而言,Java有一些明显的失误。有些地方设计的还是太复杂,甚至有缺陷。Java的类可见性和隐式scoping规则太复杂了。Interface机制是为了避免多继承带来的问题而设计的,但是要理解和使用它还是挺难。内部类和匿名类导致令人困惑的代码。缺乏有效的析构机制,使得除了内存之外的其他资源(比如互斥量和锁)管理起来很困难。Java的线程不可靠,其I/O机制很强大,但是读取一个文本文件却非常繁琐。rnJava没有管理库版本的机制,从而形式上重蹈了了Windows DLL地狱的覆辙。在类似应用服务器这样的环境里,这引起了大量的问题。rn总体而言,我们可以说除了系统编程和对效率要求极高的程序之外,Java在大部分领域优于C++。经验表明,Java程序员似乎不太容易象C++程序员那样构造过度的OO层,不过在Java中这仍然是个严重问题。rnJava是否优于诸如Perl, Python这样的语言?我们还不是很清楚,很大程度上似乎跟程序规模有关。其擅长的领域基本上于Python相似,在效率上无法跟C/C++相提并论,在小规模的、大量使用模式匹配和编辑的项目里也无法匹敌Perl。在小项目里,Java显得过分强大了。我们猜测Python更适合小项目,而Java适合大项目,不过这一点并没有得到有力的证明。rnrnPythonrnPython是一种脚本语言,可以与C紧密整合。它可以与动态加载的C库模块交换数据,也可以作为内嵌脚本语言而从C中调用。其语法类似C和模块化语言的杂合,不过有一个独一无二的特征,就是以缩进来确定语句块。rnPython语言非常干净,设计优雅,具有出色的模块化特性。它提供了面向对象能力,但不强迫用户进行面向对象设计。其类型系统提供了强大的表达能力,类似Perl,具有匿名lambda表达式,这点又让Lisp黑客们感到亲切。Python依靠Tk提供方便的GUI界面开发能力。rn在所有的解释型语言里,Python和Java最适合多名程序员以渐进方式协同开发大型项目。在很多方面,Python比Java要简单,它非常适合与构造快速原型,这一点使得它对于Java有独特优势:对于那些既不很复杂,又不要求高效率的程序,Python十分合适。rnPython的速度没法跟C/C++相比,不过在今天的高速CPU上,合理地使用混合语言编程策略使得Python的上述弱点被有效地弥补。事实上,Python几乎被认为是主流脚本语言中最慢的一个,因为它提供了动态多态性。在大量使用正则表达式的小型项目,它逊于Perl。对于微型项目而言,shell和Tcl可能更好,Python显得太过强大了。rn总结:Python最出色的地方在于,它鼓励清晰易读的代码,特别适合以渐进开发的方式构造大项目。其缺陷在于效率不高,太慢,不但跟编译语言相比慢,就是跟其他脚本语言相比也显得慢。rn[/size]rn楼主专门转载一些好的文章,希望对坛子的小伙伴有所帮助,与大家共同学习进步! 论坛

Eric Raymond对于几大开发语言的评价(转)

01-02

Eric Raymond对于几大开发语言的评价 rn出处: http://www.catb.org/~esr/writings/taoup/html/ch14s04.html#c_languagernrn【译者注】rnEric Raymond是开源运动的领袖人物,对于UNIX开发有很深的造诣,主持开发了fetchmail。他的《大教堂与集市》被奉为开源运动的经典之作。下面对几大开发语言的评价非常中肯,是我近年来看到的比较出色的评论。特别是他评价中抱有的那种“简单就是好”的思想,很值得我们深思。我特别选译出一些段落,供大家阅读思考。原文参见:http://www.catb.org/~esr/writings/taoup/html/ch14s04.html#c_languagernrnRaymond此文不是在泛泛地去谈语言的优劣,而是要回答一个问题:在UNIX下开发开源项目,如何选择开发工具?我翻译的很零散,建议大家去看原文。rnrnCrn虽说C语言在内存管理方面存在严重的缺陷,不过它还是在某些应用领域里称王称霸。对于那些要求最高的效率,良好的实时性,或者与操作系统内核紧密关联的程序来说,C仍然是很好的选择。rnrnC良好的可移植性也为它加了分。不过现在很多其他的语言可移植性越来越好,C在这方面的优势可能会逐渐丧失。rnrn现有的很多程序可以产生非常棒的C代码,比如语法分析器、GUI Builder等,这时候C语言也是有吸引力的,因为你所需要编写的代码只是整个程序的一小部分。rnrn再有,我们当然应该认识道,C语言对于程序员来说具有无可替代的价值。就我这里讨论的每一种语言而论,只要你发掘的足够深,到最后你会看到它们的内核都是用纯正的、可移植的C写成的。rnrn到了今天这个时候,我们最好把C看成是UNIX虚拟机上的高级汇编语言。rnrn就算是其他的高级语言完全可以满足你的工作需要,抽出时间来学习C语言也仍然有益,它能帮助你在硬件体系的层次上思考问题。rnrn即使到了今天,最好的C语言教程仍然是1988年出版的K&R第二版The C Programming Language.rnrn总结:C最出色的地方在于其高效和贴近机器,最糟糕的地方在它的内存管理地狱。rnrnC++rnC++最初发布于1980年代中期,当时面向对象语言被认为是解决软件复杂性问题的银弹。C++的面向对象特性看相去使其全面超越了C,支持者认为C++将迅速把上一代语言挤到陈列馆里去。rnrn但是历史并非如此。究其原因,至少有一部分归咎于C++本身。为了与C兼容,C++被迫作出了很多重大的设计妥协,结果导致语言过分华丽,过分复杂。为了与C兼容,C++并没有采用自动内存管理的策略,从而丧失了修正C最严重问题的机会。rnrn另外一部分原因,恐怕要算到面向对象身上。看起来OO并没有很好的达成人们当年的预期。我就这个问题调研过,我发现使用OO方法导致组件之间出现很厚的粘合层,并且带来了严重的可维护性问题。今天让我们来看看开放源码社区,你会发现C++的应用还是集中在GUI,游戏和多媒体工具包这些方面,在其他地方很少用到。要知道,面向对象也只是在这些领域被证明非常成功,而开放源码社区的选择,很大程度上体现了程序员的自由意志,而不是公司管理层的胡乱指挥。rnrn也许C++实现OO的方法有问题。有证据表明C++程序在整个生命周期的开销高于相应的C, Fortran和Ada程序。不过,究竟这是否应该归咎与C++的OO实现上,还不清楚。rnrn最近几年,C++加入了很多非OO的思想,其异常思想类似Lisp,STL的出现是非常了不起的。rnrn其实C++最根本的问题在于,它基本上只不过是另一种传统的语言。STL中的内存管理比先前的new/delete和C的方案要好的多,但是还是没有解决问题。对于很多应用程序而言,其OO特性并不明显,相比与C,除了增加复杂度之外没有获得很多好处。rnrn总结:C++优点在于作为编译型语言,把效率与泛型和面向对象特性结合起来,其缺点在于过于华丽复杂,倾向于鼓励程过分复杂的设计。rnrnJavarnJava的设计很聪明,它采用了自动内存管理,这是最大的改进,支持OO设计带来的好处虽然不那么突出,不过也很值得赞赏,相比C++,其OO设计规模小而且简单 。rnrn相对于Python而言,Java有一些明显的失误。有些地方设计的还是太复杂,甚至有缺陷。Java的类可见性和隐式scoping规则太复杂了。Interface机制是为了避免多继承带来的问题而设计的,但是要理解和使用它还是挺难。内部类和匿名类导致令人困惑的代码。缺乏有效的析构机制,使得除了内存之外的其他资源(比如互斥量和锁)管理起来很困难。Java的线程不可靠,其I/O机制很强大,但是读取一个文本文件却非常繁琐。rnrnJava没有管理库版本的机制,从而形式上重蹈了了Windows DLL地狱的覆辙。在类似应用服务器这样的环境里,这引起了大量的问题。rnrn总体而言,我们可以说除了系统编程和对效率要求极高的程序之外,Java在大部分领域优于C++。经验表明,Java程序员似乎不太容易象C++程序员那样构造过度的OO层,不过在Java中这仍然是个严重问题。rnrnJava是否优于诸如Perl, Python这样的语言?我们还不是很清楚,很大程度上似乎跟程序规模有关。其擅长的领域基本上于Python相似,在效率上无法跟C/C++相提并论,在小规模的、大量使用模式匹配和编辑的项目里也无法匹敌Perl。在小项目里,Java显得过分强大了。我们猜测Python更适合小项目,而Java适合大项目,不过这一点并没有得到有力的证明。rnrnPythonrnPython是一种脚本语言,可以与C紧密整合。它可以与动态加载的C库模块交换数据,也可以作为内嵌脚本语言而从C中调用。其语法类似C和模块化语言的杂合,不过有一个独一无二的特征,就是以缩进来确定语句块。rnrnPython语言非常干净,设计优雅,具有出色的模块化特性。它提供了面向对象能力,但不强迫用户进行面向对象设计。其类型系统提供了强大的表达能力,类似Perl,具有匿名lambda表达式,这点又让Lisp黑客们感到亲切。Python依靠Tk提供方便的GUI界面开发能力。rnrn在所有的解释型语言里,Python和Java最适合多名程序员以渐进方式协同开发大型项目。在很多方面,Python比Java要简单,它非常适合与构造快速原型,这一点使得它对于Java有独特优势:对于那些既不很复杂,又不要求高效率的程序,Python十分合适。rnrnPython的速度没法跟C/C++相比,不过在今天的高速CPU上,合理地使用混合语言编程策略使得Python的上述弱点被有效地弥补。事实上,Python几乎被认为是主流脚本语言中最慢的一个,因为它提供了动态多态性。在大量使用正则表达式的小型项目,它逊于Perl。对于微型项目而言,shell和Tcl可能更好,Python显得太过强大了。rnrn总结:Python最出色的地方在于,它鼓励清晰易读的代码,特别适合以渐进开发的方式构造大项目。其缺陷在于效率不高,太慢,不但跟编译语言相比慢,就是跟其他脚本语言相比也显得慢。 论坛

程序员十个糟糕的行为

11-13

这里,我们主要讨论十个糟糕程序员的特征,主要是需要让我们去避免和小心的。rn 1) 情绪化的思维rn 如果你开始使用不同颜色的眼光来看待这个世界的话,那么你可能会成为一个很糟糕的程序员。情绪化的思维或态度很有可能会把自己变成一个怪物。相信你经常可以看到很多很糟糕的程序会使用下面的这些语句:rn 我的程序不可能有这种问题。rn Java就是shit。rn 我最恨的就是使用UML做设计。rn 需求怎么老在变,没办干了。rn 受不了这些人,他们到底懂不懂啊。rn …… ……rn 这些带着情绪化的思维和态度,不但可以让你成为一个很糟糕的程序员,甚至可以影响你的前途。因为,情绪化通常都是魔鬼,会让你做出错误的判断和决定,错误码率的判断和决定直接决定了你的人生。rn 2) 怀疑别人rn 糟糕的程序总是说:“我的代码一定是正确的,我怀疑编译器有问题”,“我这应该没有问题吧,STL库怎么这么难用啊”。我曾经见过有程序员这样使用STL类:map,当他发现这样放入字符串后却取不出来,觉得那是STL库的BUG,然后自己写了一个map!我的天啊!rn 某些时候,过早的下结论是一个很不好的习惯,任何事情都有其原因,只有知道了原因,你才能知道是谁的问题。一般来说,总是自己出的问题。rn 3) 过多关注实现,陷入问题细节rn 有些时候,当我们面对一个问题或是一个需求的时候,糟糕的程序员总是会马上去找一个解决方案或是实现,这是一个很不好的习惯。设计模式告诉我们,“喜欢接口,而不是实现”就是告诉我们,认清问题的本质和特性要比如何实现更重要。rn 对于一个客户的问题来说,首先应该想到的是如何先让用户正常工作,如果恢复正在“流血”的系统,而不是把用户放在一边而去分析问题的原因和解决方案。rn 对于解决一个bug来说,重现bug,了解原来程序的意图是首先重要的事,而不是马上去修改代码,否则必然会引入更多的BUG。rn 对于一个需求来说,我们需要了解的需求后面的商业背景,use case和真实意图,而不是去讨论如果实现。只有了解了用户的真实意图,实现使用,你才能真正如果去做设计。rn 糟糕的程序总是容易陷入细节,争论于如何实现,问题的根本原因,而忽略了比这些更重要的东西。只有看懂了整个地图,你才知道要怎么去走。rn 4) 使用并不熟悉的代码rn 糟糕的程序员最好的朋友是 Ctrl-C 和 Ctrl-V ,有些时候,他们并不知道代码的确切含义,就开始使用它,有证据表明,由拷贝粘贴引发的bug点了绝大多数。因为,代码总是只能在特定的环境下才能正常地工作,如果代码的上下文改变了,很有可能让使得代码产生很多你不知道的行为,当你连代码都控制不住了,你还能编出什么好的程序呢?rn 5) 拼命工作而不是聪明的工作rn 对于糟糕的程序员,我们总是能看到他们拼命地修正他们的bug,总是花非常多时间并重复地完成某一工作。而好的程序可能会花双倍的时间来准备一个有效的开发环境,工具,以及在开发的时候花双倍甚至10倍的时间来避免一些错误。好的程序员总是会利用一切工具或手段来让自己的工作变得更有效率,总是为在开发的时候尽可能得不出错。后期出错的成本将会是巨大的,而且那时改正错误的压力也是巨大的。所以,糟糕的程序通常会让自己进入一种恶性循环,他们看上去总是疲惫的,总是很辛苦的,所以更没有时间来改善,越没有时间来改善,就有越多的问题。所以,拼命工作有些时候可能表明你不是一个好的程序员。rn 6) 总是在等待、找借口以及抱怨rn 当需求不明确的时候,当环境不是很满意的时候,他们总是在等待别人的改善。出现问题的时候,总是在找借口,或是抱怨这也不好,那也不好,所以自己当然就没有做好。糟糕的程序员总是希望自己的所处的环境是最好的,有明确的需求,有非常不错的开发环境,有足够的时间,有不错的QA,还有很强的team leader,以及体贴自己的经理,有足够的培训,有良好的讨论,有别人强有力的支持……,这是一种“饭来张口,衣来伸手”的态度,这个世界本来就不完美,一个团队需要所有人去奋斗,况且,如果什么都变得完美了,那么,你的价值何在吗?driving instead of waiting, leading instead of following.rn 7) 滋生办公室政治rn 有句话叫“丑女多作怪”,意思是说如果一个自己没有真实的能力的话,那么他一定会在其它方面作文章。糟糕的程序员也是这样,如果他们程序编不好的话,比不过别人的话,他们通常会去靠指责别人,推脱责任,或是排挤有能力的人,等等不正常的手段来保全自己。所以,糟糕的程序通常伴随着办公室政治。rn 8 ) 说得多做得少rn 糟糕的程序员总是觉得自己什么都懂,他们并不会觉得自己的认识和知识都是有限的。这就是所谓的夸夸其谈,是的,什么都做不好的程序员能靠什么混日子呢?就是吹啊吹啊。rn 另一个表现方式是他们在评论起别人的程序或是设计,总是能挑出一堆毛病,但自己的程序写得也很烂。总是批评抱怨,而没有任何有建设性的意见,或是提出可行的解决方案。rn 这些糟糕的程序员,总是喜欢以批评别人的程序而达到显示自己的优秀。rn 9) 顽固rn 当你给出一打证据说明那里有一个更好的方案,那里有一个更好的方向的时候,他们总是会倔强的认为他们自己的做法才是最好的。一个我亲身经历的事例就是,当我看到一个新来的程序在解决一个问题的时候走到了错误的方向上时,我提醒他,你可能走错了,应该是另外那边,并且我证明了给他看还有一个更为简单的方法,有。然而,这位程序员却告诉我,“那是我的方法,我一定要把之走下去,不然我会非常难受”,于是,在三天后的代码评审中,在经过顽固地解释以及一片质疑声中,他不得不采用了我最先告诉他的那个方法。rn 这些程序员,从来不会去想,也不会去找人讨论还有没有更好的方法,而是坚持自己的想法,那怕是条死路都一往直前,不撞南墙永不回头。rn 10) 写“聪明”的代码他们写出来的代码需要别的同事查看程序语言参考手册,或是其程序的逻辑或是风格看上去相当时髦,但却非常难读。代码本应该简洁和易读,而他们喜欢在代码中表现自己,并尝试另类的东西,以显示自己的才气。是的,只有能力有问题的程序员才需要借助这样的显示。rn 记得以前的一个经历,一位英语很不错的程序员加入公司,本来对我们这些英语二把刀来说,我们喜欢看到的是简单和易读的英文文档,然后,那位老兄为了展示他的英语如何牛,使用了很多GRE中比较生僻的短语和词汇。让大家阅读得很艰苦。最有讽刺意味的是,有一位native的美国人后来在其邮件中询问他某个单词的意思。呵呵。rn 你是一个糟糕的程序员吗?欢迎你分享你的经历。 论坛

没有更多推荐了,返回首页