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