大家好，我是错误先生。

最近在学前端，有空整理一个前端课程的技术总结。今天要说的内容是在我前端学到HTML的时候。学了课程不是得实机操作一下嘛，编写一个简单的html文件。

一般来说在装windows的电脑上很容易操作，新建一个txt文本文件，然后将后缀名改成html就行了。

图1-新建HTML文件

然而我发现，我的mac电脑上，右键并没有新建文本文件。

图2-mac的右键菜单

对比windows的右键菜单，mac右键能提供的“菜品”显然寒酸许多。不要求你整个新建word、excel啥的，既然新建文件夹功能都做了，新建文本文件总来一个吧？！

图3-windows右键菜单

虽说打开文本编辑器，写好内容然后保存也可实现，不影响工作。但有不少人的习惯（比如我）仍是先决定文件保存位置，然后才开始工作的。

怎么解决呢？我找了一些材料，比如下面这个：

4种方法，让你在macOS上快速新建txt文本文件

总结下来，几乎只有下载第三方app（例如New File Menu之类的）可以【完美】复刻windows的右键新建功能。但我不怎么喜欢这个方案：如果任何一个简单的功能都得去下载app才能完成，那过段时间我的mac电脑不得塞满N多app？

吸引我的是其中一个方案：自动操作（）

自动操作

自动操作是苹果公司为他们的Mac OS X系统开发的一款软件。只要通过点击拖拽鼠标等操作就可以将一系列动作组合成一个工作流程，从而帮助你自动的（可重复的）完成一些复杂的工作。

也就是说，自动操作是苹果官方为用户提供的一款能够实现自动执行繁琐重复的工作，提高效率的工具。

以新建文本文件为例，我们需要先在【访达】->【应用程序】里找到【自动操作】程序

图4-/自动操作 程序位置

点开后，选择创建一个“应用程序”，然后分别选择：【资源库】->【实用工具】->【运行】

图5-选择创建“应用程序”

图6-选择“运行”

接下来是最重要的一步，在代码框中，补充如下一段程序：

tell application "Finder"    set selection to make new file at (the target of the front window) as aliasend tell

图7-新建txt文件的代码

之后，关闭自动操作窗口，将编写好的脚本命名保存（例如：New Blank File）

图8-保存脚本

此时还没有结束，【访达】->【应用程序】里会多出一个名为"New Blank File"（你刚才起的名）的程序。但是你运行程序后，它只会在【应用程序】目录下创建txt文本文件，这显然不是我们想要的。

为了解决这个问题，我们需要按住Command+左键将【自动操作】拖动到右上角，使其变成【访达】菜单栏里的一个程序。

图9-添加到访达菜单栏

这样，我们就可以借助【访达】，在任何位置创建文本文件了。

不过，我们写的代码到底是啥意思呢？

是苹果公司在1993年十月随system 7.1.1推出的一款脚本语言。其特点是比较接近英语这样的自然语言。

其实windows也有自己的脚本语言，就是VB。但是丰富的右键菜单避免了我们想新建个文件也要写脚本解决。安装个winrar、360什么的，软件也会把自己对应的功能加进右键菜单里去。但苹果对这块比较有洁癖……so，我们瞎折腾了一番，认识了自动操作这款神器工具，也算对造成麻烦之后的补偿吧。

想要理解前面的代码，学习语法是必须的。我在网上找到了两个讲得还算全面清晰的教程，在这里分享给大家。《简明教程》适合快速入门。《权威指南》则适合作为工具手册使用。

简明教程：

提取码：608l

权威指南

提取码：y2n6

经过粗略学习，对有个基本的了解之后，我们可以尝试将前面的代码拆解，一个部分一个部分地理解它的意思：

图10

1. on run{input, }

类似其它语言中的main函数，是程序的入口，即最开始执行的代码块。input是用户输入，是相关参数，基本不需要变动。

结尾相应有return，end等语句，也不需要管。

2. "Finder"

