简约之美

出版社:人民邮电出版社
出版日期:2013-1
ISBN:9787115302380
作者:[美] Max Kanat-Alexander
页数:120页

章节摘录

版权页:   程序的代码应当采用什么结构? 是程序的速度重要,还是代码容易阅读重要? 为满足需求,应该选择哪种编程语言? 软件设计与下列问题无关: 公司的结构应该是怎样的? 什么时候召开团队会议? 程序员的工作时间应该如何安排? 程序员的绩效如何考核? 这些决策与软件本身无关,只与组织有关。显然,保证这类决策的合理性也是重要的——许多软件项目之所以失败,就是管理失当。但是这不是本书的主题,本书关注的是,如何为你的软件制订合理的技术决策。 软件系统中任何与架构有关的技术决策,以及在开发系统中所做的技术决策,都可以归到“软件设计”的范畴里。 2.1 程序员也是设计师 在软件项目中,每个程序员的工作都与设计有关。首席程序员负责设计程序的总体架构;高级程序员负责大的模块;普通程序员则设计自己的那一小块,甚至只是某个文件的一部分。但是,即便仅仅是写一行代码,也包含设计的因素。 哪怕是单干,也离不开设计。有时候你在敲键盘之前,就做了决定,这就是在做设计。有的夜晚,你躺在床上,还在思考要怎样编程。 每个写代码的人都是设计师,团队里的每个人都有责任保证自己的代码有着良好的设计。任何软件项目里,任何写代码的人,在任何层面上,都不能忽略软件设计。 这不是说设计应该采取民主程序进行。设计决不应该由某个委员会负责,那样的结果必然很差劲。相反,所有的开发人员都应有权在自己的工作中做出良好的设计决策。如果某位开发人员做了糟糕或者平庸的决策,资深开发人员或者首席程序员就应当推翻这些决策,重新来过。对下属的设计,这些人应当拥有否决权。不过,软件设计的责任应当落实在真正写代码的人身上。 身为设计师,必须时时愿意聆听建议和反馈,因为程序员大都比较聪明,有不错的想法。但是考虑了所有这些建议和反馈之后,任何决策都必须由单独的个人而不是一群人来做出。 2.2软件设计的科学 现在,软件设计仍然不算科学。什么是科学?词典里的定义有点儿复杂,但简单来说,一门学问要成为科学,必须符合下列标准。 科学必须包含汇总而来的知识。也就是,它必须包含事实而不是意见,且这些事实必须汇总起来(比如集结成书)。 这些知识必须具有某种结构。知识必须能分类,其中的各个部分必须能够依据重要性之类的指标,妥善建立起与其他部分的联系。 科学必须包括一般性的事实或者基本的规则。 科学必须告诉你在现实世界中如何做一些事情。它必须能够应用到工作或生活中。 通常,科学是经由科学方法来发现或证明的。科学方法必须观察现实世界,提炼出关于现实世界的理论,通过验证理论,而且这些实验必须是可重复的。这样才能说明理论是普适的真理,而不仅仅是巧合或者特例。

