第一次用編程語言寫自己的工具，挺有成就感的說~ 也有一些體會。工具的任務是把SilkTest腳本轉換成python腳本。裏面有一些工作特定相關的假設和需求。主要所得是心得體會啦~
Draft for SilktTest to Python transfer:
requirements:
"word1 word2" -> "word1 word2"
{ -> [
} -> ]
NULL, null, Null -> None
TRUE, true -> True
a.b.c -> a['b']['c']
["","a"] + ["","b"] -> ["","b"]
// -> #
line continuation
':' is not key delimiter in SilkTest
SilkTest keyword
=, +, -, (, ), [, ], ; , .
Addintional Plus:
1. detect what library is used in the test case , add sentence to import the library: Open_dialogname_**, Set_dialogname_**, Dlg_Set_dialogname_**, Dlg_Get_dialogname_***, Close_dialogname_***
dialoglib = lower(dialogname) + "lib"
from raftlibs import dialoglib
from dialoglib import *
2. add sentence like Activate_App(), sDocumentsDir = os.path.join(getPathToDesktop(), "TestFiles") at appropriate place
3. Function call refactor:
VerifyObjectActive()
從軟件開發的角度來看：
這是一個編譯器，需要完成的基本任務是1）提取字符串和註釋 2）分解單詞 3）轉換 等等.. 這些需求適用於“編譯器”這個領域。用什麼結構存儲中間數據，功能之間是怎麼樣的接口，這些是可選的，算是程序設計的一部份。程序結構之下，分隔符是什麼，字符串的文法，這要看具體的處理對象。
基本任務，和加分任務可以根據難易程度和需求程度分優先級。一般把簡單的最需要的任務放在前面完成。通常一個亟需的任務能夠通過簡單的機械化做到，是引發想開發這個軟件的原因。幾個亟需的任務也可以一個一個在程序中完成。當任務的個數很多很亂時，可以提取它們的共同點、合併到一個任務之中，將任務內容化爲數據儲存。
在實現越來越多的任務時，可能整個程序的結構都要發生改變。原先的設計不一定能保證完成後來添加的任務。改變是痛苦的，學習理論知識能幫助建立有效的結構。
理論知識研究通用的結構和算法。但是我們的需求可能很明確，用簡單愚笨的結構就能實現，沒有許多意外情況需要考慮。不管怎麼樣，理論知識能建立起一個模型和一類需求之間的紐帶。不過理論的書籍很少討論需求。會說明這這是用來幹什麼的，但是需求爲何需要很少解釋。而模型的建立來自複雜的需求，閱讀理論書籍而不理解需求會有障礙。也是我覺得爲什麼項目開發經驗的收穫之一就是理解需求。
從軟件測試的角度來看:
在添加任務時，一個完整的功能不一定被一個獨立的模塊實現，它可能被劃分到幾個部分中。這些部分的前趨和後繼可能會需要調整。部分和部分之間有時可能重疊，有時可能不重疊，這會讓人頭疼。將一個功能錯誤地劃分或者放入錯誤的部分就會導致問題。另外在需要覆蓋所有情況時，對個別特殊情況枚舉不全也會導致錯誤。