tell是中最重要的流程控制语句，作用是指定脚本要控制的程序对象。因为在指定路径下新建文件需要借助程序【访达】完成，所以后面跟的是 "Finder"。

tell语句的一般格式如下，后面需要跟end tell结尾。

tell application "XXX"    ...end tell

3.at (the target of the front window)

指明创建文件的位置，在哪里呢？在当前窗口所在位置。

4.make newfile

这句好理解，就是新建一个文件，位置在上面已经说明了。

5.set to

set语句起到的是一个赋值作用，而则代表用户选择的目标。这一步就把之前make new file的结果赋值给了，其结果就是新建完txt后，这个txt文件会处于被用户选中状态。

需要注意的是set的语法问题。

set A to B在自然语言环境中，表达的是“将A的值赋给B”的意思。但是在中，set A to B表达的是“将B的值赋给A”。因为A才是变量，B才是值。

这样的确很别扭，如果换成

Dim A =B 或者

Set A = B

就好理解得多。所以，很难说接近自然语言是件好事还是坏事。

6.as alias

as语句会起到强制类型转换作用，而alias是一个需要花些功夫理解的对象类型。简单来说，alias是文件的指针（在iOS或者mac OS系统体系中，它被称为“替身”）。可以通过它获取文件内容，而且即使文件改变路径，也不影响指针指向。在set as alias后，也就指向了文件的指针。

集合起来，那句代码可以翻译成“启动脚本时，告知【访达】：在当前窗口路径下新建一个文件，并选中（将文件指针传递给鼠标选择）”

这么强大，显然不单是为了解决一个新建txt文本问题的。大家有什么有意思的想法欢迎在留言区留言哦！

留言区

软件架构设计系列之九（软件架构文档化）

软件架构设计系列包括软件生命周期、软件开发模型、软件开发方法、基于架构的软件开发、软件架构设计（软件架构设计原则、软件架构质量属性、软件架构风格、软件架构设计、软件架构文档化、软件架构评估）等。

软件架构文档化

记录软件架构的活动就是架构编档过程，也就是架构的文档化。它包含两个方面：一是过程，编档过程能促使架构设计师进一步思考，使得架构更加完善；二是结果，描述架构的文档将作为架构开发的成果，供项目干系人使用。

1、架构文档的使用者

架构文档的使用者是项目干系人。编写技术文档（尤其是软件架构文档）最基本的原则之一是要从读者的角度来编写，易于编写但很难阅读的文档是不受欢迎的。

架构的主要用途是充当项目干系人之间进行交流的工具，文档则促进了这种交流—— 项目干系人希望从架构文档中获得自己所关心的架构信息，如：系统实现人员希望文档提供关于开发活动的不能违反的限制及可利用的自由；测试人员和集成人员希望能从文档中得到必须组合在一起的各部分，并以此得到一个正确的测试黑箱；项目经理希望根据所确定的工作任务组建开发小组，规划和分配项目资源。

2、合理的编档规则

编写架构文档和编写其他文档一样，必须遵守一些基本规则，这里将任何软件编档（包括软件架构编档）的规则归纳为 7 条：

（1）从读者的角度编写文档。

（2）避免出现不必要的重复。

（3）避免歧义。

（4）使用标准结构。

（5）记录基本原理。

（6）使文档保持更新，但更新频率不要过高。

（7）针对目标的适宜性对文档进行评审。

3、视图编档

视图是最重要的软件架构编档概念。视图的概念为架构设计师提供了进行软件架构编档的基本原则。架构文档化就是将相关视图编成文档，并补充多个视图的关联关系。

视图编档的组织结构（内容及编排次序、大纲）一般包含 7 个部分。

（1）视图概述：对系统进行概括性的描述，包含视图的主要元素和元素间的关系（但并不包含所有元素和元素间的关系，如：与错误处理相关的内容可以放在支持文档中）。主要表示可用多个形式：图形、表格、文本，通常用图形形式，使用UML 语言来描述。

（2）元素目录：对主要表示中所描述的元素及其关系进行详细描述，包括：元素及其 属性、关系及其属性、元素接口、元素行为。