前言

  好程序员和差程序员的区别在于理解能力。差劲的程序员不理解自己做的事情,优秀的程序员则相反。信不信由你,道理就是这么简单。  写这本书,是为了帮助各位程序员,以适用于各种编程语言、各种项目的广阔视角来理解软件开发。本书以普通人容易理解的方式,讲解了软件开发的科学规律。  如果你是程序员,这些规律能够说明,为什么有些开发方法有效,另一些无效。这些规则也会指引你在日常工作中做出开发决策,帮助你的团队进行高质量的交流,最终制订出合理的计划。  如果你不是程序员,但身在软件行业,仍然可以享受到本书的价值:  ·它既是提供给初级程序员的优秀教材,又包含对高级程序员相当有 用的知识;  ·它帮助你更深入地理解软件工程师某些行为的原因,以及软件为何 要以某种方式来开发;  ·它帮助你理解优秀的软件工程师做决定的基本原理,让你与开发人 员更顺畅地沟通。  理想的状态是,软件行业中的每个人都可以阅读并理解这本书,即便他们没有多少编程经验,甚至母语不是英语也无所谓。如果你已经有相当的技术积累,把握书中的概念会更加容易,但是大部分内容不需要编程经验就能理解。  实际上,本书虽然讲的是软件开发,却没有多少代码。这怎么可能呢?答案是,其中的思想适用于各种软件项目、各种语言。要明白如何运用这些思想,并不需要懂得某一门具体的编程语言。相反,本书中包含了大量的实例和比喻,它们会让你更好地理解所表述的每条原理。  最重要的是,这本书是为了帮助你而写的,希望能助你在软件开发中保持头脑清醒、遵守秩序、写出简洁代码。我希望它读起来是一种享受,它有助于改善你的生活,你的软件。  排版约定  本书中格式约定如下。  黑体:表示新术语。  等宽字体:用于代码示例,在段落中使用时,表示与程序有关的部分,比如变量或者函数名。  此图标表示提示、建议或者普通的旁注。  致谢  Andy Oram和 Jolie Kanat两位编辑为本书作了巨大的贡献。 Andy的建议和意见深入且充满智慧; Jolie的坚持和支持促成了本书的最后出版,她为早期手稿所做的大量编辑工作尤其值得感谢。  Rachel Head是本书的文字编辑,做整理和校对的工作,她的才华无与伦比。  还要感谢的是与我在开源社区中一同工作或讨论过问题的程序员——尤其是在 Bugzilla项目中共事的几位开发人员,有了你们的帮助,我才有清楚的思维,讲解这些年来真实存在的,活生生的软件系统。  这些年来,我的 blog上收到的评论和反馈,帮我确定了本书的形式和内容。在这里要感谢参与其中的所有人,即使你们仅仅给我鼓励,或者是告诉我你读过我的文章。  从个人来说,我尤其要感谢 Jevon Milan、Cathy Weaver,以及与他们工作过的所有人。确切地说,有了他们,我才能写出这本书。最后,要向我的朋友 Ron致敬,没有他,这本书根本不可能出现。  使用示例代码  让我们助你一臂之力。也许你要在自己的程序或文档中用到本书中的代码。除非大段大段地使用,否则不必与我们联系取得授权。例如,无需请求许可,就可以用本书中的几段代码写成一个程序。但是销售或者发布 O’Reilly图书中代码的光盘则必须事先获得授权。引用书中的代码来回答问题也无需授权。将大段的示例代码整合到你自己的产品文档中则必须经过许可。  我们非常希望你能标明出处,但并不强求。出处一般含有书名、作者、出版商和 ISBN,例如“ Code Simplicity:The Science of Software Development by Max Kanat-Alexander(O’Reilly,2012)版权所有。  如果有关于使用代码的未尽事宜,可以随时与我们取得联系。  Safari·在线图书  Safari在线图书是应需而变的数字图书馆。它能够让你非常轻松地搜索 7500多种技术性和创新性参考书以及视频,以便快速  地找到需要的答案。  订阅后就可以访问在线图书馆内的所有页面和视频。可以在手机或其他移动设备上阅读,还能在新书上市之前抢先阅读,也能够看到还在创作中的书稿并向作者反馈意见。复制粘贴代码示例、放入收藏夹、下载部分章节、标记关键点、做笔记甚至打印页面等有用的功能可以节省大量时间。这本书(英文版)也在其中。欲访问本书英文版的电子版,或者由 O’Reilly或其他出版社出版的相关图书,请到网站免费注册。  我们的联系方式  请把对本书的评论和问题发给出版社。 

内容概要

Max Kanat-Alexander:开源项目Bugzilla总架构师,Google软件工程师,作家,8岁开始修电脑,14岁开始编程。codesimplicity.com和fedorafaq.org网站维护者,现居北加州。

书籍目录

目录
第1 章  引言  1
1.1  计算机出了什么问题?  3
1.2  程序究竟是什么?  5
第2 章  缺失的科学  9
2.1  程序员也是设计师  12
2.2  软件设计的科学  13
2.3  为什么不存在软件设计科学  15
第3 章  软件设计的推动力  19
第4 章  未来  27
4.1  软件设计的方程式  29
4.1.1  价值  30
4.1.2  成本  31
4.1.3  维护  32
4.1.4  完整的方程式  33
4.1.5  化简方程式  33
4.1.6  你需要什么,不需要什么  34
4.2  设计的质量  36
4.3  不可预测的结果  37
第5 章  变化  41
5.1  真实世界中程序的变化  43
5.2  软件设计的三大误区  46
5.2.1  编写不必要的代码  46
5.2.2  代码难以修改  48
5.2.3  过分追求通用  51
5.3  渐进式开发及设计  53
第6 章  缺陷与设计  55
6.1  如果这不是问题……  57
6.2  避免重复  59
第7 章  简洁  61
7.1  简洁与软件设计方程式  65
7.2  简洁是相对的  65
7.3  简洁到什么程度?  67
7.4  保持一致  69
7.5  可读性  71
7.5.1  命名  72
7.5.2  注释  73
7.6  简洁离不开设计  74
第8 章  复杂性  77
8.1  复杂性与软件的用途  81
8.2  糟糕的技术  83
8.2.1  生存潜力  83
8.2.2  互通性  84
8.2.3  对品质的重视  84
8.2.4  其他原因  85
8.3  复杂性及错误的解决方案  85
8.4  复杂问题  86
8.5  应对复杂性  87
8.5.1  把某个部分变简单  89
8.5.2  不可解决的复杂性  90
8.6  推倒重来  90
第9 章  测试  93
附录A  软件设计的规则  97
附录B  事实、规则、条例、定义  101

