演化思维

 

一开始的架构设计非常重要，架构一旦确定，它将支撑很长一段时间，好的设计能延长架构的生命周期。

同时，优秀的架构师深知，能够不断应对环境变化的系统，才是有生命力的系统，架构的好坏，很大部分取决于它应对变化的灵活性。

所以具有演化式思维的架构师，能够在一开始设计时就考虑到后续架构的演化特性，并且将灵活应对变化的能力作为架构设计的主要考量。

提前考虑却不过早实施，即避免了设计不足，又不会导致过度设计。

 

技术选型错误的惯性思维

　　当程序员成长为技术负责人或者架构师后，经常要面临着技术的选型，仔细想想，我们是不是会犯以下惯性思维：

• “因为大家都在用它啊”，比如我面试的这个程序员的团队之所以选择这个技术，正是因为它比较流行，如果我们不用，我们可能就落伍了。

• “因为我没有用过这项技术，我感兴趣，我想学一下”，其实这也无可厚非，对于新技术的拥抱是每个程序员都要保持的。但当你不只是代表你自己，而是代表团队的时候，仅仅这么想也是不对的，你要站在团队的角度综合判断，合适的才是最好的。

• “因为我只知道它啊”，这种情况更多。你为什么选择 C3P0 连接池？因为那时候我不知道还有哪些别的数据库连接池……

 

技术选型的理性思考

当我们作为单个个体去学习时，我们可以选择那些流行的、有市场前景的、能提升自己能力的技术，但当我们代表团队，代表一个项目去做技术选型的时候，我们更需要理性思考的。

1. 业务需求的考虑

• 短周期项目还是长周期项目

• 对现在的规模是否明确，对未来规模能否准确预测

• 重要的项目（稳定优先）还是不重要的项目（适当激进）

2. 团队自身的考虑

• 复用优先，积累为重，不轻易重复制造轮子

• 先小面积实验，再大面积应用

• 考虑到团队的规模及发展

• 考虑当地的人才储备（当年转型互联网，曾考虑Ruby，最后放弃了，因为在我们这个地方，几乎招不到相关技能的人）

3. 技术本身的考虑

• 技术的匹配度，满足度。技术是为业务服务，不要为了技术而技术

• 该技术在行业的应用程度或者对发展有正确判断

• 技术的选择最好有延续性，便于深度积累

 

如何避免过度设计

虽然没法完全避免过度设计，但下面几个建议希望对大家有用：

1. 一定记住设计是为了满足需求，不要为了设计而设计；

2. 不要花费太多精力在你觉得一年之内不会提出来的需求上；

3. 如果一个实现能比较容易的改成另一个实现，现在选择容易的一方；

4. 不要花太多时间在设计上，人人都超不出自己的界限；

5. 不要指望一下把所有细节都设计出来，边写边重构是个好习惯；

6. 最重要的一点，架构是不断演化的，根据业务进展不断迭代，不断完善

 

抽象、分层、分治和演化是架构思维的四种最重要的思维模式；