《技术领导力》笔记(5)—— 系统架构
系统架构工作
软件架构概念
软件架构是对于软件实体组织形式的阐述,使用框架的意义是快速完成软件架构设计,而不是取代它。软件架构设计带来的效果是高性能、高可用、可扩展。如果你的程序非常简单,不超过1000行,只有一两个人用,那就没必要做架构设计。
软件架构离不开团队的组织架构,组织架构是软件生命周期的执行者。离开了组织架构,软件架构就是纸上谈兵。
架构不是设计出来的,而是根据业务的发展演化出来的。互联网的架构并不适合所有的行业,因为你没有互联网的业务场景。
软件架构师岗位
很多公司设置了软件架构师的职位,但并不具备调动组织架构的权利,这样的职位往往不能发挥架构师的作用。软件架构师必须是一个组织的领导人,才能把软件生命周期的拆分落实。一个开发团队的领导,如果不能在架构方面给出意见,他就会丢掉自己的技术领导力,成不了技术管理者。优秀的技术管理者,技术在前,管理在后。70%的时间用在技术上,30%的时间用在管理上,但是管理工作依然不会被落下。
软件架构落地
架构师思考技术时,要更多地考虑技术对生命周期拆分的支撑,以及不同技术实现的成本和收益。以最少的成本达到最高的增长,这是架构师追求的目标。
系统架构能力培养
提升驱动力
一个技术团队必须有技术定位,或者说是技术愿景,才能留住对技术很有热情的工程师。明确了技术定位后,要制定团队技术能力提升计划,特别是系统架构能力方面的提升。技术提升的驱动力来自以下几个方面。
- 业务需求:阿里技术发展强大的驱动力就是双11的业务高峰。技术真正发挥价值的地方,就是对用户产生影响的时候。
- 系统老旧:原有的系统采用的老技术已经没有人懂了,没办法维护。
- 外部资料:公众号、峰会、博客上都有新技术的介绍和分析。多了解外部技术发展趋势,对于明确团队发展方向很有利。
技术团队需要不断前进,只有不断给自己设置愿景的人,才会尝试提高自己的技术能力。
步步为营
不应该一开始就承担大项目。应该从小的、无关紧要的项目入手,并且不要希望该项目能够做大。否则,你就会做出过度的设计,并且通常会把项目的重要性看得比它实际的要高。或者更糟的是,你会被预想的不切实际的项目规模吓得望而却步。因此,要从小规模的项目做起,把细节考虑周全,不要盲目憧憬过大的愿景或虚幻的设计。如果项目不能解决一些相当紧急的需求,那么它十有八九是被过度设计了。
学习能力
架构师是一个充满挑战的职业,知识面的宽窄往往决定着一个架构师的架构能力,需要阅读大量的技术书籍。从程序员到架构师是一个很大的变化,架构师需要从很多方面考虑,而不只是考虑这个模块该用哪种设计模式去开发。想要成为架构师,需要有耐心,不断学习,拓宽自己的视野,不要局限于自己眼前的项目,多关注开源技术,多关注技术社区新动向。
常见问题分析
无从入手
看了很多书,看完之后只停留在会搭建开源框架的阶段,只会采用固定套路,没有大彻大悟地理解系统架构。
轻视设计
职场新兵常见问题如下。
- 需求沟通完,马上开始设计数据库表结构。
- 没有设计,提笔就是写代码,想到哪儿写到哪儿。
- 设计图一团糟,别人看不懂。
如果架构师参与到项目开发中,团队成员就不会轻视设计。敏捷开发也需要设计,快并不意味着偷工减料。
技术优先
技术本身没有好坏,问题总在不断变化,技术是为了解决问题。框架的选择,实际上是对技术可行性的选择,需要符合当前的业务形态。没有哪个技术或者框架是最好的,只有最适合产品需求的,才是最好的。
想做好技术的使用者并不容易,架构师必须深入了解不同的技术,知道这些技术的强项和弱点,懂得取舍。
技术人员要成为架构师,必须跳出技术的视角,换一个合适的角度去看技术。要把时间花在研究生命周期规律和业务增长上,花在选择合适的技术上,而不是追求新潮或自己喜欢的技术。学会很多技术,不代表能够利用这些技术来解决问题,只是解决问题的手段多一些罢了。无论是新的还是旧的技术、先进的还是落后的技术,只要场景合适,都可以采纳。
过度设计
设计方案如果不结合实际情况,考虑得太复杂,实现起来就会特别复杂,还容易出错。简单地说,用不上的设计就不要去实现。