编辑推荐

没有人喜欢复杂的东西,所以软件开发的简约之道一定会受读者青睐。本书作者Max Kanat-Alexander创建的关于Linux的简约单页网站Unofficial Fedora FAQ,月访问量超过10万人次。本书作者还是著名的开源Bugzilla Project的首席架构师、社区创始人和发布经理。

作者简介

《简约之美:软件设计之道》将软件设计作为一门严谨的科学,阐述了开发出优雅简洁的代码所应该遵循的基本原则。作者从为什么以前软件设计没有像数学等学科一样成为一门科学开始入手,道出了软件以及优秀的软件设计的终极目标,并给出了具体的指导规则。


 简约之美下载 精选章节试读 更多精彩书评



发布书评

 
 


精彩书评 (总计4条)

  •     总结了很多在实际开发中遇到的问题,当开发过一两个大系统之后再来读,觉得作者说的都在理。摘录部分笔记:https://github.com/onestarshang/Code_Simplicity_The_Science_of_Development是不是评论太少又不可以?是不是评论太少又不可以?是不是评论太少又不可以?是不是评论太少又不可以?是不是评论太少又不可以?是不是评论太少又不可以?是不是评论太少又不可以?是不是评论太少又不可以?是不是评论太少又不可以?是不是评论太少又不可以?
  •     总结性的书籍,虽然不是很厚,但是还是比较有内容的书。值得多看看想想,适合比较初级的程序员。额,附录A是一个比较不错的总结,虽然我是按照顺序看的。在我看完想写做一做笔记的时候,发现编者帮我总结好了......
  •     其实整本书说白了就是几句话:代码一定要保持整洁,不要过度设计,也不要不设计,更重要的是考虑后续的维护成本。但是在实际情况下要贯彻落实书中观点是一件很不容易的事情,除了不断实践,不断试错之外,别无他法。只有自己知道痛了才会长记性,光读一两本这种程序员“心灵鸡汤”型的书是远远不够的。书本身内容两分,译者行文流畅度不错加一分。PS:120页的书要25块,这年头...

