对于架构相关书籍的读后感

今天在课上阅读了老师所给的几本书籍，其中对于《大型网站技术架构：核心原理与案例分析》这部书阅读最为详细。此书从多个层面说明了如何构建一个高可用、高性能，高可扩展性的网站，从中也对架构感触颇深。

现在我们生活在一个技术更新换代非常快的时代，对于此，架构便是非常重要的，软件架构所指的就是说相应的系列性的抽象模式，可以为设计大型软件系统的各个方面提供相应的指导。从本质上来看，软件架构是属于一种系统草图。在软件架构所描述的对象就是直接的进行系统抽象组件构成。连接系统的各个组件之间就是做到把组件之间所存在的通讯比较明确与相对细致的实施描述。处于相应的系统实现环节，那么就会使得细化这些抽象组件成为现实的组件，比如可以是具体的某个类或者是对象。从面向对象领域进行分析，那么各个组件之前实施的连接实现往往是接口。软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构件的描述、构件的相互作用、指导构件集成的模式以及这些模式的约束组成。软件架构不仅显示了软件需求和软件结构之间的对应关系，而且指定了整个软件系统的组织和拓扑结构，提供了一些设计决策的基本原理。其中，架构其实有一些固定的模式，例如我们现在常用的MVC模式，就是一种非常常见的架构模式。软件质量是“软件与明确地和隐含地定义的需求相一致的程度”。更具体地说，软件质量是软件与明确地叙述的功能和性能需求、文档中明确描述的开发标准以及任何专业开发的软件产品都应该具有的隐含特征相一致的程度。其实在上节课看梦想改造家的时候，老师提到了软件应该关注人文关怀，以面向机器的模式来与人沟通，结果往往是完整的项目（而不是狭义的“软件项目”）割裂开来，皆不欢喜。这种情况我一直在思考，究其原因，一方面是组织不够完善，另一方面，软件开发也缺少人文关怀——软件可以没有活力，而软件开发却不能没有活力；程序可以像机器一样，程序员却不能像机器一样。要改变这种状态，就应当增添人文关怀（这里要多解释一点，“人文”其实也可以叫“人性”，它与“文”并没有太多关系，只是“人性主义”约定俗成翻译成了“人文主义”而已），把开发开发人员以及用户当作人当然，做到这一点并不容易，因为许多人印象里，软件开发人员就是“闷瓜”（充其量是“闷骚”），不好捉摸也不好打交道，那么干脆把他们当成工具来对待好了，“人性化”这样高难度的处理还是免谈为妙。但是事情并没有这么简单，因为不善于沟通，并不意味着开发人员不在乎人文关怀，想法，绝大多数人内心其实是愿意接受而且认可这些关怀的。只是因为许多开发人员不善于表达，因此并没有太多资料研究和论述软件开发中的人文关怀（或者开发人员真正在乎的人文关怀），软件开发人员进行软件开发的时候，会对用户进行心理画像，但在这一过程中其实也有一点把用户平面化，有的时候刻画不够全面，就会引起软件不受欢迎，从而使软件失败。

架构中的质量属性（非功能需求）。目前大家的软件工程都强调功能性需求，对于如何在项目中开发非功能性需求的论述都很少。非功能性需求呢？业务和产品经理技术出身还好，非技术出身对非功能性需求几乎一点感觉都没有。而非功能性需求，对于项目的进度、范围和成本的影响，比表面上看却大得多。现在工作当中，重功能需求轻非功能性需求是一种常态，这也造成从项目一开始就欠了一屁股技术债，只能从生产宕机中一次次交学费。这就是软件架构师在项目当中的需要承担的重要职责，对系统的非功能性需求进行设计！

做好最初的架构，对于实现软件的人文关怀，实现软件的功能需求，实现软件的价值都有着重大的意义，当我们进行架构的时候，要进行充分的思考，尽量在不失去功能性的同时保留人文关怀，对架构进行补充与创新，创造出更好的软件。