推荐
- njzdl 财富等级:
|
这是本非常非常好的书,33位作者,33个来自不同开发领域的专业经验,33种不同的意见。你想知道牛人们对代码之美是怎么想的吗. 当初朋友介绍这本书给我的时候,我顿时产生了一种恍然大悟的错觉:这才是我真正想读的书的样子啊,难道技术书籍本来不就应该是这个样子的吗?就一个主题,让几十位领域大牛各抒己见,简直完美符合了我内心对“书”的定义。
|
|
此评论对你有用
没用
|
| |
|
|
|
oeskf
- oeskf 财富等级:
|
好书! 值得一读`` 感谢分享 这是本非常非常好的书,33位作者,33个来自不同开发领域的专业经验,33种不同的意见。你想知道牛人们对代码之美是怎么想的吗. 当初朋友介绍这本书给我的时候,我顿时产生了一种恍然大悟的错觉:这才是我真正想读的书的样子啊,难道技术书籍本来不就应该是这个样子的吗?就一个主题,让几十位领域大牛各抒己见,简直完美符合了我内心对“书”的定义。
|
|
此评论对你有用
没用
|
| |
|
代码之美Beautiful Code(中文版)(9.22日china-pub全国独家首发)
- laynepeng 财富等级:
|
|
很经典,但是全部读懂的话,比较困难。。。
|
|
此评论对你有用
没用
|
| |
|
代码之美 (Beautiful code 中文版)
- winjack11 财富等级:
|
|
想读,不过有朋友知道这本书和《代码大全》相比,各有什么特点或者说长处?
|
|
此评论对你有用
没用
|
| |
|
代码之美Beautiful Code(中文版)(9.22日china-pub全国独家首发)
- yubanzhi 财富等级:
|
|
很想读一读!
|
|
此评论对你有用
没用
|
| |
|
|
|
代码之美Beautiful Code(中文版)(9.22日china-pub全国独家首发)
- v2sun 财富等级:
|
|
想读!!!
|
|
此评论对你有用
没用
|
| |
|
代码之美Beautiful Code(中文版)(9.22日china-pub全国独家首发)
- aiyungui 财富等级:
|
|
很独特 对学习编程是一个很大的助手
|
|
此评论对你有用
没用
|
| |
|
代码之美Beautiful Code(中文版)(9.22日china-pub全国独家首发)
- zrz512 财富等级:
|
|
经典之作,第一次实在书城看到的。虽然能看懂的不太多,但是是一种把编码当做艺术介绍的书
|
|
此评论对你有用
没用
|
| |
|
|
|
|
|
代码之美Beautiful Code(中文版)(9.22日china-pub全国独家首发)
- jiangtao 财富等级:
|
|
介绍是不错,价格也不低
|
|
此评论对你有用
没用
|
| |
|
|
|
代码之美Beautiful Code(中文版)(9.22日china-pub全国独家首发)
- xtconan 财富等级:
|
|
放在书架上。。。
|
|
此评论对你有用
没用
|
| |
|
代码之美Beautiful Code(中文版)(9.22日china-pub全国独家首发)
- prog_6103 财富等级:
|
|
有点散,不过有味道~~
|
|
此评论对你有用
没用
|
| |
|
代码之美Beautiful Code(中文版)(9.22日china-pub全国独家首发)
- ice_m86 财富等级:
|
|
想看看
|
|
此评论对你有用
没用
|
| |
|
|
|
代码之美Beautiful Code(中文版)(9.22日china-pub全国独家首发)
- jinxfei 财富等级:
|
据说很好,要拜读一下。
实际上从转型的角度来讲,不应该再看这类的书,但如果将来要求团队成员看,自己也应该有所了解。
|
|
此评论对你有用
没用
|
| |
|
|
|
|
|
代码之美Beautiful Code(中文版)(9.22日china-pub全国独家首发)
- sunlair 财富等级:
|
|
不错
|
|
此评论对你有用
没用
|
| |
|
代码之美Beautiful Code(中文版)(9.22日china-pub全国独家首发)
- JianCaesar 财富等级:
|
|
我喜欢这本书的立意,但是没有读过,如果有机会读再来评论,谢谢!
|
|
此评论对你有用
没用
|
| |
|
|
|
代码之美Beautiful Code(中文版)(9.22日china-pub全国独家首发)
- lsxjl 财富等级:
|
|
爱不释手的书
|
|
此评论对你有用
没用
|
| |
|
《代码之美》应该怎样读
- chengrong123 财富等级:
|
《代码之美》应该怎样读 我看到有些读者认为《代码之美》讲解了10多种编程语言,我只会使用了1或者2种编程语言,恐怕看不懂。还有些读者认为《代码之美》并没有讲解很多关于代码的事情,也没有发现“美”。 在这里我想谈谈,我对《代码之美》的看法: 《代码之美》是一本怎样图书? 在本书第32章开头写道:“作者将要讨论的东西大多数是关于软件的设计和架构,而不是单纯的代码。”所以,不要将《代码之美》看成一本讲解代码或者讲解编程语言的图书。 这本书的原意是讲解软件设计及架构,同时,也探讨了通过怎样的设计及架构将项目做得更佳漂亮。本书的精华是展现38位作者遇到问题后,是怎样解决这些问题的。同时,我也发现:代码只是描述这些作者思想的方法。 代码的“美”需要慢慢地培养,虽然,目前我做不出“美”,但是我必须要了解什么是“美”,其实,这本书是适合各个层级的程序员看,而且是越是初级的程序员越要看,要知道写出“漂亮”的代码是一种习惯。 《代码之美》能带给我什么? 我把《代码之美》当成一本休闲的图书来看,没事的时候可以翻看,我知道自己不可能很快的了解内容,也没有关系。我想主要是自己还没有遇到相关的问题,如果哪一天遇到像作者那样的问题,就会与作者产生共鸣想到办法啦。
|
|
此评论对你有用
没用
|
| |
|
代码之美Beautiful Code(中文版)(9.22日china-pub全国独家首发)
- hb_zxl 财富等级:
|
初步感觉没有书评写的那么好。 最近很难静下心来读,这本书写得太散,很多主题我不是太关心,所以收获不大,也许我还没有达到高手境界吧
|
|
此评论对你有用
没用
|
| |
|
代码之美Beautiful Code(中文版)(9.22日china-pub全国独家首发)
- citysheep 财富等级:
|
|
会改变你的思维,绝对值得一读二读三读
|
|
此评论对你有用
没用
|
| |
|
建议读
- jimeshengxian 财富等级:
|
[转载]这是本非常非常好的书,33位作者,33个来自不同开发领域的专业经验,33种不同的意见。你想知道牛人们对代码之美是怎么想的吗. 当初朋友介绍这本书给我的时候,我顿时产生了一种恍然大悟的错觉:这才是我真正想读的书的样子啊,难道技术书籍本来不就应该是这个样子的吗?就一个主题,让几十位领域大牛各抒己见,简直完美符合了我内心对“书”的定义。
|
|
此评论对你有用
没用
|
| |
|
|
|
|
|
代码之美Beautiful Code(中文版)(9.22日china-pub全国独家首发)
- itcj10 财富等级:
|
|
代码之美
|
|
此评论对你有用
没用
|
| |
|
代码之美Beautiful Code(中文版)(9.22日china-pub全国独家首发)
- tanaaa84 财富等级:
|
|
代码之美Beautiful Code(中文版)
|
|
此评论对你有用
没用
|
| |
|
代码之美,确实很美
- xfjJason 财富等级:
|
|
代码之美,确实很美.这本书翻译得很不错,很有水准.读起来也很流利.难怪呀,一个翻译团队翻译出来的.向团队所有的牛人致敬.哈哈...
|
|
此评论对你有用
没用
|
| |
|
《代码之美》不买的理由
- chengrong123 财富等级:
|
|
好书终于要出版了,大家千万不要买咯,给你10个不要买的理由: 不读《代码之美》的10大理由: 10. 危及感情:爱不释手,容易专注,老婆/女友会怀疑我有外遇。 9. 影响心情:从此我总会发现很多不美的代码。 8. 剥夺乐趣:编程的乐趣有很大一部分在于不停地追求完美。 7. 备受压榨:工作效率大大提高,老板只会给我更多工作来做。 6. 各有所爱:我就喜欢通过海啃书山来了解大师的精髓。 5. 分裂社区:只能让读过本书的人先牛起来,在开发界造成严重的“菜-牛”差距。 4. 没有需求:最优秀的开发者根本不需要最优秀的书。 3. 诱发犯罪:不管我买几本,都会被同事偷走甚至抢走。 2. 传染性强:一旦我买了,其他同事肯定也会买。 1. 无知者无畏:不读本书的最大理由其实只有一个,那就是你没有读过。
|
|
此评论对你有用
没用
|
| |
|
等度的流明-代码之美
- snakeguang 财富等级: 
|
等度的流明
——代码之美?序
一
我上一次印象深刻的美的体验,大概已经是在十年之前了,那只是在午后睡醒,面对窗外的一棵大梧桐树时的感觉。不过这并不是说我这十年来都只看到了丑的事物,而是说我已经忘了去观察既已存在的美。 直到我拿到这本《代码之美》,我忽然地回到了那种仰望着星星烁耀的夜空,或低头沉思于一两句大家文字的日子里。那时刻我既不是在思考,也不是在分析,更不是在解释,而只是在感受自然的、文字的,或将自然蕴于文字之中的,美。
二 有一本书开启了一个时代,而我们如今仍然在这个时代之中而不知觉于这本书的深远影响,那是三位图灵奖得主合著的《结构程序设计》(1)。其中Dijkstra将人“理解一个程序的种种思维方法”归为三种:枚举、数学归纳和抽象。 显然Wirth先生更为深层地看到了程序的本质,他说“程序=算法+数据结构”(2)。他揭示了这样一个事实:一个未知的、无序的世界是不可能实现“程序”的,于是我们抽象它——使它成为结构,或者对象,或者网,或者某个相对规则的事物。然后,我们再着之以“算法”。
《代码之美》这本书,三十八位大师,在三十三章的内容中详细讨论了代码中抽象的过程、算法的过程和编程的过程。显然的,这些正是程序中最深刻的美。如同花之蕊,叶之脉,以及维系花蕊叶脉的美的,那些汁液。这种对美的触及,使他在我面前闪耀着与前两本书等度的流明。
三 “只有在不仅没有任何功能可以添加,而且也没有任何功能可以删除的情况下,设计师才能够认为自己的工作已臻完美。”(3)然而编程的过程呢?我们最初只是想实现一个功能。但为了实现它,我们写了一段功能代码、一段测试代码、一段功能代码的配置代码,一段功能代码的配置代码的测试代码…… 如此往复不休。
我们回到原始的问题,原本只是要做一个“实现某项功能”的代码,我们却为何把代码做到了“往复不休”的绝地?
或者你做的事情并不完美,但是你应该知道所谓完美的终极。代码要不停的测试,以及为测试代码再写测试代码,这一过程也不是美的。或许你认为它“必须”,但你应知道它终究不美。
四
大师们也并没有创生完美的能力,他们只是在一步步地进行着。在这本书里,Adam Kolawa告诉你的,Lincoln Stein告诉你的,以及Elliontte Rusty Harold等等告诉你的,就是那经年累月地或亦步亦趋地进行过程,和那个“终极完美”的定义。
这只是过程和隐于过程中对美的追求。而“美”是什么,还是在你的心底。你心中原本就没有美的感受,如何写得出美的代码?所以代码写到烂处,写到心胸滞涩处,便不如寻一清静所在,捧《代码之美》一册,回顾一下,品味一下,吐故纳新一下了。
看得多远,取决于你站得多高;要想成为他们,你得先知道他们。
这就是我的建议了。
注: (1) 《结构程序设计》出版于1972年,作者分别是1972、1980、2001年图灵奖得主Edsger W.Dijkstra、 C.Anthony R.hoare、Dahl。
(2) 《算法+数据结构=程序》出版于1975年,作者Pascal之父Niklaus Wirth,是1984年图灵奖得主。
(3) 出自Antoine de SaintExupery,法国战士与文学家。本书的第3章中Jon Bentley引用。
|
|
此评论对你有用
没用
|
| |
|
代码之美,自由之美
- snakeguang 财富等级: 
|
《代码之美》的推荐序
作者:徐继哲2008年9月7日 下午 北京
想要向世人展示源代码之美,毫无疑问,大家都需要能够获得源代码,否则一切无从谈起。这让我很自然地想到了发轫于1983年的自由软件运动。自由软件运动认为软件应该是自由的,每个人都具有运行、学习、修改和再发行软件的自由。25年过去了,这一切已经成为现实。《代码之美》一书的许多章节就是在讨论那些被广泛使用的自由软件,涵盖了操作系统、计算机语言和开发工具和企业软件等领域。 在自由软件运动中发展起来的对称版权(copyleft)思想和GNU GPL软件许可证等从法律层面保证了一个自由软件可以继续自由下去,保证了每一个人都可以获得自由软件,当然也包括源代码。但如何看待软件和源代码仍然是一个关键问题。在主流(技术)媒体上整天讨论“IT民工”和“软件蓝领”的今天,能从美学的角度来思考软件和源代码,对于整个行业来说,实在是幸运之举。 凡高创作的《向日葵》和Richard Stallman创作的GNU Emacs有什么区别呢?一个是没有替代品的艺术品,一个是有着无数替代品的(软件)工具,这就是区别。但进一步思考,我们不难发现:“正如一个独一无二的艺术品的创作过程充斥着大量的技术细节,在创作一个可替代的(软件)工具的过程中,作者也付出了独一无二的智慧。”所以,当我们在挖掘软件之美的时候,绝不能像欣赏艺术品那样站在外面,而是要深入其内部,---源代码,去学习、体会、修改和赞美。即,艺术之美存于结果和外在;软件之美存于过程和内在。 但将30多个技术精英的智慧汇集到一本书里是不是一个好主意呢?《代码之美》一书勇敢地做了这个尝试。在我的阅读过程中,沮丧、无奈和激情交替出现。从技术层面看,此书的内容跨度非常之大,沮丧和无奈在所难免。但当看到如此多的技术精英投入到各自的领域去研究、探索和实践,不由得心潮澎湃,这和我的内心世界产生了共鸣。 从美学的角度去阅读此书吧,她将唤醒你的激情,一种成为真正的黑客(hacker)所必备的激情! Happy hacking! 徐继哲 2008年9月7日 下午 北京 哲思自由软件社区 创始人 http://www.zeuux.org
|
|
此评论对你有用
没用
|
| |
|
向大师学习美
- snakeguang 财富等级: 
|
向大师学习美
我1989年参加高考时,总分120分的语文才考了71分,这最弱一环差点造成致命打击。最害怕的是写作文,记得当年的题目是写一封信,在右江盆地高温的教室里,我写得汗都滴在试卷上。没想到,后来看的东西多了,“不会作诗也会吟”,居然也能接杂志和出版社的约稿,写一些文章和序言之类。 翻开本书第29章,Ruby之父Yukihiro Matsumoto(松本行弘)说:Treating Code As an Essay。写代码如同写文章一般,多看多研究大师的作品,才能够信手拈来,写出美丽的代码。本书就是33位大师的倾情之作。 本书并不限于讨论某一种语言的技巧,你能看到大师们使用现在流行的Java、Ruby,也能看到历史悠久的Fortran。讨论的领域从Linux内核,到NASA火星探测器、ERP系统,让我们从不同角度来体会代码之美。 美除了让人欣赏,还能带来金钱。因北京奥运的成功,博尔特的速度之美估计价值上千万美元。美丽的软件也一样。一些软件公司,公司人少且稳定,多年来专注于做某一个小领域里的软件,对软件的打磨可谓是精雕细琢,美丽软件带来的利润自然也很可观。比起那些靠低人力成本、低价格在市场上打拼的“程序员民工”公司,他们要活得滋润得多,安全得多。 美还可以作装饰。就算没时间看,也买一本装点一下。书架上的《人月神话》、《计算机程序设计艺术》摆设了好些年,该换一本《代码之美》了。
UMLChina首席专家 潘加宇
|
|
此评论对你有用
没用
|
| |
|
享受代码之美
- snakeguang 财富等级: 
|
享受代码之美
熊节
“希望写出漂亮代码的开发者可以向艺术家们学习一些东西。画家常常放下手中的画笔,然后远离画布一段距离,围着它转一转,翘起脑袋,斜着看看,再从不同的角度看看,在不同的光线下看看。在寻求美的过程中,他们需要设计这样一些视角并使它们融为一体。如果你的画布是个集成开发环境(IDE)而你的媒介就是代码,想一想,你如何做到离开画布一段距离,用挑剔的眼光从不同的视角来审视你的作品?──这将使你成为一个更优秀的程序员,并帮你写出美丽的代码。” 写这段话的Alberto Savoia在他的文章里真的没有讲什么令人敬畏的高技术或是大架构,他讲的是每个计算机系的大二学生都熟悉的二分查找。所以Savoia真的是在讲如何写出漂亮的代码,所以才选择了这么一个所有人都清楚得不能再清楚的例子。你会觉得这种事情都是些不谙世事的小程序员才会热衷于干的吧?可这位Savoia却是从Google离职以后开创了Agitar Software公司(http://www.agitar.com/)的不折不扣的创业者。有意思吗?一个胡须花白、在这个行业里厮混了数十年、拥有自己公司的老家伙,还在乐此不疲地谈论“漂亮的代码”。 这本《代码之美》就是由三十多篇像这样有意思的文章组成的。像Brian Kernighan、Tim Bray、Charles Petzold、Douglas Schmidt、Yukihiro Matsumoto这样的名字,你甚至很难想象他们同时出现在同一本书上。或许也只有“漂亮的代码”这样的话题才能激起他们共同的兴趣。于是就有了这本了不起的书:从正则表达式匹配器到图像处理,从通信到基因排序,这些可能是世界上最优秀的程序员毫不吝啬地向读者展示:不论面对什么问题、使用什么语言,代码的美感都是始终存在的,而且这种美感应该是程序员毕其一生不懈追寻的。 作为《重构》的译者,不时有人会问我一些关于重构的问题,其中一个问题让我最感为难:为什么要这样做?真的,如果不是要修改代码,也不是要添加功能,为什么要把这段代码抽取出来呢?让每个方法都保持5行以内的长度到底有什么好处呢?这种时候与其说是有什么利弊权衡,毋宁说就是为了让代码“更漂亮”。当然了,在大部分时间里,软件开发是一项集合了科学、工程和服务的工作,但──至少在我们的内心深处──它多少还有那么一点艺术的成分。除了完成任务以外让自己手上的代码更具美感,也算是对自己作为程序员的梦想的小小坚持吧。 所以,既然你已经拿起了这本书,就暂时放开那些功利的目标吧──别误会,这可不是一本没用的书,通过阅读这些“高手”们的编程心得,对自己的能力提升就算不能立竿见影至少也有潜移默化之功。但那也只是装珍珠的盒子而已。在一个安静的周末,给自己泡上一杯清茶,跟着三十三位顶尖高手畅游在代码世界,在他们的指引下遍赏代码之美,这才是作为一个程序员最大的享受呢。
|
|
此评论对你有用
没用
|
| |
|
|
|
三十三位顶尖专家聚首Beautiful Code
- 221.223.19.*
|
这是一本独特的书。
其英文封面上本应写着作者的位置写的却是“Edited by Andy Oram and Greg Wilson”。Edited?那作者呢?
实际上,这本书有33位作者!
现在你知道为什么封面上不列作者了吧?一是列不下,二来更重要的是每位作者都是一个领域里的大牛,怎么排列? 每位作者都贡献了一章内容,所以本书一共有33章。这种做法带来了三个重要的结果: <!--[if !supportLists]-->· <!--[endif]-->每位作者都是大牛,所以每个人都知道自己在说什么。
<!--[if !supportLists]-->· <!--[endif]-->每位作者都将自己心目中对于“美丽的代码”的认识浓缩在一章当中,张力十足。
<!--[if !supportLists]-->· <!--[endif]-->心理学上有一种说法叫做联合评估与单独评估,即如果你单独评估一样东西,是难以把握其好坏的,然而如果将它跟同类东西一比,就能够做出更准确的判断。33位大牛,每个人对代码之美都有自己独特的认识,现在一览无余地放在一起,对于热爱程序的每个人都不啻一场盛宴。
当初朋友介绍这本书给我的时候,我顿时产生了一种恍然大悟的错觉:这才是我真正想读的书的样子啊,难道技术书籍本来不就应该是这个样子的吗?就一个主题,让几十位领域大牛各抒己见,简直完美符合了我内心对“书”的定义。
而且,编程是计算机行业的核心活动,而代码则是编程活动的核心,代码之美一直一来都是一个玄妙永恒的话题,如果让我选一个主题来请教这些作者,我还真想不出比这更好的主题!
所以,我就迫不及待地把这本书介绍给了更多的朋友。
所以,我同样也已经迫不及待地想要告诉你,这本书的作者都有哪些人了:
Jon Bentley:久负盛名的《Programming Pearls》(《编程珠玑》)的作者。在斯坦福获得学士学位,在北卡罗莱纳获得硕士和博士学位。继而在卡内基梅隆执教6年。贝尔实验室前研究员,西点军校和普林斯顿的访问教授。
Brian Kernighan:C语言圣经K&R C(《C程序设计语言》)和《程序设计实践》两本不朽著作的作者,他的书被翻译成近30种不同的语言。
Charles Petzold:经典的《Windows程序设计》影响了整整一代程序员,被奉为Windows编程圣经。而他的另一本经典著作《编码的奥秘》则另辟蹊径,由浅入深地将计算机最深层的奥秘娓娓道来。
Tim Bray:XML创始人之一。
Yukihiro 'Matz' Matsumoto:Ruby之父。
Douglas C. Schmidt:著名的C++跨平台开源框架ACE的设计者,《C++网络编程》卷I,卷II的作者。
Jeff Dean:天才架构师,Google大型并发编程框架Map/Reduce作者。
Diomidis Spinellis:两届Jolt大奖获主,分别以《Code Reading》和《Code Quality》获2004 和2007年的Jolt大奖。
Simon Peyton Jones:Haskell语言核心人物之一,并领导设计了著名的Haskell编译器GHC。
Douglas Crockford:JSON发明者,Javascript领域大牛,写了广为流传的《Javascript,世界上最被误解的语言》。
Bryan Cantrill:著名的DTrace的作者之一;之前是Sun杰出工程师,主要工作领域为Solaris内核开发...
Greg Kroah-Hartman:目前的Linux内核维护者,经典的《Linux Device Drivers》的作者。
Andreas Zeller:大名鼎鼎的GNU DDD可视化调试器的作者,著作《Why Programs Fail》获得2006年Jolt生产效率大奖。
Sanjay Ghemawat:大规模分布式文件系统Google FileSystem(GFS)的主要作者(GFS是Google的基石之一),同时也是Google Map/Reduce以及Google BigTable的作者之一。
...
(一个完整的作者列表见于书后)
如今这些如雷贯耳的名字居然出现在同一本书中,怎能不令人兴奋?!
你是程序员吗?你对代码之美的认识是什么?33位作者,33个来自不同开发领域的专业经验,33种不同的意见。你想知道牛人们对代码之美是怎么想的吗?
其实,这本书最奇妙的地方还不在于这一点,而在于,如果你知道这些作者的名字,你肯定会忍不住去看一看。如果你不知道这些作者的名字,你更加会忍不住去看一看。因为你知道这些人的观点肯定不会让你失望!
最后,还有一个更大的好消息, O’Reilly出版社表示还会继续出书的第二版,邀请更多的牛人!
其实,“Beautiful Team”还有另一个含义:我们有一个漂亮的翻译团队;此外团队组建的过程也很是有趣。在此就留一个悬念,稍后会公布!
注:由于我只是译者之一(我们的翻译团队里面有一堆牛人),所以这篇仅代表我个人意见
|
|
此评论对你有用
没用
|
| |
|