最近从码农变成了苦逼的 FC

所谓的FC是Fault Coordinator的简称，是负责协调处理Fault相关的角色。FC的所负责的杂事特别多，很多情况是完全重复的机械化劳动。

在做FC的一个职责是为每个 Fault 添加不同分支的改动表格给开发人员，这样保证所有 Fault 影响到的分支都有相关改动。

在公司龟速的网络下，每个分支的创建是相当的折磨人，而且在Fault特别多的情况下，这个工作量巨大，基本上一下午的时间就没有了。同时每个Fault需要FC来帮忙建立一个Jira Issue来让开发人员统计工作，而这个无疑又是手动的劳作。

在万般无奈的情况下，自己开始写Web自动化的工具来帮助半自动化重复的工作。

这个工具的需求已经明确了，就是半自动自己的一些重复劳动。在开始coding之前，需要自己做些相关的使用。

因为自己做的主要操作是和Fault管理系统相关，平时手动的工具是Web 浏览器，所以基本上是与Http打交道的比较多。而能够快速迭代的语言在我看来Python是最合适的。主要原因是相关的库比较全，同时对Http的交互比较好。

在技术方案确定下后，下面开始快速迭代。

在原始的软件工程是瀑布模型，也就是需求->设计->代码->测试->交付，也就是说刚开始很难拿到工具，这个不符合我的情况，我需要快速解决我的痛点。

所以我选择了快速迭代的模型，也就是每次出一个产品，包含我所要的一个功能，然后在使用中还需要加时再重新加。这样能使我从一些体力活中解脱出来。当然快速迭代中是有一个问题就是架构设计可能会变动的比较频繁，这对代码的之后的扩展性不利。所以在快速迭代中一定要考虑架构的稳健性和扩展性，不能写死。同时快速迭代的用户体验非常好，至少我自己拿到后生活轻松了许多。

当选好模型后，我们就开始真正的Coding。

我们需要使用到urlib/urlib2还有Jira的Reset API，这样可以方便地模拟Web相关操作。

在快速迭代时，需要明白用户最痛的点是什么这样工具做出来才有用户使用。而之前最大的痛点在于自己每个Fault创建Jira Issue上。尤其是在Fault特别多的情况下特别明显。自己一上午的时间都花在这个上面。

有了这个基本的痛点后，自己就可开始设计软件基本的架构了。

我们可以看到基本的工具设计如上，其实时序图不是很复杂，所以基本上花了2天的时间从设计到功能实现。

在上图有所谓的Fault File，这个Fault File的格式选择也让我纠结了很久，到底如何选格式呢？后来为了便于EXCEL做图，就选择了csv格式，这样方便在EXCEL打开。而Python有csv相关的处理库，可以很方便地处理数据。

而Jira的Python Reset相当好用，很多Jira相关处理直接用API提供的函数即可。

而自己也实时试用了下，发现十分好用。

至此，第一阶段的迭代就此完成