转发一篇有争议文章，如有任何不适请绕道：）：）：）
但随着年代的变迁，从前的小程序员也成了有多年工作经验的大咖了，更多人的头衔从程序员贴上了架构师标签。
而在互联网如此火的今天，在这样一个年代里，我又要出来指出几个误区。
1 误区一，一套开发框架代替架构师
首先我们来看下，架构师全称为“软件系统架构设计师”。名字很长，但拆分开来是xxxxxx设计师，前面加上“架构”这一词突出了是一个从更高层次的考虑问题的设计师，最终还是个“设计师”。
更高层次是相对而言，相对ui设计、局部的功能设计，更高层次是总体的设计，并不是说架构设计要比ui设计厉害或重要。
“软件系统”则限定了在软件系统范围内的设计师，而不是弱电、土木工程等设计师。
一套开发框架只是代码架构，没错是架构，但实际开发中会对代码架构剪裁，这取决于需求的理解和系统的设计，类似嵌入式工程师对架构剪裁。
这其中最重要的因素还是在于人为的设计，而不是架构，所以这种思想是错误的，而且错得可怕。
从ejb、ssh、ssm，框架从来都没有解决过问题。
离开了优秀的设计师，项目不提早完蛋，成本也会提高
2 误区二，高并发、大数据是难点
主要是软件行业里伪程序员太多了，以至于这么基础的问题会成为一个难点。
其实问题很简单，属于大学教科书里的课后练习题。
大量培训学校，网络培训课程，以及混日子的大学生，和一波非专业对口人士转程序员，可能没有接触过。
然而随着时代发展，这一波伪程序员已经有了相当长的工作经验，在长达5年以上的业余时间里，并未系统地学习过，精力只够了解新框架，新技术，但为生活所迫留在这行业成为资深，甚至成为带团队的负责人。
然后团队开发模式非常落后，在这样的软件行业环境下，以至于程序有可能并发的情况下，程序运行出诡异的结果。
等到出现诡异的结果时，往往应用程序已经离当初开发完成到交付有了个把月的时间。
因为这些非功能性需求导致的问题，会在开发交付半年后才慢慢体现，这些公司事前最多也只是在文档中或讨论中提到这些非功能性需求，但没有有效的测试办法去保证万无一失。
这也是我之前的一个误区，总以为我设计的软件是比别人高质量的，如何证明？请等半年或几年后看看我还维护得了，别人就得加班或跑路。
为什么不能通过测试，提前暴露这些问题，在交付部署以前？而不是凭借个人经验或个人能力。
交付部署以前，开发未完成时，除了对非功能性需求的考虑以外，还需要可量化的测试，用模拟的测试（mock）对服务对接点进行压力测试。
3 误区三，流行微服务架构
如果说上几年是xxx+xxx+xxx的开发框架比较火，
那么这几年是微服务比较火，这也和并发要求高的大环境下有关，微服务通常提供了分布式服务的解决方案。
其实这货就是以前得soa基于服务的架构分布式升级版，并非是必选项，然后水平不够该躺的地方还是得躺。
通常误引入微服务的原因只是为了解决误区二里的高并发，高可用。
但是又跌进了另一个更大的坑：
1、比以前更吃资源，花费更多购买服务器的费用；
2、分布式事务一致性难以保证，由网络导致的调用失败更多；
3、设计师经验不足强行拆分带来的更多服务的交叉引用；
4、发布和部署到生产环境和运维工作量更多，带来更大成本；
如果误区二里分布式的问题不能在以前就解决，傻傻地引入微服务架构，最终结果还是一样的，还会付出更多代价。
要说微服务这东西还真不是什么突然冒出来的概念，多年以前我就开发了一个webservice作为类似注册中心的总线，所有独立的dll丢到目录下就当是注册了，然后通过网关或是反向代理工具去访问多个点部署的它，实现负载均衡。
只是它并不是真正的微服务，当然也不像微服务那样吃系统资源，但它却解决了高并发、高可用的问题。
可将它看作微服务的过渡版，正因为接触这种类型的soa，才知道分布式服务设计的难点所在，绝不是单单引入微服务就万事大吉了。
关键点还是在于人，在于设计师，在于团队开发模式。
4 总结
没有实现不了功能的程序员，只有设计不出可靠软件的程序员。
没有带不了团队的程序员，因为每个程序员都能实现功能，并且总有更弱得新手可以带，难的是带出一个好的设计师，难的是带出一个能带人的设计师，从而带起整个公司甚至是行业。