架构师之路

拿破仑曾经说过，不想当将军的士兵不是好士兵。

我非常认同这个说法，在我看来，不想当架构师的程序员不是好程序员。

很幸运，在追求梦想的第6年，我终于也当上架构师。过程不算短，但只要是目标实现了，一切都值了。

我想很多程序员也正在追逐梦想的路上。下面分享下我的架构师成长过程，希望能帮助到大家，少走一些弯路（大牛人就不要往下看了，哈哈）。

• 首先，先自我介绍下

本人在北京读的书，09年毕业，毕业后直接来广州，13年到深圳，一直从事java web后台开发。

言归正传，下面回到我们的正题-架构师，那么做架构师需要些什么能力呢？

• 我认为第一需要的是独立思考能力。

一个没有自我思想，不能独立思考问题，并提出解决方案的架构师不是一个合格的架构师。

咱先从最基础的代码思考说起：

我们刚开始学习编程时，可能只会复制粘贴代码，每个人都有这个过程，这并没有什么不对的。当我们有一定经验后，就应该反过去思考以前写的代码，看能不能进行优化。

建议从代码的可读性、合理性、可维护、安全性、性能等等角度去思考代码。

如果你经常去审查自己以前的代码并加以改进，那么你就进步了。

千万不要抱着只要功能实现了，代码写得好不好有什么关系，别人又看不到的思想。

确实，对于我们大多算人来说，没人去看我们写的代码，但这并不是你随便的理由。我们应该抱着，我写出来的代码就要像优秀开源框架中的源代码一样，逻辑清晰，结构合理，让人看了就觉得舒服的心态去严格要求自己，也唯有这样，你才能学到更多的东西，才能更进一步。就算没有别人看，至少还有你自己，是不是？人在做，天在看，请千万不要小看这些细节，所谓细节决定成败。

注重细节，注重代码质量，这是每个程序员的必修课，基本功扎实不扎实，直接影响你能走多远，你能飞多高。就像盖高楼一样，没有深而稳固的地基，却期望着大厦高耸入云，是不切实际的幻想。对于这方面的提高，推荐大家看本书《Effective Java》。当然，光看书是远远不够的，还是需要大家平时多思考，多运用书中介绍的技巧到实际项目中。所谓学以致用，只有当我们去使用时，才可能真正掌握。

除了代码思考，一个架构师还应该从更高层次去思考，那就是整个系统架构的思考。一个大的系统分几个子系统、各个子系统之间怎么通信、选用什么语言去实现、各个子系统选用什么技术框架去实现、选用什么数据库、各个业务表怎么设计等等，几乎包括了项目或产品达到最终使用这一目标的一系列与技术有关的活动。

每个公司都会有一套现成的架构（那些刚成立，什么都没有创业公司除外），你会发现里面有很多问题或者说不合理的地方。这时候你就要换位思考，假设你现在就是架构师，让你来做基础框架设计，你会怎么样去做，你会把一些基础功能做怎么样的封装，这将是十分有挑战的事情，是吧。还是那句话

永远不要只停留在思考层面，你要抽时间实际优化原有的架构，你想得再多，也比不上一次实践操作得到的收益大。

在你实际改变原有架构设计前，首先得看懂原来设计的方方面面，对每个细节都了然与胸。其实这个过程并不容易，且不说底层设计本身对技术有高要求，光是某些前任架构师繁杂，反人类思维的设计，就会让你望而却步。这时候你可能会说，我为什么要看懂这些不好的设计，我直接重新设计不就行了。当然，如果你是技术大牛，有相当丰富的设计经验，可以这么干。但我这里假设的前提，你还是个新手，这时候你迫切需要从原来的设计中寻找思路。不管再糟糕的设计，里面或多或少有设计好的地方，完全是可以借鉴或重用的。所以我们的思路，一定是在原来框架设计上进行一小步一小步的改进。当你把原来框架中所有不好的地方都优化之后，你就会惊奇发现，这个框架已经比最初的设计前进了一大步。在上家公司，我就是这么干的，通过反复思考和优化原来的框架，才获得长足的进步。

