最近由于老板需要做一個基于ArcGIS的地理分析工具。
經過分析權衡，最終選用了Python作為開發語言，開發出的工具將在ArcToolbox中運行。
由于需要存在比較復雜的用戶交互，ArcToolbox自帶的界面無法滿足需求，因此使用了PyQt做用戶界面。
這差不多還是我頭一次用腳本開發一個完整的應用。麻雀雖小（就數千行代碼），但也五臟俱全。
此帖就來總結一下做這個工具的某些經驗教訓。
一方面是自我總結，一方面也希望給各位迄今為止沒用腳本干過大程序的靜態語言擁躉的筒子們以微不足道的啟發。
先來討論一下設計上的差異。
說到設計，便會討論到設計模式。
對于設計模式的經典圖書《Design Patterns》而言，它所提出的模式基本是針對靜態語言，有關設計模式的實現方案的討論，也多半是針對C++一類的強類型靜態語言。在Python的開發過程中，會發現很多模式（或者其它的慣用手法）在原有實現的基礎上有不小的變化，甚至一些原則也有所變動。
最典型的例子是，在C++中，會提倡使用接口繼承而不是實現繼承；實現繼承改由委托來完成等一系列原則。
原先在C++中用接口繼承來分割接口與實現，在Python中，可以完全不使用繼承，而采用動態類型的特性，以類似于運行期Concept的方式達到接口的目的；
相對的，繼承盡管也用于設計中，但是更主要的是以extend這樣的方式對原有的類進行功能擴展，使得行為類似于decorator模式；減少擴展所需要的代碼量。
同時，python不支持重載（因為都是動態類型，也確實沒法重載）,如果想重載只能在函數體中用instance of這樣的函數進行判斷并手工分派（你拿字典分派也是手工分派），至少我目前只知道這個辦法。為了避免不必要的錯誤，建議大家還是用命名對多個重載函數顯示的區分，對于需要重載的構造函數，還是用Factory Method比較好。
關于重構，如果腳本沒有對應的測試，一定不要重構。對于靜態語言，這一條件要稍顯寬松，但是在Python這樣的動態語言上，就連Rename這樣的小型重構，都需要測試的保證，因為幾乎所有的錯誤只有在運行期才能被檢定出來。
其次，說一下代碼編寫的問題。
和C++相比，Python是很節省代碼的。一方面要歸功于語言機制，另一方面，Python豐富多樣的標準庫也為我們節省了不少的代碼量。
先來說說語言機制。
python一個很好的地方，就在于它將list、tuple、set、map/dict作為了build-in的要素，python的語法為這些要素提供了first class的支持。這使得我們在編寫容器相關操作時可以非常的方便。通常程序中大量存在類似的操作，在靜態語言中大量的語句可以在python中一句概括；在實際的編碼過程中，一定要靈活運用Python容器操作，寫出干凈利落的代碼。
其二就是動態類型也讓我們不需要為類型約束填寫過多的代碼，比如不必要的繼承與接口定義。這些代碼的節省其實是很可觀的。
其三，lambda、可調用體（其實就是仿函數）被語言機制直接支持，也是能節省大量代碼的重要因素。憑借仿函數，可以寫出大量在C++中難以編寫出的簡潔優雅的代碼。雖然boost費勁心思提供了functor與lambda，但是這些庫編譯之慢，調試之辛苦，相比大家都是有感觸的。
個人體會：
首先，靈活運用語法優勢，特別是一些通用的初始化格式，以及一些特殊的寫法，比如list的構造格式，slice等。這點往往也是腳本和靜態語言相比最大的優勢。
其次靈活運用內建函數。內建函數往往最能發揮語法優勢，甚至可以填補一些語法上的空缺。個人印象最深的，要數map/reduce/zip/lambda這幾個函數/語言機制。這些東西運用好了，能很大程度上簡化本來復雜的循環代碼。當然，對于多層循環而言，個人不太建議用嵌套的map一類的函數，外層的還是展開寫可讀性比較強，內層則保留以簡化結構；
同時我也不太愿意用大量的lambda函數，因為lambda函數本身很占版面，用多了代碼不那么好讀。必要的時候，還是用def定義出去比較好了。可調用體用恰當了，能簡化代碼，但是用的太多或者用法不好，也會影響可讀性。
同時，python對于內建類型的模擬做的很好，它提供了一系列buildin function的重寫方法，可以達到完全亂真的目的，這一點做的比C++還要好。
常規的內建函數就不討論了，Python的Ref上都有。
討論一下__getattr__, __setattr__這兩個函數。如果我們用getattr函數，或者XXX.xxx這樣的方法取得對象的一個成員，python首先會到對象內建的屬性字典中查找。如果找不到，要么raise一個exception出來，如果重寫了__getattr__，那就調用這個函數。因此這兩個函數實際上是實現了屬性get/set的掛鉤。一般來說，我用get/set都不是為了單純的get/set，實際上是為了保持對象內部的一致性，訪問的安全性，細節的封裝性等等目的，不同的屬性不是那么容易就用同樣的邏輯代碼。
本來像C#那樣為每個屬性提供獨立的get/set其實挺好的。Python則把所有的成員的get/set都攏到一起了。如果存取的附加代碼稍有差異，就容易寫出if...elif...elif...else這樣的分支代碼。
對這個問題，我是這樣做，屬性對應的成員變量放入字典中；每個需要做復雜存取操作的屬性，有一個存取函數，存取操作的區別用if分開，屬性與存取函數，則用一個字典來關聯。這樣，attr函數首先訪問存取函數的字典，按照需要執行存取操作。如果屬性不對應存取函數，那么就直接訪問屬性字典。
對于查找不到的情況，建議先捕獲異常，然后仿照的內建的屬性訪問異常拋出。
當然，有時候我也完全不用屬性，直接使用get/set函數的形式。不過這樣的話還是不如屬性來的方便。況且有時候括號漏寫了，代碼直接就來個運行期異常，也是挺郁悶的。
最后討論下私有函數。對于python來說不存在真正的私有函數，一般來講，要表達“私有實現”都是用“_”開頭的命名約定。
最后，討論一下調試和測試。
恐怕保證程序的正確性上，腳本還是要比靜態語言難。缺乏靜態檢測的腳本，連拼寫錯誤都要延期到運行期才能被檢測出來。因此大量腳本的調試，還是相當痛苦的。
在這里，確保有有效的單元測試對腳本比對靜態語言要重要許多。這次做的工具，一開始并沒在意，但是到了中期以后，發現調試占用了大量的時間（因為ArcGIS本身啟動速度就比較慢，執行一個調試周期很長），才開始給代碼部分地方補充了一些單元測試。有了單元測試以后，很大程度上縮短了調試周期。
單元測試也是腳本重構的必要條件。
對于腳本而言，由于代碼量比傳統語言少很多，因此利用TDD一類測試先行的方法恐怕比在靜態語言上的收益要大得多。
在腳本中，偶爾要寫一些防衛代碼。在工程的早期，我在防衛代碼，特別是類型約束的代碼上做了大量的工作。但是后來發現，這些防衛代碼本身引入的錯誤不必原始工程來的少。因此中期之后，對于內部的類，撤消了大部分的類型防衛代碼，而改用測試保證內部邏輯的一致性。這樣減輕了代碼量，提高了可讀性。
--------------------------------
其實腳本對于Web開發來說一點都不陌生。上次跟老李說這事，他說他至少寫了萬行的jsp和vbs代碼，調試不難，但是要保證正確性很難。測試很大程度上成為了腳本的救命稻草。
一般來說，腳本比靜態語言省代碼，比靜態語言方便，比靜態語言XX，但是如果沒有測試，這些，都是鏡花水月而已。