最近从码农变成了 *FC *
所谓的FC是Fault Coordinator的简称，是负责管理协调Fault相关的角色。
FC的主要职责是管理每个Fault，确保Fault很及时有效地处理。
FC的工作的一部分是为Fault建立一个Jira Issue，可以让开发人员在上面记录花费的时间，以便于项目管理统计开发人员的资源分配，以及评价开发人员的能力，查看开发人员的产出。
而在公司龟速的网络下，无论是Fault 管理系统还是Jira服务器都很慢。而在Fault特别多的时候，这基本上是FC的灾难
在万般无奈的情况下，开始写Web自动化的工具来帮助自己半自动化些重复的劳动。
所以这个工具的基本需求在开始前就已经明确了，就是半自动自己的一些重复劳动。
原始的软件工程是瀑布模型，是需求->设计->代码->测试->交付，也就是说刚开始很难拿到工具，这个不符合我的情况，我需要快速解决我的痛点。
开始设计之前，需要做些相关的需求细化。
- Fault 管理系统和Jira服务器是基于Web的，工具需要很好地支持Web
- 制作半自动化的工具不能耗时太久，占用工作资源
- 工具可以快速迭代，能很快帮助实现需求
经过上述需求细化后，要满足上面的需求，做了以下的分析：
- 选择支持Web良好的语言
- 语言需要有很多库
- 支持快速迭代
- 方案实现简单易行，不占用太多时间
综上所述，基本上Python是符合我的要求的。
在技术方案确定下后，下面开始快速迭代。
快速迭代的模型，就是每次出一个产品，包含客户所要的一个功能，然后在使用中有新的需求再重新加。
当然快速迭代中是有一个问题就是架构设计可能会变动的比较频繁，这对代码的之后的扩展性不利（前提是架构设计不是很好）。所以在快速迭代中一定要考虑架构的稳健性和扩展性，不能写死。同时快速迭代的用户体验非常好，至少我自己拿到后生活轻松了许多。
当选好模型后，我们就开始真正的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提供的函数即可。 而自己也实时试用了下，发现十分好用。
至此，第一阶段的迭代就此完成