这部分是文档的主要组成部分，其中要注意：

—对元素及其协同工作的行为进行编档，如用UML 的顺序图和状态图描述行为；

—对接口进行编档，图9-19 说明了这部分的内容。

（3）上下文图：用图形展示系统如何与其环境相关。

（4）可变性指南：描述架构的可变化点，如在软件产品线中，产品线架构通过变化，适用于多个系统，因此，文档中应包含这些变化点，如各系统要做出选择的选项、做出选择的时间。

（5）架构背景：为架构的合理性提供足够的、令人信服的论据。包括：基本原理、分析结果及设计中所反映的假定。

（6）术语表：对文档中每个术语进行简要说明。

（7）其他信息：描述不属于架构方面的必要信息，如管理信息（创作者、配置控制数据及变更历史）。

4、跨视图文档

软件架构由多个视图文档来反映，按前面所述的要求完成每个视图的文档后，需要对这些文档进行一个整体的“打包”工作，这就是跨视图文档。它包括如下内容：

（1）文档有哪些内容，它们是如何组织的：视图目录（含哪些视图）；视图模板（即前面描述的视图文档，企业可以通过规范化来定义统一的、公共的视图模板）。

（2）架构概述：它描述系统的目的、视图之间的关联、元素表及索引、项目词汇。

（3）为什么架构是这样的（基本原理）：跨视图基本原理解释了整体架构实际上是其需求的一个解决方案。即解释了做出决策的原因、方案的限制、改变决策时的影响及意义。

5、软件视图

软件视图通常分为三种类型：

（1）模块视图类型：为系统的主要模块实现单元编档。

（2）构件和连接件视图类型：为系统的构件和连接件执行单元编档。

（3）分配视图类型：为软件的开发和执行环境之间的关系编档。每一视图类型中，又有一些常用的形态，可以把这些形态归纳成架构风格（简称风格），

大量的架构风格供架构设计师选用，例如客户机/服务器是一种常见的架构风格，它是构件和连接件视图类型中的一员。架构风格是对元素和关系类型的特化，它还包括如何使用这些元素和关系类型的一组限制条件。架构结构/视图分类如下表所示。

6、软件架构重构

前面已论述了架构编档，即在架构设计时完成编档工作。但是还有另外一种情况：系统已经存在，但不知其架构，即架构没有通过文档很好地保留下来（文档的缺失/失效）。如何维护这样的系统并管理其演变？其关键就是要找到软件架构，软件架构重构就是研究解决这一问题的方法，它是反向工程之一。

架构重构需要工具的支持，但任何一个工具或工具集对架构重构都是不够的。因为：

工具往往是面向特定语言的；

数据提取工具经常返回不完整的或错误的结果，因此，应在多个工具提供的结果间进行补充、验证和判断；

重构的目的（文档的用途）不同，决定了需要提取什么数据，这反过来影响了工具的选择。以此为原则，就是架构重构的工作台方法，如 SEI 开发的 Dali。

软件架构重构由以下活动组成，这些活动以迭代方式进行，如下所示。

（1）信息提取（View ）。可以使用各种工具进行信息提取，如解析器、语法分析器等；可以利用 build 和 文件中关于模块的依赖关系；可以从源代码、编译时制品和设计制品中提取静态信息；可以使用分析工具提取动态信息。

（2）数据库构造（ ）：将提取的信息转化为标准的形式，并置于数据库中。

（3）视图融合（View Fusion）：将数据库中的信息组合在一起，生成该架构的一个内聚的视图。

（4）重构（）：构建数据抽象和各种表示以生成架构表示，主要由两个活动组成：可视化和交互、模式定义和识别。最后生成需要的架构文档（）。

上述过程中，架构是由重构人员通过对系统做出一组假定来获得，为了最有效地生成这些假定并对其进行验证，必须让熟悉系统的人参与此项工作，包括过去参与系统开发的人员或现在正在对其进行维护的人员。