要深入的说，其实开发，严谨点说就是将业务逻辑转换为代码的那些人，DBA 和程序员在大部分时间的交集除了规范，审核，在就是互看不顺眼。DBA时刻不在吐槽，就这烂数据表设计，不出性能问题才怪，开发其实脑子里面大多数时间差不多只想回应，你懂个啥，不就会操作个破数据库。老子是不想干，干了分分钟让你失业。
转眼时光荏苒，N年过去了，在新公司转到软件开发部，近朱者赤，其实大部分时间大家是互补的，还好没有怎么被怼，但从此就有一个看法，不懂开发及开发思想的DBA不仅只能在低端混着，并且如果你技术能力在差点，剩下的只能是被怼和蔑视。
从我一个外行来看，开发人员分为几个等级，业务逻辑解释者，能进行系统结构设计与业务结合并且能初步设计一些基础架构的人，能根据业务制定编写基础框架的人，对整体的系统架构与业务关系有一定把握的人，最后这种人俗称架构师。
我接触的大部分开发都属于第一个层级，其实到了第二个层级没有多年的捶打和幸运的大项目的锻炼也是很难修炼的，止于其他等级我还是闭嘴吧。
个人理解，就算是逻辑到代码的解释者，其实也是有大咖和小白之分，并不是因为准入的门槛低，而活好干，钱好拿。这些开发者需要高效的的产出，业务代码质量的降低产生的bug,而如果要做到这一点除了要深入的理解业务外，还要精通所使用的架构和各种语言的组件，使功效比最大化。或许根本不需要多高的技术壁垒，细心，逻辑思维清晰，加之熟练的使用语言提供的更高效的架构和组件应该算是成功80%，而在上一个层次的程序员，就不仅仅是逻辑到代码的解释者，而是有一定大局观的开发者，这个层次的开发者不管上面提到的事情门清，而且考虑的事情要开始兼顾软件的易于维护，和考虑代码的生命周期等事情，这就已经开始涉及一些基础架构的事情，能将一些常见的业务架构化，简化逻辑解释者的工作强度，加速软件开发速度和提高代码的质量也是他们工作的范围。这个层级的人，知识点的范围不光是软件语言或架构，还要懂得一些数据库和组件的知识。至于更高等级的软件开发或架构师，视野会更开放，除了上面那些，还要有更大的大局局观，软件的生命周期，软件的质量体系，系统的集成硬件都要懂一些，并且还要开始牵扯开发的成本等一些事情。
而一个高级DBA,或者database architecture,要想做好工作，至少应该达到第二层级的开发匹配的水平，通晓各种主流数据库，能用数据库中提供的功能抵消开发中遇到的困难，并且知晓数据库中潜在的坑，深知数据库原理，在表设计之初能指导开发避免开发会由于当下表设计的缺陷，而让后续的系统运行在不稳定的状态，在开发之初根据不同的业务选择适合的数据库发挥数据库与业务最大的契合度。同时还要涉及考虑运维的需求，降低运维的工作量和出错的几率，配合devops的概念将数据库操作自动化，固态化。原来抱着一个数据库到死，不懂devops,不懂业务，只谈各种死规则的管理型dba的可能越来越会遭到白眼和各种怼。
另外随着数据库上云，以前的维护型DBA的日子也会越来越难过，产业要升级，开发要升级，DBA不升级，难道还真要怼怼更健康！
