软件开发有其生命周期，它应该是：

为什么说一个软件架构是很重要的呢？直接编程直接开发，多EASY？请看下面几点：

这个问题，可能大家一直都在问，包括一些IT企业也在问，对于这个问题的回答，可能不仅仅是一个简单的语句或者是定义就可以回答的出的，我们来看下面的几个形象的例子：

它即可以以一个完整的模型卖给你，你也可以把它全部打碎了重新从一个模型自由的再去组装成另一个模型，因为每一个乐高的模块在横向、坚向里都有标准的接口，这就是我们常说的高内聚、低耦合。

什么又是糟糕的架构

一个是清代的八股文，一个是孔乙己。还记得回字的四种写法吗？那么你专门就研究回字的四种写法 ，但你有没有想过我把回字折开来又可以变成几个字？是否好折？

要知道最时髦的并不一定是最好的

成功的软件又是怎么样的呢

我们谈的是软件架构，架构的最终体现是一个软件，那么什么是成功的架构什么是成功的软件呢？

大家看左边的这个图，是美国的“阿利伯克级”宙斯盾驱逐舰，右边的是印度模仿美国的宙斯盾自己设计和建造的”德里级”的“咖喱盾”驱逐舰。

两艘战舰一对比，怎么样？

架构，架构，到底什么是架构？我以前上大学时有一个70多岁的老教授，他上课每讲20分钟左右，需要2个同学”架“着去上一次WC，我们的架构师当然不是指这种”架构师“。那么我们一直说的架构，到底它是一个什么样的东西呢？怎么样又可以做出一个完美的架构呢？

架构就像是迷踪拳

动作轻灵敏捷,灵活多变，它其实违背一切传统拳法，因此可以克敌制胜。

架构就像是一件艺术珍品，有时一个看似简单的架构往往却是一件艺术珍品。

大家知道这幅画吗？他是挪威画家蒙克的一幅作品叫”呐喊“，蒙克这个人是一个疯子，这幅画很简单，就是随手涂鸦一般，但是大家可知道这幅画值多少钱吗？2012年该画在纽约苏富比拍卖上以1.19亿美元被拍卖。

架构的意境

一个好的架构不应该受限于框架，受限于语言，受限于技术，受限于各种条条框框，它是一种意境。

架构时需要考虑的几个基本因素

当然，我们这边主要说的是JAVA，那么作为一名学习JAVA、J2EE的架构师来说，要具备一些什么样的技能才能达到架构师的水平呢？

说了这么多架构，我们来说说架构师吧。

大家看到了没有，架构师的第一职责就是关注：non-functional requirements，即非功能性需求。很多人对功能性需求和非功能性需求的界线划分还是不清楚，我这边举2个例子说明一下吧：

功能性需求

页面查询，这个查询是关联哪些哪些数据库表，因为我的业务是有这样这样的需求，在界面A里点了一个按钮，然后弹出窗口B，在窗口B里要显示什么样的数据，最后界面A里点完后，当我打开界面B时哪块数据已经随之发生了更改。

非功能性需求

我们的系统查询速度小于2S，是否考虑使用异步查询、使用队队列机制，系统要求可以容纳1000个并发，这个系统要可以做成插件式的，要可以横向扩展，要符合XXX协议，这个Webservice要做成SOAP HEAD内带有BASIC认证，还是做成符合NTLM的认证的，还是使用令牌环认证的？这个下拉框要做成即可输入又可以下拉的，这块认证要访问LDAP？

很多以业务为主的项目型公司认为架构师就是trouble shooting（即排错、查错的意思，就是有错误、出问题了再找架构师），把架构师当成了fireman（救火员），可是你不自己想想为什么出了问题架构师过来2秒、2分钟或者1天半可以解决你们1个月几十人天天到零晨也解决不了的问题呢？嗯？

解决了说这是人家应该的，解决不了，说人家架构师不合格呢？是不是我们应该从这个软件最早的框架上、架构上去发现一下问题呢？

架构师啊，这不是一个trouble shooting的问题啊。

在节前我也进行了一些面试，出于纯技术角度来说，即走架构师，TECH LEADER这样的路线的侯选人。我还是发觉了不少的问题这也是中国的一个通病：即我们的程序员，很多时候不是在做程序，而更多时候是在做业务逻辑，成了一个某一领域的业务人员了。

当然，我们的程序员在其职业生涯的前3年、4年都是做某一块领域的代码的，这个是没有问题的，但是请一定一定记住，我们是编码，是IT，是程序员，不是“业务人员”！！！

什么是IT？什么是程序员？什么是Tech Leader？什么是架构师？这个问题大家有必要好好的去问一下自己，去好好的想一下，架构师的要求是什么？

我这边随便说一些东西：相信对一些要走技术道路的同学们是有帮助的：

TCP/IP协议，加密解密，计算机原理（增补反码），JPG码，MPEG2-3协议，逻辑电子电路，计算机编译器原理（堆、栈、队列），这些东西你平时工作时一直用到吗？这些是你一直关注的底层吗？

如果你是要走技术路线，一定一定请记得“数据库+ASP/JSP”不是技术，它只比表单制作，报表制作人员稍微强了那么一点点。

请一定记住，技术路线关注的是非功能性需求，非功能性需求啊，就是一种一通百通的东西，有了这块底蕴，任何需求和你说清了，对你来说是没有任何“难度”的，或者你再去学，是可以举一反三的啊。

最近一直面试一些侯选人，做架构师的，在此过程中我对此深有感受，找一个程序员开发不难，招一个架构师，难。。。唉，我觉得大家有必要要考虑一下，如果我走技术路线，我缺什么，我怎么补，还要关注些什么？

科技是第一生产力，管理方法论中的所谓的六SIGMA即六西格玛的第一条就是“技术人才是当下企业的第一生产力”，大家看看能够发财的是哪些公司？阿里，淘宝，支付宝，GOOGLE, 通讯，互联网，高科技等等等一些企业，他们靠的不是业务逻辑，而是真正的技术，这足以说明问题了，所以大家如果要走技术道路，请多关注一下更细节，更底层的东西吧。

这也是为什么我在之前的博文中所阐述的那些东西的原因，可见企业IT项目开发之七宗罪。

第一宗罪：重业务不重技术
    第二宗罪：编程开发人员沦为业务开发人员、沦为码农
    第三宗罪：IT市场沦为自由市场、小菜场一样的叫买
    第四重罪：技术无用论的诞生
    第五宗罪：闭门造车，与实际脱节，完全抛弃业务
    第六宗罪：消极怠工 
    第七宗罪：不思进取

架构师的分类

一般会把架构师分为：

一般就是把系统架构师和应用架构师合成一类。这个从本质上来讲倒没有什么太大的区别，不伤大雅。

架构师会做什么

一个架构师在一个团队中或者说在一个企业中它具体要做哪些日常工作呢？

架构师很牛B，可是架构师也是人，他不是超人。

技术，是架构师的Hard Skill，那么架构师的Soft Skill有哪些呢？

架构师不是皇冠上的明珠

大家一定一定要记住，架构师决不是像大家想像中的那样，是所谓的皇冠上的明珠，架构师承担的责任是相当的大的。

人类是如何进化的？学习、使用工具、社会协作性、不断的总结经验。

谈架构师的自我修养

学习之道

大家注意，上面这个列表在学习时是有先后顺序的，从上至下分别为第一步，第二步，第三步。。。。。。不要觉得枯燥，你可以去试试，真的，被折腾着和被快乐着。Bad artist copy good artist steal

1.

2.

3.

4.

5.

6.

7.

8.

点击「阅读原文」加入我们的小圈子！