软件架构-性能与可维护性

今天看了2篇文章，正是我所思考的问题，觉得很有帮助，在此记录一下再加上自己的思考。

• 架构之路：前言目录

• 架构之路（一）：目标

• 架构之路（二）：性能

  前文说过，评价架构好坏是一个很主观的东西。既然大家写出来的程序都能跑，凭什么就说你架构好，我的架构就差？拿出来大家评评理，张三说好，李四说不行，王五说将就……究竟谁说了算？现在已经不是一个迷信权威的时代了，所以不管你多少光环加持，你都得说出子丑寅卯来，都得服众才行。 我觉得，这种现象的产生，抛开“同行相轻”和“流派之争”之类无厘头的东西，一个很重要的原因就是没有明确判断标准。

请牢记：没有牺牲，就没有胜利！ 那么，我们的策略是：特色突出、整体均衡。说得更直白一点：有亮点，没硬伤。这就够了！而我们的亮点就是：可维护性。（注意：不是可扩展，可维护性包含可扩展，但不仅仅是可扩展）

设计模式之类的东西是润滑剂是黏合剂，他们的作用是弥补架构的局部缺陷，更好的支撑架构。更极端的一种说法可以送给痴迷于设计模式的同学：设计模式是药，没病就不要吃药！

架构的一个天然目的就是：让代码更智能让程序员更傻瓜。换一张说法就是，架构要“创造便利，让程序员更关注业务”。

一、性能不是不重要，而是他没有可维护性重要。要理解这一点，首先要理解可维护性的重要（请再读上一篇我花数周找bug的段子）；然后要明白：解决性能问题，我们可以有很多代码以外行之有效的方法，而可维护性基本上就只能靠代码了；最后，还是要牢记：没有牺牲，就没有胜利！ 二、所以，在绝大多数情况下，当性能和可维护性相冲突的时候，性能让位于可维护性。我们采用其他办法来弥补代码性能不够高的问题。

开发过程中，很多的“优化”，其实只是你的想当然。与其这样想当然的优化，不如在拿到性能测试结果之后再有的放矢的进行优化。这时候，又回到了我们之前说的，是不是代码的可读性更重要？这样你才能迅速的找到该优化的瓶颈啊！否则，一堆乱七八糟看都看不懂的代码，你怎么去优化，你连该优化的点都找不到。

最后最后，有一些我能想到的名言警句供大家参详： 过早的优化是万恶之源 优化首先需要找到性能“瓶颈”。否则，任何人都可以随手一指，“这段代码需要优化”。 可读性更强的代码总是更好优化 硬件永远比软件便宜