何种情况下的工作适合编写脚本？

客户端

并非所有工作都适宜编写脚本，需视情况而定。根据重复性，我们可作如下区分。

依复杂度来进行区分。

那么就能评估自己的工作是否有必要使用脚本了。

PostgreSQL

重复性低的场合都无需写脚本，写了也是用完就弃。随着重复性增加，脚本就有了必要性。不过也要考量复杂度，复杂度适中时，都能写脚本且推荐写脚本。然而，事情一旦变得复杂起来，脚本的收益就会降低。这是因为复杂的事情会使需求发生改变，而脚本要做到足够灵活是非常困难的，这涉及到诸多编程设计与工程方面的问题。并且其难度不是呈线性上升，而是指数级增长。总会有一个拐点，当复杂工作所需脚本过于复杂时，就完全无法平衡开发和维护脚本的投入了。所以有你写脚本的时间，我早就一个个做完了这话在特定时候是成立的，像一次性的所有活儿就不适合脚本。

日常即便做高复杂度的工作也不要写脚本。因为复杂度能接受且长期可维护的脚本所能做的工作，复杂度必然不高。实际上，很多时候我们难以预计频率，好多活儿未来的频率根本无人知晓。我以前在做数据中心自动化脚本运维工作时，遭遇过一次大规模故障。我们负责维护众多客户的自动流，这些流之间有着复杂的上下级关系与时间触发条件。故障发生时，客户无法登录工具的图形用户界面（GUI）来查看自己的流，于是要求我们直接从后端数据库找出某些完整流的上下级关系，再通过邮件发送。我当时采用手动方式，耗时数小时逐个查询并查询关联，为客户提供了80到100个节点的关联数据。后来恢复了，不知谁走漏了风声，跟其他客户讲我们数据中心能提供流的结构与数据。于是每周我们都会收到一两个请求，想要当前文档格式的流结构。要知道很多客户没我们客户端权限，正常应自行保管流设计。于是我只好设计了一个用PostgreSQL加shell编写的查询脚本，借助后端生成XML文件，下载后再转为pdf用于打印文档。该软件有XML文件输出接口，它自己也能读取并生成格式化数据，只要打开XML格式文件，将其打印成pdf就可以交差了。然后，这个活儿之前每次手动查找和处理要花30分钟到2小时，现在5分钟就能回复客户了。这套东西，我前前后后花了20个小时才设计完成。后来遇到bug，回去修复又总共花了大概40个小时。像限制层级、显示时间条件、多条件搜索，还有快速判断两节点间是否存在能串联它们的上游关联等功能，也在不断地添加进去。有些小流仅有10多个节点，很是干净。而某些大流，从一处搜索，能牵扯出半个数据中心的节点（达30多万个），实际上客户要求别涉及这么多节点，需重新设计与隔离，索要流结构就是想知道是如何牵扯的。同一套工具起初简洁干净、逻辑明晰，后来却不断遇到各种奇葩特例，这套脚本工具也逐渐变得杂乱难理。不过，总体而言，我开发与维护它所花费的时间，依旧比每遇到一个任务就重新做一次要少得多。并且有些复杂的流程，靠手动去做根本就不可能完成（像有几十万个节点的，手动搜索得花多少时间啊）。所以要具体问题具体对待。要是有那么一刻，我开发和维护这个工具花费的时间成本超过了我的工作时长？例如突然所有客户都能实时查看自己的流量了，那我肯定就不再继续维护这个工具了，之前花费的时间就当浪费了，在我搞自动化操作的经历里，这种情况确实出现过。现实生活复杂难测，不能认定上脚本就好，用手做就不好，要具体问题具体分析。