走出架构误区，架构师并非想象的那么容易

几年前还记得我发表的软件设计的几大误区吗?

　　随着时代的发展，orm被更多人接受，九十年代出来的设计模式也被动地融入到主流框架，以致于设计模式到如今发展成了架构模式和业务模式，而存储过程也被开发者更少地使用。

　　以前提到的误区到如今已经没有什么争议了。

　　但随着年代的变迁，从前的小程序员也成了有多年工做经验的大咖了，更多人的头衔从程序员贴上了架构师标签。

　　而在互联网如此火的今天，在这样一个年代里，我又要出来指出几个误区。

误区一：

　　一套开发框架代替架构师

　　首先咱们来看下，架构师全称为“软件系统架构设计师”。

　　名字很长，但拆分开来是xxxxxx设计师，前面加上“架构”这一词突出了是一个从更高层次的考虑问题的设计师，最终仍是个“设计师”。

　　更高层次是相对而言，相对ui设计、局部的功能设计，更高层次是整体的设计，并非说架构设计要比ui设计厉害或重要。

　　“软件系统”则限定了在软件系统范围内的设计师，而不是弱电、土木工程等设计师。

　　一套开发框架只是代码架构，没错是架构，但实际开发中会对代码架构剪裁，这取决于需求的理解和系统的设计，相似嵌入式工程师对架构剪裁。

　　这其中最重要的因素仍是在于人为的设计，而不是架构，因此这种思想是错误的，并且错得可怕。

　　从ejb、ssh、ssm，框架历来都没有解决过问题。

　　离开了优秀的设计师，项目不提前完蛋，成本也会很高。

　误区二：

　　高并发、大数据是难点

　　主要是软件行业里伪程序员太多了，以致于这么基础的问题会成为一个难点。

　　其实问题很简单，属于大学教科书里的课后练习题。

　　大量培训学校，网络培训课程，以及混日子的大学生，和一波非专业对口人士转程序员，可能没有接触过。

　　然而随着时代发展，这一波伪程序员已经有了至关长的工做经验，在长达5年以上的业余时间里，并未系统地学习过，精力只够了解新框架，新技术，但为生活所迫留在这行业成为资深，甚至成为带团队的负责人。

　　而后团队开发模式很是落后，在这样的软件行业环境下，以致于程序有可能并发的状况下，程序运行出诡异的结果。

　　等到出现诡异的结果时，每每应用程序已经离当初开发完成到交付有了个把月的时间。

　　跑了一段时间后，互联网应用则会出现用户数量急剧上升所带来的问题，企业(zf)应用则须要导入历史数据或随着年代增加核心程序的业务数据堆积如山，致使海量数据性能问题须要解决。