说明

本文是 我做系统架构的一些原则 的读书笔记。

如何评价一个技术是否有价值？

在决定是否要使用某技术时，会遇到这个问题。这决定了我们是否要使用这项技术。（值得用吗？）
用下面3个问题审核该技术：

1. 能提高效率吗？
2. 能使系统运行的更稳定吗？
3. 能降低成本吗？
   成本：人力、时间、资金
   人力成本体现在：慢、贵、人容易犯错、沟通需要成本。

如果某技术无法促成上述三条中任何一条，就不值得使用。

应站在怎样的角度去评价一个系统？

系统所服务的用户的角度：系统是否好用、易用？是否稳定？
不要站在实现系统（技术和底层）的角度去看！
没人用的系统一文不值。

应选啥样的技术？怎么选技术？

随大流

1. 更成熟更工业化的技术栈
2. 最好是全球流行（国际化）
   具有普适性的技术生命力更强。因为技术只有在被使用时才具有生命力。

站在巨人的肩膀上

1. 使用成熟的解决方案。只要在使用时注意在它和自己的项目间加一层抽象，隔离开二者即可。（方便后续更改方案）

完备比性能更重要

等真正遇到性能问题时，再考虑解决。

怎么让系统更完备、更加可扩展？

1. 制定标准、按标准做事。
2. 降低耦合，灵活使用设计模式。
3. 分离业务逻辑和控制逻辑
   控制逻辑：和具体业务无关，为业务提供基础功能。指对程序流转的与业务无关的代码或系统的控制（如多线程、异步、服务发现、部署、弹性伸缩等）
   如创建用户和创建用户后发短信通知的文本是业务；而异步，发送短信，短信发送失败的重试等是控制。

用事实说话，不凭主观经验臆断

不断重复过去无法进步，学习自己本不知道的东西才可能进步。
做决定前应该先收集相关资料进行分析，不能完全依靠个人臆想。

关注问题本身

真正的问题究竟是什么？
在对问题本身的认识并不透彻的前提下给出的解答方案，真的是解决问题的最优方案吗？更何况如果本身还不知道如何实现该解答方案的话，就更应该先回归问题本身。

敢于冒险，勇于探索

进步源于探索，探索肯定要付出代价。
但这一定好过不敢冒险、不敢犯错、害怕失去带来的结果。既然一定要做决定，为什么不自己决定呢？我们要做的是提升自己做决定的能力。