程序猿与架构狮的思路区别

在这里插入图片描述
(小编推荐一个学C语言/C++的学习裙【 八九二,六四三,六六三 】,入裙即送C/C++全套学习资料,满满的干货!)

发现问题

· 有一天,程序猿写了一条sql,发现执行挺慢的。想想也不是慢点太离谱吧,先提交上线吧。

· 有一天,架构狮写了一条sql,发现执行挺慢的。想想,是不是索引没加?explain一下看看。where字段加上索引。还是不满意,上google找方案。并且rtx找到DBA,跟他讨论起这条sql怎么优化,需不需要做表里新增索引。

对待问题

· 有一天,DBA找到程序猿,告诉他发现了一条慢查询。程序猿问:怎么优化?DBA噼噼啪啪说了出来。程序猿屁颠屁颠把代码一改,编译,上线。

· 有一天,DBA找到架构狮,告诉他发现了一条慢查询。架构狮问:还有没有发现其它慢查询?DBA说暂时发现一条。架构狮说:请你帮我重点监控一周,把这个系统上的所有慢查询和优化方案都一一列举出来,然后我们建立一个优化专项,统一把整个系统慢查询优化掉。之前,我们把这次专项作为案例,形成一门sql优化课程。无论新老员工,都应该接受这门培训。

处理问题

· 有一天,程序猿接手一个老系统。发现,这个系统执行速度非常慢!程序猿经常听到最近火热的不行的大数据平台、分布式计算,一拍脑袋,就用大数据框架解决!老板问他,解决这个问题要多久?程序猿说:我要先了解大数据平台、分布式框架,再搭建一套,怎么都得一个月之后了。

· 有一天,架构师接手一个老系统。发现,这个系统执行速度非常慢!架构狮找来这个系统的日志,仔细分析,发现系统处理的数据越来越多。看看系统所在的服务器,cpu、内存、磁盘io样样未满。看看代码,居然还是单线程单进程单连接。再看看日志统计数据,发现增量数据的条数是非常多,但是数据大小并不算大。架构狮主动找到老板,胸有成足的说:我会分几步解决这个问题。第一步是改为并发模型,多进程多连接等等,充分用满cpu;第二步把增量数据放内存上处理,充分用满内存。如果数据量继续增大,可以考虑再买一块内存加上。第三步是逐步规划研究实践分布式,应对将来业务发展带来的cpu、内存、硬盘等瓶颈。

写作最后

· 培养技术深度:程序猿需要对面临的问题,做出深入研究,做到知其然并知其所以然。

· 培养技术广度:程序猿除了需要理解计算机系统原理、网络原理等,更多跳出舒适区去学习新的技术。

· 培养系统思维:一个问题的出现,意味着同类的问题正在潜伏,找到根源并且解决掉。

· 培养体系思维:架构狮不是一个人,而且需要带领一帮程序猿去攻城略地。建立高效的体系,把程序猿培养为新的领袖–架构狮。

—END—

(小编推荐一个学C语言/C++的学习裙【 八九二,六四三,六六三 】,入裙即送C/C++全套学习资料,满满的干货!)

如果看了有所帮助,关注,转发,点赞,分享给那些还在迷茫的人吧。

猜你喜欢

转载自blog.csdn.net/weixin_43659511/article/details/84555568