如果，你现在正在一家不怎么忙的公司，你千万不要让自己闲着没事做，那样只会荒废你自己。正好你可以利用这段时间充电，把自己放在架构师的位置去考虑整个系统架构并进行优化实践，相信坚持一段时间后，你一定会有很大的收获；如果，你现在在一家很忙的公司，比如创业型公司，那你也要抽时间去思考系统架构的问题并实践。这个过程没有捷径，唯有不懈的坚持和努力，才可能实现从程序员到架构师的蜕变。

刚刚说要看懂项目中原来的设计，在这之前，建议大家先看优秀开源框架的源码，比如：

• Jdk源码 Lucene源码 Netty源码 Spring源码

等等。推荐几本书给大家

• 《Netty权威指南》 《Lucene 原理与代码分析》 《HowTomcatWorks》。

一般优秀框架的源码还是比较好看懂的，有一定基础后，再来看项目中的基础封装，就比较轻松了。

当然对系统基础功能的架构和优化，这只是架构师一部分工作。从大处说，还包括系统怎么分，分几个系统，系统之间要怎么通信，选用哪些技术框架等等。对于这些，就需要去学习前辈们已经有的设计了，推荐经常上CSDN或Iteye等技术网站进行针对性的学习和了解，拓宽自己的知识面。对于各种技术选型，其实也不是很难，网上大都有相似的两种或几种技术的比较，再结合自己的技术功底，应该没什么大问题。这阶段最主要的就是拓宽自己的视野，不要一叶障目，不见森林。一定是所有相关的技术都有了解，从两个或多个备选方案中选择出最适合本项目的技术框架。其实每个技术方案都有好，或者不好的地方，你的选择一定是经过权衡，就目前阶段最优的方案。

那么怎么检验技术方案是否好呢。我觉得一个重要标准就是在满足系统功能前提下，从可扩展性和稳定性来判定。怎么说呢，我遇到一个项目，就是当前我正接手的项目。将前端、后台和socket通信全部放到一个系统中，通过一个tomcat提供服务。我也是醉了，假如说tomcat挂了，那么所有的服务都挂了。很显然，这样的架构是没有任何可扩展性和稳定性可言的，相应的性能也不好，并且对开发人员和运维很不友好。后面需要单独出后台和socket通信服务，将各个子系统解藕，增加系统的可扩展性和稳定性。

在我看来，一个好的系统架构，是不断演化出来的，没有一步到位或一成不变的架构（可参看《淘宝技术这十年》这本书）。在业务发展的不同阶段，我们的系统架构就要做相应的改变以满足业务增长的需求。但不管怎么变，一个总的标准还是系统的稳定性，可扩展性和性能，兼顾对普通开发人员和运维人员来说，系统架构是否足够友好。就像优秀开源框架提供的接口对开发人员足够友好一样。只有当你的系统架构，让普通开发人员和运维人员觉得很好使用，带来的是工作效率的提高时候，你的架构才真正有了生命力。

个人觉得，系统架构设计类似产品设计，只不过系统架构设计面向的是终端用户是开发和运维人员而已。一个好的系统设计，一定是对开发和运维人员足够友好。

关于思考能力就先说到这，以后有时间再说说其它能力。
欢迎大家各种拍砖，一起交流，互相提高。

<script type="text/javascript"> $(function () { $('pre.prettyprint code').each(function () { var lines = $(this).text().split('\n').length; var $numbering = $('<ul/>').addClass('pre-numbering').hide(); $(this).addClass('has-numbering').parent().append($numbering); for (i = 1; i <= lines; i++) { $numbering.append($('<li/>').text(i)); }; $numbering.fadeIn(1700); }); }); </script>

版权声明：本文为博主原创文章，未经博主允许不得转载。