码迷,mamicode.com
首页 > 其他好文 > 详细

大话程序界+推荐书籍!

时间:2016-09-06 15:23:05      阅读:163      评论:0      收藏:0      [点我收藏+]

标签:

  作为中国人,有着优良传统文化,在IT界中,中国的程序员也总是想着创新,专研,提高程序代码,为什么却没有想着提高自己的视野、思维和经验呢?今天,现编就来大胆一说,和推荐给各位一些程序员很有用的书籍介绍!

  我大胆把程序员分为两种——工人与艺人。

  工人,类似于泥瓦匠,按部就班,可以做好本职工作,但不具备创造性,在编程时也没有考虑系统的架构、各模块之间的分工等。这种人往往死守某一种语言或技术,不肯接纳新思想,也拒绝接受新的技术。其最大的特点就是,写出的代码能勉强能运行,但没有经过任何重构,代码完全是一团错综曲折的杂酱面。这种工人有许多称呼,如码农、IT民工。

  艺人,即是艺术家。我们常听见有人说编程是一门艺术,他们口中所说的就是这类人。艺人级别的程序员,所写的代码精炼简洁,架构优良,各模块分工明确且结构清晰。他们选用某种语言,不是因为它流行,而是因为它适合,因此他们不会拘泥于语言,追求完美与极致。这种艺人也有许多称呼,如黑客、极客。

  并局限于某门编程语言,并实现工人到艺人的华丽转变。按照这个标准,我推荐了以下书籍:

  1.《代码的未来》:松本行弘,编程的本质是思考。

  关于作者:Ruby之父

  编程的本质是什么?

  编程的本质是思考。

  什么又是编程?

  创造出一种人类和计算机都能够理解的语言(编程语言),并通过这样的语言将人类的意图传达给计算机,这样的行为就叫做编程。

  我是在大学在读到这本书的,在此之前,我已有了3年多编程经历。但不可避免的,在读到这本书之前,我对编程的理解却仍然淡薄。

  我曾经在学习汇编语言的过程中,得到了老师的善意提醒:“汇编语言已经过时了,没多少人用,现在主流的语言是JAVA,你应该学习JAVA。”

  我非常困惑,因为在此之前,我同样得到另一个人的提醒:“语言只是一种工具,真正的高手,不管用什么编程语言都一样。”

  刚学的语言却早已过时,刚进入正轨却要重新开始......你很难想象当时的我有多么低落。

  这,还不是最可怕的。

  可怕的是老师还告诉你:“现在都是可视化编程,不用再写那么多代码,需要什么直接用就好了,就像搭积木一样。未来的话,可能只需要你把你的需求告诉编程软件,它就自动为你生成代码了。”

  恐惧!

  我第一次感觉到学了编程没有任何意义,因为我跟不上时代发展的潮流,世界每一天都在变化,并且,很快就会将我抛弃。

  如果你对此没有太多感触,不以为然,那么,你可以看看现在层出不穷的新语言、新技术、新思想,你觉得你曾经学的东西还能支撑多久?而智能程序替换掉你的那一天,又会在什么时候到来?

  我的恐惧是在读到这本书之后才烟消云散,或许是随着接触的编程语言增多,我对编程有了更多的认识,又或者,是这本书给了我一个善意的谎言,让我有了继续坚持下去的勇气。

  编程的本质是思考。

  这意味着,语句中是用for还是while,编程语言是采用面向过程还是面向对象,对话框是放置到左边还是右边......这一切一切的背后,都是思考。

  换句话说,无论你用多么高效的语言,多么强大的框架,多么牛逼的编程思想,该写的代码还是要写,该解决的问题还是要解决。最终,编程还是得靠你的大脑思考,思考,就是编程的本质。

  至于仍在担心的问题:未来的某一天,程序员这个职业会被更智能的编程软件(AI)替代,从此消亡。

  这个不是放弃编程的理由,因为既然AI能够替代程序员,那么也就意味着它能替代掉更多是人。要担心的不是我们程序员应该怎么办,而是,我们人类该怎么办?

  2.《编程高手箴言》:梁肇新,做一个程序员一定要有耐心。

  关于作者:豪杰超级解霸作者(过去的豪杰超级解霸 == 现在的暴风影音)

  程序与软件是一样的么?

  程序不等于软件。

  程序与软件的区别是什么?

  程序要变成软件,这中间是一个商业化的过程。

  在此之前,你可能从某些方面知道了它们的区别:软件 = 程序 + 文档;规模小的是程序,规模大的是软件;写的差的是程序,写的好的是软件......

  但是,这是第一本从商业的角度探讨程序与软件区别的书。不仅如此,这本书还在编程人员的编程习惯、学习态度、个人发展、产品商业化等方面都给出了可供参考的见解。

  如果你需要的不是那种完全是讲解技术的书籍,而是能够拓展你的思维,那么这本书或许能够给你更多的思考。

  (注意:本书涉及到的技术较为底层,且同其他编程书籍一样,技术讲解占据很多)

  3.《UNIX编程艺术》: Eric S. Raymond ,KISS。

  关于作者:《大教堂与集市》的作者

  UNIX的哲学是什么?

  一个程序只做一件事,并做好。

  程序要能协作。

  一个好的程序应该遵循哪些原则?

  简洁原则:设计要简洁,复杂度能低则低 。

  吝啬原则:除非确无它法,不要编写庞大的程序。

  缄默原则:如果一个程序没什么好说的,就保持缄默。

  优化原则:雕琢前先得有原型,跑之前先学会走。

  扩展原则:设计着眼未来,未来总比预想快。

  KISS原则:Keep It Simple, Stupid!

  听说Unix/Linux不错,作为一个合格的程序员应该去尝试一下。

  于是你下载安装了Ubutu/RedHat,打开了桌面环境,单击双击,复制粘贴。

  呃,Unix/Linux相比Windows,没什么不同嘛!

  Unix相对于Windows,其最大的特色,我觉得就是程序之间的协作,也就是管道。围绕管道而设计出来的程序,便会顺理成章的去遵循上面提出的几个原则。

  如果你认同Linux的设计哲学,那么你可以看看这本书。

  这本书在模块化、文本化、配置、接口、复杂度、优化、可移植性等方面,都提供了Unix/Linux世界所积累的宝贵经验。

  好的程序可以经受时间、平台与用户的考验,好的编程思想可以经受实践的检验。

  附:

  不懂UNIX的人注定最终还要重复发明一个蹩脚的Unix。

  Those who do not understand Unix are condemned to reinvent it, pooly。 —— Usenet 签名, Henry Spencer

  4.《程序员修炼之道:从小工到专家》:Andrew Hunt / David Thomas,死程序不说谎。

  “拿来就用”主义应该受到鄙视吗?

  你不是在窥探,你是在向他们学习。而且要记住,访问是互惠的——不要因为别人钻研你的代码而苦恼。

  怎样看待抽象与细节?

  将抽象放进代码,细节放进元数据(put abstractions in code, details in matadata) 。

  复用,俗称Copy,文人称之为拿来主义。在站在巨人的肩膀上与独立自主的争论中,复用与造轮子各自朝着不同的方向快速发展着。

  有一种观点认为一个好的程序员应该自己从底层做起,而不是去复制粘贴别人的代码。但随着开源运动的崛起,以及程序员所做的大量重复工作,迫使我们对复用有了更深的认识。

  这本书可以看作是对《UNIX编程艺术》的补充,是对编程好程序所应遵循原则的进一步阐述。同时相比上一本书,本书更着重于实际的建议:如何划分调用者与被调用者之间的职责范围,如何处理传递给函数的参数,如何正确调试等。

  在用户需求的看法上,本书不同于其他主流观点,推崇挖掘需求——不要搜集需求——挖掘它们。(don‘t gather requlrementsdig for them) 。

  它不是字典般的代码大全,却更像是百科全书般的编程指南。

  5.《重构:改善既有代码的设计》: Martin Fowler,事不过三,三则重构。

  关于作者:协助创作了“敏捷软件开发宣言”

  什么是重构?

  重构,是这样一个过程,在不改变代码外在行为的前提下,对代码做出修改,以改进程序的内部结构。

  为什么要重构?

  任何一个傻瓜都能写出计算机可以理解的代码,唯有写出人类容易理解的代码,才是优秀的程序员。

  我对大学编程类课程的一个感受时,大学老师不会讲授软件调试。

  调试对软件开发而言,无疑是非常重要的一个步骤,因为它能发现软件中存在的很多语法问题与逻辑问题。

  但就算如此重要的调试,也只是发现了代码的表面问题,更深层次的架构设计之类,仍需要借助与重构。

  重构,通俗的称修改代码,或者代码优化。

  在多数程序员处于匠人级别,是因为他们所写的代码仅仅是勉强能够运行,没有达到优化原则,在进阶艺人的台阶上,止步不前。

  开源软件之所以在软件质量上通常都远高于闭源软件,很重要的一个原因是开源软件有更多的人参与软件的重构工作,不断修正软件中不完美的设计或组件。

  重构不是修复Bug,而是一个把“玩具”变为“可用产品”的优化过程,琢石成器!

  重构也不是随便看到哪里不顺眼就立即去修改,它有一些必须遵循的基本规范,其中最重要的一个就是“在不改变软件可观察行为的前提下改善其内部结构”。

  这也意味着,使得在重构完成后,不会影响软件的正常使用,同时尽量减少重构之后的代码调试。

  由于每次修改的幅度都很小,所以任何错误都很容易发现,你不必耗费大把时间调试。

  遵循合适的重构规范,重构之后的软件,在用户眼中它与重构前的软件没有任何差异,但在代码内部,软件小麻雀却早已“飞上枝头变凤凰”,变得更加强健、简洁、易于维护等。

  同时,重构也不是一个永无止境的过程,要懂得适可而止。在重构的过程中,要时刻谨重构的目的是为了解决软件结构中的问题,而不是为了编程完美的代码。

  单凭对完美的追求无法写出实用的代码,而“实用”是软件压倒一切的要素。

  附:

  我不是个伟大的程序员,我只是个有着一些优秀习惯的好程序员。

  —— Kent Beck

  6.《人月神话》: 弗雷德里克.布鲁克斯, 向进度落后的项目中增加人手,只会使进度落后。

  关于作者:主持开发OS/360

  如何处理大型项目中的管理问题?

  我相信由于人员的分工,大型编程项目碰到的管理问题和小项目碰到的管理问题区别很大;我相信关键需要的是维持产品自身和概念完整性。

  为什么我们时常陷入产品延期的僵局?

  系统编程的进度安排背后的第一个错误的假设是:一切都将运作良好,每一项任务仅花费它所应该花费的时间。

  这是一本被软件开发人员(特别是项目管理人员)推崇的神书,能够获得如此尊称的书并不多,除《人月神话》之外,《计算机编程艺术》也是其中之一。

  我在多年前曾接触到这本书,当时我并没有任何团队开发经验,读这本书只是它的名声实在过于响亮。不幸的是第一次它给我的印象并不是很好,觉得百般无聊,如读天书,很快我就将它搁置在一旁。

  直到高三那年我和3位好友创业失败,在创业过程中暴露出来的问题,以及自己在团队开发过程中学到的种种经验,才使得当我再次捧起这本书时,如若知己。

  《人月神话》中的人代表参与开发工作的人员数量,月代表开发周期。在很多人眼中,人月是可以互换的,也即是安排更多的人员参与开发,那么开发工作只需要更短的月就可以完成。

  但正如作者在书中所言:

  我们围绕成本核算的估计技术,混淆了工作量和项目进展。人月是危险和带有欺骗性的神话,因为它暗示了人员数量和时间是可以相互替换的。

  项目的时间依赖于顺序上的限制,人员的最大数量依赖于独立子任务的数量。

  最终,我们得到了著名的布鲁克斯法则:

  向进度落后的项目中增加人手,只会使进度落后。

  这只是作者在实践中总结出的众多心得之一,除此之外,本书还涉及了其他软件开发与项目管理中出现的各种问题,如功能的取舍、手册编写、制定开发周期等。

  如果你没有任何团队开发经验,我不建议你读这本书。

  如果你已经参与团队开发,并且深陷项目管理的焦油坑,本书将带给你更多有价值的思考。

  附:

  手中有个锤子,看到什么都是钉子。

  7.《黑客与画家》:Paul Graham,编程是一种艺术创作,黑客就是艺术家。

  关于作者:创业投资公司Y Combinator创始人

  编程语言对我们的思维有何影响?

  你选择什么语言,决定了你能说什么话。编程语言就是程序员的思维方式。

  什么才能成为一个优秀的黑客?

  优秀的黑客养成了一种质疑一切的习惯。

  一直以来,程序员总是给人一种呆子的错觉。他们木讷、情商低下、不善言辞.......普通人很难理解这些呆子,因为在作者看来:

  书呆子已经在思考的东西,正是真实世界看重的东西。

  换而言之,他们不是呆,他们只是在专于他们着迷的问题。

  这本书是一个程序员到艺术家的转变之路,使得程序员不再执着于技术,而是对商业、设计等都有更深的认识。

  对于很多人盲目追求新语言、新技术,或者其他流行的东西,本书的观点是:

  他们接受流行,不是因为想要与众不同,而是因为害怕与众不同。

  对于那些被动跟着潮流而动,却又想要看到潮流方向的人,这本书狠狠得打了他们一个耳光:

  如果自己就是潮水的一部分,怎么能看见潮流的方向呢?

  附:

  世界潮流,浩浩荡荡。顺之则昌,逆之者亡!

  8.《大教堂与集市》, Eric S. Raymond,只要眼睛多,Bug容易捉。

  关于作者:《UNIX编程艺术》的作者

  怎样才能写出好的软件作品?

  好的软件作品,往往源自开发者的个人需要。

  如何成为一个优秀的程序员?

  优秀的程序员知道写什么,卓越的程序员知道改写和重用什么。

  一直以来存在着两种开发模式:大教堂与集市。

  第一中模式中,软件开发人员类似于大教堂中专门研究神学的神职人员,关在小黑屋里,每日每夜的和其他人一起精雕细琢。通俗的讲,这就是集中力量办大事。要想进入此道,需有一个神职人员特许证。

  第二个模式中,软件开发人员就是集市中熙熙攘攘的商贩。你可以随意参与你感兴趣的开发工作,而他人的成果也对你开放,不会被供奉在神探供他人景仰。如果你觉得某个软件用起来不爽,或者有什么问题,没关系,自己修改一下,然后再将它奉献给集市。通俗的讲,这就是人多力量大。要想进入此道,需要一种拿来就用,不爽就改的开源精神。

  这是一本可以引领你进入开源世界的书,你顽固不化且邪恶的灵魂若想得以解脱,需每日诚心诵读全文,并按照大神指引的精神之路,参与开源事业。若你违反开源协议,将开源作品采用虚假手段作为个人的荣誉或公司产品,并给其披上邪恶的伪装,你将被世代钉在开源世界的耻辱柱!遭受所有程序员的不屑!

  附:

  开源是第一生产力。

  9.《失控》,凯文·凯利 ,量变引起质变。

  关于作者:maverick(游侠)

  什么是量变引起质变?

  大量个体和少量个体的行为存在重大差异。群聚的个体孕育出必要的复杂性,足以产生涌现的事物。随着成员数目的增加,两个或更多成员之间可能的相互作用呈指数级增长。当连接度高且成员数目大时,就产生了群体行为的动态特性——量变引起质变。

  如何看待信息化所带来的民主?

  在任何社会中,只要交流和信息连接的强度适中,民主就必然出现,在思想自由流动并产生新思想的地方,政治组织会最终走向民主这个必然的自组织的强大的吸引子。

  刚进大学时,辅导员就强调一句话——量变引起质变。当然听着,感觉还有些哲理,但一直苦于不知道其出处。后来终于在这本书里看到了它。

  本书作者是互联网教父般的凯文·凯利,简称KK。《失控》一书写作于1994年,其全称是《失控:机器、社会与经济的新生物学》。

  这本书探讨了可能在当下也依然热门的很多问题,如蜂群思维、控制论、分布式计算、蝴蝶效应、人工智能、混沌理论...... 很难想象,这样一本对未来饱有远见的书,却写于20多年前。而在20多年后,它仍被很多人推崇,其价值可见一斑。

  近些年人工智能领域突发猛进,也引发越来越多的人,开始担忧人与机器的新生。对此,KK在书中是如何评论的:

  在将生命的力量释放到我们所创造的机器中的同时,我们就丧失了对他们的控制。

  而随着网络的快速发展,我们也有幸见证了微博反腐的变革,信息化所推动的民主革新,不可避免。对此,KK在书中又是这样论断:

  唯有庞大的网状结构才能包容形态的真正多样性。这就是为什么网络差不多与民主和市场意义等同的原因。

  而在社交网络,若你有幸是一个中心结点,那么你的价值也会随着与他人直接或间接的连接而提高。对此,KK在书中又是这样:

  他们的联系越多,我的联系就变得越有价值。

  就是你要的思想著作,精神洗礼,灵魂深造!

  附:

  网络符号象征着心智的迷茫,生命的纠结,以及追求个性的群氓。

  10.《哥德尔、艾舍尔、巴赫——集异璧之大成》:侯世达,quaerendo invenietis(觅之,自有所获)

  关于作者:Douglas Richard Hofstadter,中文名为侯世达,本书获普立兹奖。

  什么是侯世达定律?

  做事所花费的时间总是比你预期的要长,即使你的预期中考虑了侯世达定律。

  怎样才能创造出灵活的智能?

  智能的灵活性来自大量的不同规则和规则的层次。

  《哥德尔、艾舍尔、巴赫——集异璧之大成》,分为《集异壁GEB》与《异集壁EGB》 上下两篇。其英文原书名为《Godel, Escher, Bach--an Eternal Golden Braid》,其中braid一词有2种含义:

  辫子,名词

  编织,动词

  标题中的braid具有双关的作用。

  作为数学名词暗示了正题和副题之间有“G,E,B”和“E,G,B”这种词首字母在次序上的照应。

  而对于中文标题中的“G、E、B”,分别对应着"Godel、Escher、Bach",即是“哥德尔、埃舍尔、巴赫”。由此扩展下去,又代表着“哥德尔的哥德尔不完备定理、埃舍尔的画、巴赫的音乐”。

  好吧,之所以对一个书名都如此纠结,是因为这本书是一本跨度很大,且非常烧脑的书。

  按照作者侯世达在”鸣谢“与“导言”中自述,本书在他的脑海中酝酿了几乎有二十年之久,起初他打算写一篇以哥德尔定理为核心的小册子,后来想法像球面一样扩展开来,不久就触及了巴赫和艾舍尔,并涉及数理逻辑,可计算理论,人工智能等诸多领域。

  最后提醒:本书的中文译本共计1053页,涉及音乐,绘画,宗教,哲学,人工智能,数理逻辑......

  这就是你想要的那本奇书!

  附:

  侯世达定律指做复杂任务需要花费的时间总是很难预计的。程序员经常会引用这一定律,特别是在进行有关提高效率的讨论时(如《人月神话》和极限编程)。其自指的特征反映了即便意识到任务的复杂性,预计花费的时间仍是困难的。

本文摘自:http://www.cdtedu.com/info/8115.html,如需转载,请保存!

大话程序界+推荐书籍!

标签:

原文地址:http://www.cnblogs.com/yu-an/p/5845491.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!