架构师素养及从小菜进阶架构(CTO)的书籍
Posted jimcsharp
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了架构师素养及从小菜进阶架构(CTO)的书籍相关的知识,希望对你有一定的参考价值。
CTO要了解无线技术/搜索/大数据/数据库等。
-- 通常定义架构有几个层次,这包括业务架构、产品架构、应用架构和技术架构:
1.业务架构:描述一个企业围绕一个行业做了哪些业务,例如支付行业的收单、退款、出款、充转提等能力,这与公司对外和对内定义的产品无关。
2.产品架构:描述对外和对内定义的可销售的产品,例如微信的条码支付、扫码支付、公众号支付等。
3.应用架构:描述提供了哪些系统和服务来实现对外和对内的产品架构,从而支持公司的业务架构,例如微信内部的订单系统、支付系统、账务系统和对账系统等等。
4.技术架构:通常涉及采用什么的技术栈,以及各个技术栈之间如何分工和协作的,具体会细分为数据架构视图、服务化架构视图、缓存架构视图、消息架构视图、安全架构视图、性能架构师视图等等。
作为通用架构师应该有众多的能力,这涉及到方向、战略、策略、决策、影响力、规划等。
对于技术人员在职位上的晋升,我们通常通过点线面体来类比,这也是从工程师到架构师的晋级过程:
点:能够独立负责一个模块的开发。
线:能够根据设计,同时负责一个项目中多个模块的开发,甚至独立负责一个项目的开发。
面:在所在领域内,可以负责一个产品的整个研发过程,并对业务和技术要有前瞻性。
体:能够负责一个产品线的研发过程,并且能够开拓某个行业。
架构能力,我们通常通过深度、广度和高度上来衡量:
1.广度:要有全栈的技术知识,针对所在领域的技术要有全面的了解,能够评估各种技术的优缺点,要能根据优缺点来做技术选型的决策。
2.深度:要针对所在领域的核心技术有一定的造诣,阅读过源码,针对产生的 Bug 要有能够迅速定位的能力,或者曾经贡献过核心代码。
3.高度:能够理解业务的本质,能够识别业务的风险,并做出合理的应对,对业务和技术都要具有前瞻性。要理解业务的本质,对业务的特殊性有所把控,要能抽象事务也要能具象事务。要能用技术服务业务,或者推动技术的更新换代,或者推动业务创新,从而直接产生价值。
管理模式:架构师要理解和适应各种管理的方法,通常有传统的多层企业管理、扁平化的企业管理、矩阵式管理,一般情况下,扁平化管理的效率较高,沟通成本较低,适合初创企业,在这种管理模式下,架构师也比较容易发挥其价值。但是在多层的企业管理和矩阵式管理中,由于层次较多,沟通成本增加,一项事情从上面传达到下面要经历多个中层领导,中层领导需要一层一层往下传达,传达过程其实也是一种成本,对于每个任务和项目需要沟通确认达成一致,才能保证项目传达的方向的正确性,由于层次多了,沟通成本增加,再由于中层领导区分战略思维,或者有战略思维没有落地经验,就会导致底层的人有可能没有完全获得上层人交给的任务,在下面就有可能“憋死了”,这些都是管理上的通病,架构师必须理解所处的环境,已经产生的问题,针对这些问题来提供合理有效的解决方案,毕竟组织架构也属于架构的一部分。
> 架构师素养
分享一个架构师的成长阶段。第一个阶段应该是习惯养成阶段,应该注重于培养良好的编码和设计习惯,注重代码量和代码质量,注重抽象;第二个阶段应该是培养模块和系统设计能力,在关键系统设计上总结方法积累经验,懂得资源(网络IO、磁盘IO、内存、CPU等等)如何最优化利用,系统如何分层,掌握可用性、高并发、高性能的一些方法论和设计技巧;第三个阶段是培养业务思维,能站在业务需求角度思考系统架构的合理性和架构演进方向,能发现影响业务发展的系统瓶颈;第四个阶段架构师应具备产品思维。
十位值得关注的Java顶级专家- http://blog.csdn.net/FL63Zv9Zou86950w/article/details/78639669
专访架构师陈波:微博近几年的架构演进之路和架构师的技能素养- http://geek.csdn.net/news/detail/199899?ref=myread
个人对架构的理解是这样的:
从开发人员的角度,架构是系统整体结构的规划设计,也是系统实现的一个草图,主要包含抽象出来的模块、交互协议及设计决策。因为架构的模块、协议、决策是抽象层面的规划,所以具体实现跟业务相关,要考虑业务的需求与特性,还跟业务发展阶段相关,要考虑业务当前的规模及发展阶段,选择合适的实现方案,必要时对当前的架构做适当的修改和演进。所以,架构是设计出来的,更是演进出来的;另外没有最好的架构,只有更适合(当前业务场景和阶段)的架构。
关于架构师如何定义:
架构师负责设计系统整体架构,确定系统实现的行动纲领,使设计的项目尽量高性能、高可用、易实现,并且在上线后运维方便,在新功能加入时扩展性良好。
架构师的能力要求:
1.较强的代码能力,对日常问题有丰富的阅历及解决之道,设计不是空谈,需要实践,代码能力、解决问题的能力是系统实践的一个副产品;
2.较好的抽象能力,业务需求在架构师消化后,需要转化为设计蓝图,这中间需要大量的抽象。
3.良好的沟通和组织能力,架构设计出来,需要组织讨论、频繁沟通,让项目组成员理解架构组成及设计取舍的原因,明白架构设计中的how和why,在遇到疑问、反对、建议时,能进行良好的沟通并有序的推进。
4.较好的团队协作能力和领导能力,架构师需要得到项目组成员的认可,在关键时刻对技术的选择作出及时、有效的决定,并为决定负责。
架构师的主要职责:
1.把业务需求转换为实现架构,定义每个组成模块的外部特性,比如它的依赖、性能、异常处理等,并确定模块之间如何通信,最终形成可以指导业务开发的行动图。
2.组织讨论,组织更多的人来了解、讨论架构,能够让大家理解架构整体方案、模块特性及边界、决策权衡点,进而可以自行进行组件服务的设计及实现;
3.协助项目经理制定开发计划和控制项目进度;
4.确定系统的基础架构、实现技术,必要时组织技术调研和攻关。
Java架构师之路:Java程序员必看的15本书的电子版下载地址- http://blog.csdn.net/qq_37810594/article/details/72810316?ref=myread
高效的程序员:
熟悉不同的代码结构和设计模式。有一套自己的工具或者方法论了(带有Debug功能的编辑器)。高效率的程序员都把时间花在制作工具上。好一点的编辑器.系统性的思考方式.
适合CTO修炼的书籍:《六顶思考帽》-思维训练;《少有人走的路》-心理修炼;《创新者的窘境》《创新者的解答》-企业战略修炼;《定位》-自我定位修炼的书籍;《卓有成效的管理者》-管理方面的修炼;《麦肯锡方法》-工作方法方面,提高工作效率;《一网打尽》-企业文化。
CTO首席技术官职责:发展战略,技术总监,团队提升,团队建设,项目管理,产品管理等。
> 成为架构师:http://codebay.cn/post/939.html
小团队一般 10 人左右,其中常常是技术最牛的人做架构师(或 TL)。所以,架构师在广大码农中的占比大概平均不到 10%。而架构师也可以分为初级、中级、高级三档,江湖上真正高水平的软件架构师就更少了。
所以,大部分(超过九成的)码农干上许多年,还是做不了架构师,这是什么原因造成的呢?
1:码农分为真的能写代码的,以及自认为能写代码的。
2:真的能写代码的码农又分为自认为写的不错的,以及真的还不错的。
3:真的能写不错代码的码农又分为会钻研会不断优化的,以及安于现状的。
4:会钻研的码农又分为喜欢广度了解新技术蜻蜓点水的,以及深入钻研用到知识的。了解广度的码农又有少部分愿意深入某些技术,喜欢深入研究的又往往缺乏广度知识。
5:极少深度广度都关注的码农又分为为技术而技术和为业务而技术的。纯为技术而技术的码农在国内的软件行业需求太少,且需求的往往不是应用软件领域了。
6:为业务而技术的深度广度都了解的码农,又需要有良好的沟通能力。
7:而沟通好的,又有一部分当 PM 去了。
8:然后剩下的,又有一部分慢慢脱离实际开发(不再做任何实现)或者开始依靠拿各种中间件搭积木来作为“架构”手段。
9:除去这些,剩下对业务有一定了解,对技术广度上有多种涉猎,深度上对部分技术研究彻底,还有很重要的一点,考虑问题足够细致全面。
10:细致全面善于沟通,技术上深度广度都没问题, 又喜欢这个工作,还会不时做底层实现,从业务和开发两个角度出发,搭出“架构”来是为了开发效率,为了运行效率,为了开发质量,为了业务灵活和运行稳定,为了维护方便等等这样的人,个人认为可以称为“架构师”。
而真能满足这种需求的,别说题主的 10% 的比例,1% 能不能达到我也持怀疑态度。其实现在的“架构师”大多数都停留在 8 这个层次,甚至很多在 5 这个层次就当上 title 上的架构师了。
总之,成为架构师,不仅仅是工作上的简单积累,更需要主动接纳工作外的大量知识,同时,对性格上对于非技术能力上也有一定的要求,不仅如此连思维方式都很重要,外加职业发展中又有很多岔路,最后走到架构师这根树枝上的就寥寥可数了。
金字塔结构
自古以来,金字塔结构(人群分个三六九等、高中低三档)在人类社会的各行各业中普遍存在,这是客观规律。恐怕再过千万年,也是如此。
人类社会为什么普遍、长期存在金字塔现象?其他动物,比如蚂蚁、大雁社会,有吗?这个问题就很深了,刨根问底有难度,也许应该问上帝。
金字塔结构 / 现象从根本上决定了大多数人做不了软件架构师。不光软件工程行业如此,能做技术领导的始终必然只是位于中上层的少数人。
英文水平差
据说中国有 700 万码农,英文不好似乎是一个比较普遍的现象。英语,尤其读写不好,把合格的架构师候选人选砍掉一大半。
小富即安的心理
很多码农每月拿到万把块钱,就心安理得了,不再有更高的追求。求稳求安定,这符合大多数人的心理。不满于现状,坚持不断学习,努力提高自己的开发技术和管理水平,拥有强烈进取心,想一朝一日做编程高手、软件架构师的人毕竟是少数。
二三流企业的压制
架构师不是随便什么人可以做的。在一个企业团队里,架构师作为研发和管理骨干,具有特殊的地位和权利。
知识结构的缺陷
架构师,程序员,
产品经理的区别,大概就是建筑行业里建筑师,建筑工人,甲方业主的区别。产品经理说我要建这么这么一栋楼,架构师说好吧,我来帮你看看是做成砖木结构还是
框架结构,房型怎么设计,水电气怎么布局,预算多少,然后程序员上阵,按照图纸把楼建起来。运营是大楼的物业管理,负责营运大楼。
软件开发越来越成为传统行业(即便在互联网企
业),一个成熟的软件团队内部自然会分化出这些角色,各展所长。但非常不同的是,建筑工人很少能自发成长为建筑师,后者都是科班出身,因为建筑学科已经高
度发达,需要掌握结构力学,美学等技术,现在软件行业还没有这么高的成熟度,程序员和架构师接受的都是一样的计算机教育,所以程序员可以自学升级到架构
师,走一条不同的升级打怪路线。
那么,架构师是什么人呢?
按所工作的不同软件层分,有网络架构,系统架构,数据架构,业务架构,应用架构,平台架构。
按所解决的问题领域分,有电商架构,支付架构,搜索架构,安全架构,性能架构,游戏架构,多媒体架构,等等等。
按其工作的深度来分,有集成架构,业务架构,模块架构,框架架构,中间件架构,软件架构,引擎架构,服务器架构,甚至编程语言架构。
是不是太乱了?好比在设计师的世界观里一切东西都需要设计。软件也需要精心设计,在优秀的程序员眼里,每一行代码都需要架构!都体现了架构。
为了解决问题,程序员自然需要架构,他们中的佼佼者被冠以架构师的名号,获得了一定的话语权,逐步成为一个职业分工,我想,这就是架构师的本来面目。
成为架构师,需要经验和眼界
老码农分为两种:游击队和板凳王
坐穿板凳有利于积累经验,而不利于开拓眼界
游遍四海有利于开拓眼界,而不利于积累经验
码农的生活是高压的,唯有热情可以驱使你一边吃着苹果,一边又去摘梨
然而,又有多少热情没有随时间而冷却呢?
Java进阶之路——从初级程序员到架构师,从小工到专家- https://zhuanlan.zhihu.com/p/27991030
对分布式存储,云计算及并行编程有一定研究。
搜索、推荐、广告等.企业级架构-跨越业务和 IT 之间的鸿沟.
职业道路不用太严肃,要干点好玩的事情,走不一样的路。
有多年NIO领域的设计、开发经验,对HTTP、TCP长连接技术有深入研究与领悟。
> 成为Java架构师必须要懂的知识- http://www.jianshu.com/p/925d9aa27be4
Java架构师要掌握哪些技术:一个是基础技术,另一个就是组织能力和提出解决方案能力了。
熟练使用各种框架,并知道它们实现的原理。Jvm虚拟机原理、调优操作,懂得jvm能让你写出性能更好的代码;池技术也是要掌握的,对象池、连接池、线程池都要会;Java反射技术,写框架必备的技术;Java各种集合对象的实现原理,了解这些可以让你在解决问题时选择合适的数据结构,高效地解决问题,写出代码;nio,注意“直接内存”的特点,使用场景。
熟练使用各种数据结构和算法,数组、哈希、链表、排序树等等都是;熟练使用Linux操作系统,也是必备的;熟悉各种协议,比如tcp协议,创建连接三次握手和断开连接四次握手的整个过程,不了解就没法对高并发网络应用做优化,http协议,session和cookie的生命周期与关联;熟悉系统集群、负载均衡、反向代理、动静分离,网站静态化;懂得分布式存储系统nfs,fastdfs,tfs,Hadoop了解他们的优缺点,适用场景,以及分布式缓存技术memcached,redis,提高系统性能必备.
一个软件架构师首要的和最重要的是他的远见。如果一个架构师拥有一些软件开发经验,那会更好,但大多时候,他们面对的是一个多语言的复杂环境。在第一行代码开始编写之前,架构师需要制定出业务需求如何转变成解决方案。这不仅仅需要业务环境的相关知识,从业务操作到客户环境,他还需要向公司上级勾画出一个令人信服的系统。如果有些问题不事先考虑,如扩展性,访问延迟问题,安全问题,系统开始开发时就会忽略这些。而资深程序员了解自己的团队,了解他们的能力。资深程序员知道如何管理工作进度,确保开发中的软件如何实现架构设计的目标。
> 架构要在理想和现实之间折中,保证架构的设计实用可行“接地气”,且又不过于“山寨”。具体总结为以下几点:
1. 要端到端地审视系统
因为无论在课本教学还是文章介绍中,讲解分析往往只是集中在一个系统的某一个小块地方,会加以简化与假设。但在现实中,系统则应该从端到端来处理,因此用这个模式来考虑问题,会得到一个比较合适的结果。否则可能会只看到局部,而丢掉全局的把控。谷歌的Jeff
Dean也曾阐述过这一问题,强调要理解整个系统是如何串在一起的。
2. 对复杂性的理解和控制
因为只要是一个系统,到最后都会变得相当复杂,有各种原因导致它越来越复杂。对此我有一些经验,比如尽量把复杂性控制在一个地方,然后再通过一些分层次、模块之类的方法来将其隔离开来。我觉得对于做架构来说,很重要的一个工作就是对复杂性的控制,因为所有的系统到最后如果崩溃的话,基本上都是因为复杂性失控导致的。
3. 关注分布式
目前,所有的系统基本上都是分布式的,所以在设计系统时基本上都是以分布式为先,应该假设这个系统就是分布的。分布式代表什么?比如说一个请求可能会失败,你要做好对失败的处理,一个请求可能会不在你期望的时间内返回,会有一些超时的设计,可能涉及资源竞争。总而言之,各种在单机和单个程序内不会发生的错误,在这个产品里面都会出现,所以在设计的时候,一定要把这些因素考虑在内。
4. 性能
虽然Donald
Knuth曾说过一句颇有名的话,就是“所有未成熟的性能优化是所有罪恶的根源”,意思是过早地做优化对整个系统是不利的。但是,还有一点我觉得可能没有说太清楚。所有的系统设计其实都应该有一些性能的考虑在内。虽然说不要过早做优化,但是应该定好几个标线。与此相关的还有Jeff
Dean在一个PPT里列出来的:你应该对各个硬件和软件的各种延迟、各种吞吐量,有一些量化的理解,无论是硬盘、SSD、内存,还是CPU
Cache,都应当有一个量级上的理解,以此保证你对这个性能的预估不会差得太离谱。因为如果架构开始出错,性能设计存在瓶颈,最后将极难推广。
5. 技术以外的其他因素
其实在我看来,架构是几个因素的综合考虑,包括:
技术,也就是目前有哪些技术可以用;
人员分配,你现在有哪些技术人员可以用。因为不同的工程师可能使用的技术不一样,举例来说,有些热门语言,比如Erlang VM上的Elixir,还有Spark、Scala等的适用人群和像是Python、php,或者Golang、C++等语言是不一样的。
产品,不同的产品对人和技术的要求可能也不一样;
时间表,你打算何时发布你的产品?
架构需要从这几个角度全面考虑,找到一个折中的点,也就是可行的位置。有时在这几点受限的情况下,可能是很难找到这个各方面都满意的平衡点。我认为架构师需要从这些因素排选,比如说某产品不行,就要砍掉一些功能;这些人员、这些技术不合适,可能就需要换技术或人;时间表如果满足不了就往后延迟——这是一个动态的过程,通过调整这几个因素来寻求平衡。
程序员更多是考虑一个局部的问题,而架构师可能更侧重全局考量。程序员眼中更倾向于一个点化的世界,可以有很多假设,但架构师往往不能有那么多假设,他需要根据实际情况来考虑问题,包括所掌握的人力资源、技术限制、时间安排等——在这些因素的约束下,选择将受限,一切也不再那么理想化。
另外一方面,架构师对知识了解的广度和深度,可能比程序员要高一些。因为架构师的某些决策,有时甚至会对他人的最终结果产生影响。如果程序员写了很多代码,那个代码却无法做出产品,这无疑是时间的浪费,而我觉得在这一方面,架构师应该承担更多责任。
最后,架构师需要跳出技术——这是我想要给大家分享的一个建议,即不完全只看技术,而是要综合考量包括技术和技术以外的因素,将其想象成一个类似于数学优化的问题。换一个角度来说,就是给你一些材料比如技术和人员,你要获得结果包括产品和团队,而这个时候很多情况是不理想的、有限制的,包括预算和时间的限制,所以你要思考如何灵活处理这个问题,包括调整各种输入、限制,甚至是输出,从而获得更优或者至少是可行的方案。架构师的世界,不仅仅是技术,通常囊括人员、沟通、产品等各种因素。把这些因素都考虑进去,才是一个完整的架构设计。
> 个人觉得架构师需要具有以下几特点:
1.知识广度:需要知道主流技术为什么诞生,能解决什么问题?如果同一种业务用不用的技术来实现,会有什么哪些优缺点?比如:流行的ORM框架Mybatis 和 hibernate ,他们之间的优缺点是什么?要有清晰的认识会能在技术造型时做出正确的决定。
2.抽象能力:对业务和技术进行抽象。业务抽象就是对需求进行分析后,能够建立完美的实体类以及他们之间的联系。技术抽象是对整体架构进行一个分层,各层之间的交互。这至关重要,如果技术抽象能力不足,这会导致整个系统的架构不灵活,难以维护和扩展。
3.知识的深度:至少是某个领域的专家,比如消息队列,activeMQ熟悉其源码,知道其实现。
4.优秀的学习能力:对新的技术和前沿性的技术进行学习,使用它来解决工作中的业务问题。
那么你该如何去做呢?我觉得可以从以下几个步骤开始:
1: 扎实的JAVA 基础,Think in java上介绍的内容都能理解,做到这一步恭喜成为了程序员。
2:熟练使用主流框架,如:mybatis,spring 等。
3:研究过至少一种以web框架的源码,如spring mvc ,struts 等。
4:架构过或者参与过高并发系统设计,知道如何应对突发情况。
5:对自己所处的业务能够根据自己的知识维度,提出优化建议或者预测其风险点。
Java 工程化、高性能及分布式、高性能、深入浅出。性能调优、Spring,MyBatis,Netty 源码分析和大数据等
> 小菜进阶架构的书籍
引用:http://blog.csdn.net/hongshan50/article/details/7047667
作为Java程序员来说,最痛苦的事情莫过于可以选择的范围太广,可以读的书太多,往往容易无所适从。我想就我自己读过的技术书籍中挑选出来一些,按照学习的先后顺序,推荐给大家,特别是那些想不断提高自己技术水平的Java程序员们。
要好多年才能懂得,最好不是去震惊世界,而是要像易卜生所说的,生活在世界上。
技能,是为了从事某项工作或活动所需要学习的专门知识与训练的成果。程序员能够写程序,只能算是技能过关吧,而能写好程序,才算具备了程序员的基本能力。而架构师,如其名,架构显然不是一种技能,而是一种能力,综合应用多种技能的能力。架构师也许不像在工程师阶段写大量代码,但实际是需要具备代码能力的,但仅此一项能力远远不足。在我自己的经验中,至少还需要沟通、管理和领导能力。
《领域驱动设计》 《企业应用架构模式》 《领域特定语言》 《恰如其份的软件架构》 《面向模式的软件架构》
一、Java编程入门类
对于没有Java编程经验的程序员要入门,随便读什么入门书籍都一样,这个阶段需要你快速的掌握Java基础语法和基本用法,宗旨就是“囫囵吞枣不求甚解”,先对Java熟悉起来再说。用很短的时间快速过一遍Java语法,连懵带猜多写写代码,要“知其然”。《Java技术手册》
1、《Java编程思想》
在有了一定的Java编程经验之后,你需要“知其所以然”了。这个时候《Java编程思想》是一本让你知其所以然的好书,它对于基本的面向对象知识有比较清楚的交待,对Java基本语法,基本类库有比较清楚的讲解,可以帮你打一个良好的Java编程基础。这本书的缺点是实在太厚,也比较罗嗦,不适合现代人快节奏学习,因此看这本书要懂得取舍,不是每章每节都值得一看的,挑重点的深入看就可以了。
2、《Agile Java》中文版
这本书是出版社送给我的,我一拿到就束之高阁,放在书柜一页都没有翻过,但是前两天整理书柜的时候,拿出来一翻,竟然发现这绝对是一本好书!这本书一大特点是以单元测试和TDD来贯穿全书的,在教你Java各种重要的基础知识的过程中,潜移默化的影响你的编程思维走向敏捷,走向TDD。另外这本书成书很新,以JDK5.0的语法为基础讲解,要学习JDK5.0的新语法也不错。还有这本书对于内容取舍也非常得当,Java语言毕竟类库庞大,可以讲的内容太多,这本书选择的内容以及内容的多寡都很得当,可以让你以最少的时间掌握Java最重要的知识,顺便培养出来优秀的编程思路,真是一本不可多得的好书。
虽然作者自己把这本书定位在入门级别,但我不确定这本书用来入门是不是稍微深了点,我自己也准备有空的时候翻翻这本书,学习学习。
二、Java编程进阶类
打下一个良好的Java基础,还需要更多的实践经验积累,我想没有什么捷径。有两本书值得你在编程生涯的这个阶段阅读,培养良好的编程习惯,提高你的代码质量。
1、《重构 改善既有代码的设计》
这本书名气很大,不用多介绍,可以在闲暇的时候多翻翻,多和自己的实践相互印证。这本书对你产生影响是潜移默化的。
2、《测试驱动开发 by Example》
本书最大特点是很薄,看起来没有什么负担。你可以找一个周末的下午,一边看,一边照做,一个下午就把书看完,这本书的所有例子跑完了。这本书的作用是通过实战让你培养TDD的思路。
三、Java架构师之路
《架构之美》《面向模式的软件架构》《领域驱动设计》《实现领域驱动设计》《软件框架设计的艺术》
到这个阶段,你应该已经非常娴熟的运用Java编程,而且有了一个良好的编程思路和习惯了,但是你可能还缺乏对应用软件整体架构的把握,现在就是你迈向架构师的第一步。
1、《Expert One-on-One J2EE Design and Development》
这本书是Rod Johnson的成名著作,非常经典,从这本书中的代码诞生了springframework。但是好像这本书没有中译本。
2、《Expert One-on-One J2EE Development without EJB》
这本书由gigix组织翻译,多位业界专家参与,虽然署名译者是JavaEye,其实JavaEye出力不多,实在是忝居译者之名。
以上两本书都是Rod
Johnson的经典名著,Java架构师的必读书籍。在我所推荐的这些书籍当中,是我看过的最仔细,最认真的书,我当时读这本书几乎是废寝忘食的一气读完的,有小时候挑灯夜读金庸武侠小说的劲头,书中所讲内容和自己的经验知识一一印证,又被无比精辟的总结出来,读完这本书以后,我有种被打通经脉,功力爆增的感觉。
但是后来我看过一些其他人的评价,似乎阅读体验并没有我那么high,也许是因为每个人的知识积累和经验不同导致的。我那个时候刚好是经验知识积累已经足够丰富,但是还没有系统的整理成型,让这本书一梳理,立刻形成完整的知识体系了。
3、《企业应用架构模式》
Martin的又一本名著,但这本书我只是泛泛的看了一遍,并没有仔细看。这本书似乎更适合做框架的人去看,例如如果你打算自己写一个ORM的话,这本书是一定要看的。但是做应用的人,不看貌似也无所谓,但是如果有空,我还是推荐认真看看,会让你知道框架为什么要这样设计,这样你的层次可以晋升到框架设计者的角度去思考问题。Martin的书我向来都是推崇,但是从来都没有像Rod
Johnson的书那样非常认真去看。
4、《敏捷软件开发原则、模式与实践》
Uncle Bob的名著,敏捷的经典名著,这本书比较特别,与其说是讲软件开发过程的书,不如说讲软件架构的书,本书用了很大篇幅讲各种面向对象软件开发的各种模式,个人以为看了这本书,就不必看GoF的《设计模式》了。
四、软件开发过程
了解软件开发过程不单纯是提高程序员个人的良好编程习惯,也是增强团队协作的基础。
1、《UML精粹》
UML其实和软件开发过程没有什么必然联系,却是软件团队协作沟通,撰写软件文档需要的工具。但是UML真正实用的图不多,看看这本书已经足够了,完全没有必要去啃《UML用户指南》之类的东西。要提醒大家的是,这本书的中译本翻译的非常之烂,建议有条件的看英文原版。
2、《解析极限编程 拥抱变化》XP
这是Kent Beck名著的第二版,中英文对照。没什么好说的,必读书籍。
3、《统一软件开发过程》UP
其实UP和敏捷并不一定冲突,UP也非常强调迭代,测试,但是UP强调的文档和过程驱动却是敏捷所不取的。不管怎么说,UP值得你去读,毕竟在中国真正接受敏捷的企业很少,你还是需要用UP来武装一下自己的,哪怕是披着UP的XP。
4、《敏捷建模》AM
Scott
Ambler的名著,这本书非常的progmatic,告诉你怎么既敏捷又UP,把敏捷和UP统一起来了,又提出了很多progmatic的建议和做法。你可以把《解析极限编程拥抱变化》、《统一软件开发过程》和《敏捷建模》这三本书放在一起读,看XP和UP的不同点,再看AM是怎么统一XP和UP的,把这三种理论融为一炉,形成自己的理论体系,那么你也可以去写书了。
五、软件项目管理
如果你突然被领导提拔为项目经理,而你完全没有项目管理经验,你肯定会心里没底;如果你觉得自己管理项目不善,很想改善你的项目管理能力,那么去考PMP肯定是远水不解近渴的。
1、《快速软件开发》
这也是一本名著。可以这样说,有本书在手,你就有了一个项目管理的高级参谋给你出谋划策,再也不必担心自己不能胜任的问题了。这本书不是讲管理的理论的,在实际的项目管理中,讲这些理论是不解决问题的,这本书有点类似于“软件项目点子大全”之类的东西,列举了种种软件项目当中面临的各种问题,以及应该如何解决问题的点子,你只需要稍加变通,找方抓药就行了。
六、总结
在这份推荐阅读书籍的名单中,我没有列举流行的软件框架类学习书籍,例如Struts,Hibernate,Spring之类,也没有列举AJAX方面的书籍。是因为这类书籍容易过时,而上述的大半书籍的生命周期都足够长,值得你去购买和收藏。
10本软件架构师必读书籍:
《软件架构:基础,理论与实践》《面向模式的架构,卷I:模式系统》《设计模式:可重用面向对象软件的要素》《软件架构实践》《开发人员软件架构》《软件架构基础》《大型软件项目重构:成功实施复杂重组》《软件系统架构:利用视点和观点与利益相关者合作》《企业应用架构模式》《软件架构师的12个基本技能》
以上是关于架构师素养及从小菜进阶架构(CTO)的书籍的主要内容,如果未能解决你的问题,请参考以下文章
今天,公司架构师跟我分享多年的私货 | 进阶之路必读书籍(附下载链接)
Java架构师之路:从Java码农到年薪八十万的架构师,最牛Java架构师进阶路线