几年前还记得我发表的软件设计的几大误区吗?
随着时代的发展,orm被更多人接受,九十年代出来的设计模式也被动地融入到主流框架,以至于设计模式到现在发展成了架构模式和业务模式,而存储过程也被开发者更少地使用。
之前提到的误区到现在已经没有什么争议了。
但随着年代的变迁,从前的小程序员也成了有多年工作经验的大咖了,更多人的头衔从程序员贴上了架构师标签。
而在互联网如此火的今天,在这样一个年代里,我又要出来指出几个误区。
误区一:
一套开发框架代替架构师
首先我们来看下,架构师全称为“软件系统架构设计师”。
名字很长,但拆分开来是xxxxxx设计师,前面加上“架构”这一词突出了是一个从更高层次的考虑问题的设计师,最终还是个“设计师”。
更高层次是相对而言,相对ui设计、局部的功能设计,更高层次是总体的设计,并不是说架构设计要比ui设计厉害或重要。
“软件系统”则限定了在软件系统范围内的设计师,而不是弱电、土木工程等设计师。
一套开发框架只是代码架构,没错是架构,但实际开发中会对代码架构剪裁,这取决于需求的理解和系统的设计,类似嵌入式工程师对架构剪裁。
这其中最重要的因素还是在于人为的设计,而不是架构,所以这种思想是错误的,而且错得可怕。
从ejb、ssh、ssm,框架从来都没有解决过问题。
离开了优秀的设计师,项目不提早完蛋,成本也会很高。
误区二:
高并发、大数据是难点
主要是软件行业里伪程序员太多了,以至于这么基础的问题会成为一个难点。
其实问题很简单,属于大学教科书里的课后练习题。
大量培训学校,网络培训课程,以及混日子的大学生,和一波非专业对口人士转程序员,可能没有接触过。
然而随着时代发展,这一波伪程序员已经有了相当长的工作经验,在长达5年以上的业余时间里,并未系统地学习过,精力只够了解新框架,新技术,但为生活所迫留在这行业成为资深,甚至成为带团队的负责人。
然后团队开发模式非常落后,在这样的软件行业环境下,以至于程序有可能并发的情况下,程序运行出诡异的结果。