演化思维
一开始的架构设计非常重要，架构一旦确定，它将支撑很长一段时间，好的设计能延长架构的生命周期。
同时，优秀的架构师深知，能够不断应对环境变化的系统，才是有生命力的系统，架构的好坏，很大部分取决于它应对变化的灵活性。
所以具有演化式思维的架构师，能够在一开始设计时就考虑到后续架构的演化特性，并且将灵活应对变化的能力作为架构设计的主要考量。
提前考虑却不过早实施，即避免了设计不足，又不会导致过度设计。
技术选型错误的惯性思维
当程序员成长为技术负责人或者架构师后，经常要面临着技术的选型，仔细想想，我们是不是会犯以下惯性思维：
-
“因为大家都在用它啊”，比如我面试的这个程序员的团队之所以选择这个技术，正是因为它比较流行，如果我们不用，我们可能就落伍了。
-
“因为我没有用过这项技术，我感兴趣，我想学一下”，其实这也无可厚非，对于新技术的拥抱是每个程序员都要保持的。但当你不只是代表你自己，而是代表团队的时候，仅仅这么想也是不对的，你要站在团队的角度综合判断，合适的才是最好的。
-
“因为我只知道它啊”，这种情况更多。你为什么选择 C3P0 连接池？因为那时候我不知道还有哪些别的数据库连接池……
技术选型的理性思考
当我们作为单个个体去学习时，我们可以选择那些流行的、有市场前景的、能提升自己能力的技术，但当我们代表团队，代表一个项目去做技术选型的时候，我们更需要理性思考的。
-
业务需求的考虑
-
短周期项目还是长周期项目
-
对现在的规模是否明确，对未来规模能否准确预测
-
重要的项目（稳定优先）还是不重要的项目（适当激进）
-
团队自身的考虑
-
复用优先，积累为重，不轻易重复制造轮子
-
先小面积实验，再大面积应用
-
考虑到团队的规模及发展
-
考虑当地的人才储备（当年转型互联网，曾考虑Ruby，最后放弃了，因为在我们这个地方，几乎招不到相关技能的人）
-
技术本身的考虑
-
技术的匹配度，满足度。技术是为业务服务，不要为了技术而技术
-
该技术在行业的应用程度或者对发展有正确判断
-
技术的选择最好有延续性，便于深度积累
如何避免过度设计
虽然没法完全避免过度设计，但下面几个建议希望对大家有用：
-
一定记住设计是为了满足需求，不要为了设计而设计；
-
不要花费太多精力在你觉得一年之内不会提出来的需求上；
-
如果一个实现能比较容易的改成另一个实现，现在选择容易的一方；
-
不要花太多时间在设计上，人人都超不出自己的界限；
-
不要指望一下把所有细节都设计出来，边写边重构是个好习惯；
-
最重要的一点，架构是不断演化的，根据业务进展不断迭代，不断完善
抽象、分层、分治和演化是架构思维的四种最重要的思维模式；
