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