精彩短评 (总计75条)

  •     更多的是看书的内容比较实用,包装我觉得都是次要的
  •     很简单一本书,把最后两页的附录看了就可以了,说的更极端点, 书的标题 如果 深刻理解了, 书都不用看了, 书名已经概括了书要讲的所有东西. 所以非常适合刚刚学编程的人, 就像译者序说的, 就是 一本 <<常识>>
  •     废话连篇 看附录的总结就足够了
  •     看完没什么感觉
  •     超简短的小册子,新的软件开发观念
  •     字字珠玑
  •     干货不多,一般般
  •     够短的。。把精华收集到附录挺好的,应该再有索引到正文呀。
  •     全文就一个核心观点: 不要过度设计, 处理目前已知的明确的需求, 通过迭代的方式进行开发.
  •     99页。简单真的很美,不要再往软件里面加广告了。不敢写书评,怕一不小心写的比本书的字数还多。
  •     好棒的一本书~~自己试过重写代码,也试过把代码从单个文件逐渐演化到各个模块的过程,经过这些实践之后,再回过头来看这本书,感觉真不一样....很多很好的原则可以遵循,写代码也是门手艺活~~
  •     不错 传授了一种软件设计思想
  •     没啥意思,对于初学者入门还是挺不错的。
  •     基本上全是废话
  •     经验之谈,值得读一读
  •     书中的内容比较浅显,略读就行了
  •     多看阅读限免一天,读了下。写的比较简单,属于软件开发常识类。
  •     价格很便宜,正版!
  •     不是令人印象特别深刻的书,说的都是一些基本常识,大概也就是说程序员其实是『设计师』
  •     简约软件设计原则
  •     通通都是顯而易見的準則,讀完簡直是在浪費我的時間啊幹
  •     还没有时间好好看
  •     几句话就可以总结完了,果然是“常识”
  •     好的思考,是需要由根本来打好基礎
  •     good job~!!
  •     好程序员和差程序员的区别在于理解能力,差劲的程序员不理解自己做的事情,优秀的程序员则相反。
  •     常识
  •     一切以简为美
  •     看完后,我首先想到的是,谷歌的里所有的代码都是统一的编程规范带来的开发效率的提升。
  •     简约之美
  •     没啥意思,全是废话,内容少的可怜,翻来覆去在绕弯子。
  •     书倒是不错,就是太薄了
  •     100页确实说的东西不多,主要是软件可维护性最重要
  •     不看也罢,想看类似的书,还不如看那本《架构之美》更有意义
  •     简约之美:软件设计之道
  •     什么是科学,什么是定理,不要重新发明轮子
  •     KISS
  •     里面的观点都很简单,看起来是个刚入门的同学看的,其实工作了一段时间的同学也应该好好看看,很多东西看起来简单,做起来真的很难。不要忘了开发软件的初心。
  •     浏览一遍 没啥感觉
  •     都是常识,几句话的事情,非得写成一本书。
  •     内容很好,值的一看,推荐!
  •     书的内容很少完全纲领性的书
  •     有点失望…
  •     驾驭业务的复杂性必须依赖设计的简单性,退而求其次的策略是封装复杂性使其尽量少的被感知。
  •     非常短,基本上都是已经知道的大实话。还是值得一看。我们这里有不止一个非常好的**反例**。
  •     对于当前的工作有一些触动。书本身也用简洁的叙述自我点题了。非常明快和踏实的引人思考如何让项目简洁起来。
  •     还不错。虽然是写给程序员的。但是作为设计师。也能够更好的和程序合作。更好的了解软件整体流程中的一些东西
  •     挺不错的书,就是内容有点单调了
  •     一般,不妨一看,小有收益
  •     这本书非要分一个类的话,就是代码规范类的吧。这种书我已经读的很多了。但是最重要的还是自己的代码感觉,简称码感。
  •     做为软件初级工程师看起来没什么感觉。。。
  •     “软件的目的是帮助别人”是软件设计六条法则之一。另外还有一个软件设计方程式和四条定律(变化定律、缺陷概率定律、简洁定律和测试定律)。
  •     薄薄的,但“很重”
  •     好薄的一本书,一晚上就看完了。删掉无用的代码;只根据现有的需求做可扩展设计,不过度设计;考虑软件可维护性很重要;不愧是一本"常识"书。道理很明显,关键是要在实际工作中具体实践。
  •     当当的忠实书友
  •     保持clean code就对了
  •     过度设计,过犹不及
  •     2015
  •     用作者两句话总结:相比降低开发成本,降低维护成本更重要;维护成本正比于系统复杂度。
  •     很简短的小册子,将的设计相关的道理都很浅显,倒很是印证了近期所在项目的工作内容。中高级码工可以忽略此书。没有耐心的读者只读附录即可。
  •     书很小很薄,更像是小册子,但内容肯定值这个价钱.在外面吃个肯德基还要20块呢.对于工作了两三年的工程师来说,有醍醐灌顶的感觉.可以跟<软件简洁之道>一起看,这本书告诉你方法,而<简约之美>告诉你原因.
  •     32开纸只有100页,还真是挺贵的。。。最主要是,排版好难看啊。。。
  •     建议10分钟左右读完
  •     在看从最基本的原理讲解,收获不少。这叫理论指导实践么。
  •     这本书有点浅 不过例子挺多
  •     说的比较本质,着重表明软件开发的科学性
  •     把东西变得简单是一种伟大的能力,当然这种简单并不是狭义上的简单。
  •     书很短,两小时读完。 可能之前我已经有相关的知识储备,所以收获不大。 对于初学编程者,想要写出设计更好的代码,更推荐 整洁代码之道,以及重构。
  •     http://teawater.coding.me/mindmap/Code_Simplicity.html 欢迎吐槽
  •     应当是写给大众的普及民用版书吧,没有预期那么好,挺爆还那么贵,性价比不高~
  •     简单易懂~~~~~~~
  •     书中有些关注值得细细品味
  •     #图灵PDF#
  •     书很薄很快翻完了,感觉说的太形而上学,总结一下差不多就是中庸之道,要平衡考虑编码的通用性和复杂度……作者要是能多举点案例就好了
  •     非常多设计的一些原则和方法, 涉及了软件设计, 开发, 代码, 测试等各个方面, 非常有启发.
 

外国儿童文学,篆刻,百科,生物科学,科普,初中通用,育儿亲子,美容护肤PDF图书下载,。 零度图书网 

零度图书网 @ 2024