- 推荐1
- 收藏4
- 浏览1.4K
聊聊架构
- 书 号：978-7-121-31122-2
- 出版日期：2017-04-19
- 页 数：248
- 开 本：16(170*240)
- 出版状态：上市销售
- 维护人：张春雨
纸质版 ￥69.00
架构是如何运作并影响人们的日常生活的，在软件行业中架构是如何运作的？架构又是如何指导代码编写的，如何把架构应用在软件工程实践上？带着这些疑问，本书通过大量的实例一步一步揭示出架构背后的原理，以及架构在软件行业的发展，并通过企业实例来展示软件架构的实际应用。本书没有高深的词汇，不仅适合IT从业人员阅读，也适合其他行业的人士阅读。尤其对于想从事架构工作的人而言，是一本不可多得的参考材料。
溯本求源 返璞归真
序
在软件行业，架构师和软件工程师是非常辛苦的职业。一方面新技术层出不穷，另一方面业务需求也层出不穷，让人疲于应付。导致的后果就是常常加班，生活质量低下。只有曾经身在其中的人，才能够体会其中的酸甜苦辣。
在软件行业经历过这么多年，也看到了软件行业普遍存在的一些问题，总觉得自己应该为这个行业贡献一点点力量。不期望能够改变这个行业，能够引起一点点思考也是好的，如果能够帮助提升一些软件从业者的工作和生活质量，就超出期望值了。
把自己的想法写出来的过程是痛苦的，从来没有写文字的习惯，也没打算过写书，因此愈发艰难。年初时基于以上同样的想法，在 InfoQ 投稿写了《架构漫谈》专栏，和大家分享一下自己对软件架构的思考，以为算是交差了。不料 InfoQ 的郭蕾多次和我约稿，希望我能够把架构漫谈扩展成一本书。拒绝了很多次，但是脸皮实在是薄，禁不住郭蕾三番五次的游说，狠狠心答应了下来。
把文字写下来传播出去，是要承担很大的责任的，一旦说得不对，伤害的是一大片人。不愿写东西的原因大部分在此。但是想想人非圣贤，总有犯错的时候，把自己的错误暴露出来给大家，也是帮助大家学习。话虽如此，还是郑重声明，本书的内容都是个人的思考和个人的观点，并非学术的结论，请各位读者不要当作结论全盘接受。反而读者应该质疑书中的各种观点，尽量自行思考，如此才会有所收获。本书的目的也仅仅是为了引发大家的思考。
思及自身水平有限，文字功底也差，难免伤人慧命，深感惭愧和惶恐！望各位读者，鉴其愚诚，不吝慈悲指正！
王概凯 Kevin
前言
现代的软件从业者，都受过良好的计算机和软件方面的教育。但是现代的计算机和软件方面的教育，基本上都是从科学研究领域脱胎出来的，教育的目的也理所当然的主要是为科学研究领域服务。而随着社会的发展，软件不断地渗透到不同的业务领域，涉及到普通人生活的方方面面。以科学研究为目的的软件教育，和日益深入人们生活的软件应用，产生了很大的隔阂。以致于很多计算机和软件专业毕业的学生，进入企业工作后，总是感叹学校所学习的知识派不上用场，必须得重新学起，才能够达到企业的要求。
而这些重新学习的内容，又往往是以技术为主的。技术的更新换代太快，往往也导致想跟上新技术的我们力不从心。技术和业务的关系是如何的？业务又是怎么运作的？很少有人去问这些问题。即使有人问了，也很难有人可以提供建议。
软件技术学习到一定的地步，又会发现软件架构是一个门槛。一直以来，在软件行业，对于什么是架构有很多的争论，每个人都有自己的理解。甚至于很多架构师一说架构，就开始谈论应用架构、硬件架构、数据架构等。而事实上，架构在软件发明时的很多年以前就已经存在了。众说纷纭，莫衷一是，这也给大家带来了很多困扰。
业务和架构，是压在软件从业人员身上的两座大山。而软件从业人员手上却只有一个武器：技术。可是这个武器还时灵时不灵，就好像金庸小说《天龙八部》中段誉的六脉神剑，并不总是能够解决问题，有时还会带来麻烦。
软件并不是虚无缥缈的东西，它和现实生活是紧密相关的。业务和架构都是处理人的问题。而技术人员最讨厌处理的就是人的问题，心里面厌恶，但却又无法逃避。因为这个排斥的心理，工作中始终想避开和人有关系的地方。因此在技术之前，还需要做一些准备工作，用来连接现实生活，联系上人，让大家知道处理人的问题并不可怕。建立了这个相关性，每个人就都可以自行思考了。
不仅人类受限于自身的生命周期，凡事都有其生命周期。理解了生命周期，就可以看到很多隐藏在背后的规律，以及这些规律之间的联系。因此，本书试图从生命周期入手，描绘出一张整体的画卷，帮助包括技术人员在内的大家定位自己处于什么地方，自己在起什么作用，别人又在什么地方，他们又在起什么作用。
明白了自己的位置和别人的位置，自然也就清楚自己有什么，缺什么，要往哪个地方走，从哪些地方入手了。所谓“知己知彼，百战百胜”，知道这些后中，面对人打交道时也就有了自己的思考方式，能够进行独立思考，对业务也不再厌恶以致于逃避，而是为能帮助业务人员分析及解决问题而自豪。
本书虽然不是技术书籍，不谈技术，但却是以帮助技术人员为出发点。本书的内容可以作为连接技术人员和现实世界的桥梁，用来使技术人员不再悬在空中使不出力。对于非技术人员而言，本书可以帮助其理解软件开发的特殊性，拉近与技术人员的距离，能够更有针对性地与技术人员合作。
当然，读完本书不会使读者突然学会神功，打通任督二脉。因为每个人的成长，最终还是要靠自己的思考和实践。本书的思考也不能够代替读者自己的思考，在解决某个业务问题时也无法从书中直接找到答案。本书可以提供给大家的是一个思考的出发点，一个思考的方向，一个思考的角度，使得大家不再惧怕或排斥业务，并可以像业务人员一样思考，和架构师一样思考，不再受困于业务和架构，甚至是技术本身。如果本书能够帮助大家跨过这个门槛，并从这里开始展开思考，那么目的就达到了。
在软件行业，架构师和软件工程师是非常辛苦的职业。一方面新技术层出不穷，另一方面业务需求也层出不穷，让人疲于应付。导致的后果就是常常加班，生活质量低下。只有曾经身在其中的人，才能够体会其中的酸甜苦辣。
在软件行业经历过这么多年，也看到了软件行业普遍存在的一些问题，总觉得自己应该为这个行业贡献一点点力量。不期望能够改变这个行业，能够引起一点点思考也是好的，如果能够帮助提升一些软件从业者的工作和生活质量，就超出期望值了。
把自己的想法写出来的过程是痛苦的，从来没有写文字的习惯，也没打算过写书，因此愈发艰难。年初时基于以上同样的想法，在 InfoQ 投稿写了《架构漫谈》专栏，和大家分享一下自己对软件架构的思考，以为算是交差了。不料 InfoQ 的郭蕾多次和我约稿，希望我能够把架构漫谈扩展成一本书。拒绝了很多次，但是脸皮实在是薄，禁不住郭蕾三番五次的游说，狠狠心答应了下来。
把文字写下来传播出去，是要承担很大的责任的，一旦说得不对，伤害的是一大片人。不愿写东西的原因大部分在此。但是想想人非圣贤，总有犯错的时候，把自己的错误暴露出来给大家，也是帮助大家学习。话虽如此，还是郑重声明，本书的内容都是个人的思考和个人的观点，并非学术的结论，请各位读者不要当作结论全盘接受。反而读者应该质疑书中的各种观点，尽量自行思考，如此才会有所收获。本书的目的也仅仅是为了引发大家的思考。
思及自身水平有限，文字功底也差，难免伤人慧命，深感惭愧和惶恐！望各位读者，鉴其愚诚，不吝慈悲指正！
王概凯 Kevin
前言
现代的软件从业者，都受过良好的计算机和软件方面的教育。但是现代的计算机和软件方面的教育，基本上都是从科学研究领域脱胎出来的，教育的目的也理所当然的主要是为科学研究领域服务。而随着社会的发展，软件不断地渗透到不同的业务领域，涉及到普通人生活的方方面面。以科学研究为目的的软件教育，和日益深入人们生活的软件应用，产生了很大的隔阂。以致于很多计算机和软件专业毕业的学生，进入企业工作后，总是感叹学校所学习的知识派不上用场，必须得重新学起，才能够达到企业的要求。
而这些重新学习的内容，又往往是以技术为主的。技术的更新换代太快，往往也导致想跟上新技术的我们力不从心。技术和业务的关系是如何的？业务又是怎么运作的？很少有人去问这些问题。即使有人问了，也很难有人可以提供建议。
软件技术学习到一定的地步，又会发现软件架构是一个门槛。一直以来，在软件行业，对于什么是架构有很多的争论，每个人都有自己的理解。甚至于很多架构师一说架构，就开始谈论应用架构、硬件架构、数据架构等。而事实上，架构在软件发明时的很多年以前就已经存在了。众说纷纭，莫衷一是，这也给大家带来了很多困扰。
业务和架构，是压在软件从业人员身上的两座大山。而软件从业人员手上却只有一个武器：技术。可是这个武器还时灵时不灵，就好像金庸小说《天龙八部》中段誉的六脉神剑，并不总是能够解决问题，有时还会带来麻烦。
软件并不是虚无缥缈的东西，它和现实生活是紧密相关的。业务和架构都是处理人的问题。而技术人员最讨厌处理的就是人的问题，心里面厌恶，但却又无法逃避。因为这个排斥的心理，工作中始终想避开和人有关系的地方。因此在技术之前，还需要做一些准备工作，用来连接现实生活，联系上人，让大家知道处理人的问题并不可怕。建立了这个相关性，每个人就都可以自行思考了。
不仅人类受限于自身的生命周期，凡事都有其生命周期。理解了生命周期，就可以看到很多隐藏在背后的规律，以及这些规律之间的联系。因此，本书试图从生命周期入手，描绘出一张整体的画卷，帮助包括技术人员在内的大家定位自己处于什么地方，自己在起什么作用，别人又在什么地方，他们又在起什么作用。
明白了自己的位置和别人的位置，自然也就清楚自己有什么，缺什么，要往哪个地方走，从哪些地方入手了。所谓“知己知彼，百战百胜”，知道这些后中，面对人打交道时也就有了自己的思考方式，能够进行独立思考，对业务也不再厌恶以致于逃避，而是为能帮助业务人员分析及解决问题而自豪。
本书虽然不是技术书籍，不谈技术，但却是以帮助技术人员为出发点。本书的内容可以作为连接技术人员和现实世界的桥梁，用来使技术人员不再悬在空中使不出力。对于非技术人员而言，本书可以帮助其理解软件开发的特殊性，拉近与技术人员的距离，能够更有针对性地与技术人员合作。
当然，读完本书不会使读者突然学会神功，打通任督二脉。因为每个人的成长，最终还是要靠自己的思考和实践。本书的思考也不能够代替读者自己的思考，在解决某个业务问题时也无法从书中直接找到答案。本书可以提供给大家的是一个思考的出发点，一个思考的方向，一个思考的角度，使得大家不再惧怕或排斥业务，并可以像业务人员一样思考，和架构师一样思考，不再受困于业务和架构，甚至是技术本身。如果本书能够帮助大家跨过这个门槛，并从这里开始展开思考，那么目的就达到了。
目录
读者评论
-
拜读之后，关于访问通道不重用这块有些问题。
我们现在的系统存在多种使用者角色与多个终端，如老师、学生、家长为三个使用者，App、Web为两个终端。
老师、学生、家长所访问的数据实体是一种，App、Web同样如此，如试卷信息。
这种情况下，应该如何拆分访问通道呢。 -
第4章 什么是架构 架构产生的条件 （1）必须由人执行的工作 不需要人介入，就意味着不需要改造；不需要节省时间，也就不需要另外再产生架构了。大自然会自行调整自然界本身的架构。既然是不需要人介入的，为啥又是必须由人执行的工作呢？
-
读者朋友你好，你所提出的问题小编已转告本书的相关编辑，编辑近期会予以回复。
-
这是不是随着社会的发展，人越来越多。需要有个人去整合资源。让人与人之间的合作更高效，类似建筑上的包工头，他要清楚每个人擅长的技术，并把任务分配给他。
-
这里作者是反证法，如果证明A不成立，A的反命题B就成立了。
-
-
第125页 第21章 软件架构和面向对象
21.1 什么是面向过程 第一段最后一句通过功能调用(Procedure Call)或者过程调用(Function Call)来组织调用的流程。 英文反了， Function Call才是功能调用， Procedure Call是过程调用-
读者朋友你好，你提出的勘误小编已告知相关策划编辑。近期编辑会予以回复。
-
-
本来想来这里给作者好评的，不知道你们怎么做到我无法在你们的评论框输入中文，只能在别的地方打字，然后复制过来
-
感谢您的购买和阅读，如对图书有其他的意见和建议，在图书页面的读者评论处直接留言即可。
-
“虚线表示非生命周期”-＞“虚线表示非核心生命周期”。
根据上下文，增加“核心”一词限定。
“这样每个人为自己核心生命周期所花的时间就少多了，有更多的时间用来提升核心生命周期的质量“这一句， ”这样每个人为自己核心生命周期所花的时间就少多了“应该改为：”这样每个人为自己的非核心生命周期所花的时间就少多了“
“这样每个人为自己核心生命周期所花的时间就少多了”
应为
“这样每个人为自己的非核心生命周期所花的时间就少多了”
降低数的层数。应该是“降低树的层数”
“降低数的层数”改为“降低树的层数”