最近從碼農變成了 *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提供的函數即可。 而自己也實時試用了下，發現十分好用。
至此，第一階段的迭代就此完成
