1、程序员的3个层次
1.1、普通程序员
a、编写代码：正确处理业务流程和数据计算；b、让代码跑起来
1.2、工程师
代码：易读、易扩展、易维护、可重用；效率：开发高效、快速
特点：有洁癖、有工匠精神、有修养
1.3、架构师
权衡、决策
简化、灵活
应对复杂度
2、软件开发需要解决的问题
1、微观：代码
2、宏观：架构
3、分离控制与逻辑
控制：对程序流转， 与业务逻辑无关， 如：多线程、异步 、服务发现、消息中间件等， 另外还有业务逻辑中的判断(if else) , 是否可以去掉if else , 变为根据一定规则进行路由到不同逻辑， 这样也便于扩展， 职责分离，同时也便于测试
逻辑：实实在在的业务逻辑，解决用户问题的逻辑
控制、逻辑构成了整体的软件复杂度，有效分离得到最大简化
3、架构对软件开发的影响
好的软件架构：
人力成本：可以大大节省软件项目构建与维护的人力成本。
变更成本：让每次变更都短小简单，易于实施
风险：并且避免缺陷
扩展性：最大程度地满足功能性和灵活性要求
4、设计与架构的关系
二者之间没有区别，这是作者的观点。个人思考，一般的软件设计与架构设计差别还是很大的，面临的问题，思考的方式都是不一样的。
底层设计细节和高层架构信息是不可分割的。
6、复杂软件开发的思想
要想跑得快，先要跑得稳
7、软件系统的价值
软件系统可以通过行为和架构两个维度来实现实际价值
7.1、行为价值
包括需求的实现，以及可用性保障（性能、稳定性）
是最直观的价值
7.2、架构价值
软件系统必须灵活，必须容易被修改
7.3、架构价值是否是必须要有的？
看情况！
如果业务是明确的、稳定的，架构的价值就可以忽略不计；但业务通常是不明确的、飞速发展的，这时架构就无比重要
7.4、哪个价值维度更重要
第一个价值维度：系统行为，是紧急的，但是并不总是特别重要
第二个价值维度，系统架构，是重要的，但是并不总是特别紧急
开发人员的职责： 平衡系统架构的重要性和功能的紧急程度，为好的软件架构而持续斗争
如果忽视软件架构的价值，系统将会原来越难以维护，终有一天，系统将会变得再也无法修改，导致：重构！
7.5、只关注行为价值带来的问题
当我们只关注行为价值，不关注架构价值时，会发生什么事情？这是书中记录的一个真实案例，随着版本迭代，工程师团队的规模持续增长，但总代码行数却趋于稳定，相对应的，每行代码的变更成本升高、工程师的生产效率降低。从老板的视角，就是公司的成本增长迅猛，如果营收跟不上就要开始赔钱。
7.6、如何处理好行为价值和架构价值的关系
重要紧急矩阵中，做事的顺序是这样的：1.重要且紧急 > 2.重要不紧急 > 3.不重要但紧急 > 4.不重要且不紧急。实现行为价值的需求通常是PD提出的，都比较紧急，但并不总是特别重要；架构价值的工作内容，通常是开发同学提出的，都很重要但基本不是很紧急，短期内不做也死不了。所以行为价值的事情落在1和3（重要且紧急、不重要但紧急），而架构价值落在2（重要不紧急）。我们开发同学，在低头敲代码之前，一定要把杂糅在一起的1和3分开，把我们架构工作插进去。
