這個title挺大，不過好在只是發在自己部落格上，說說也無妨。是我最近使用python開發的一些心得。
到現在已經有一年半的時間了。這期間用python寫指令碼越來越頻繁，有一些心得體會。
原先只是寫點很小很小的片段，最近的兩個月，用python用得特別頻繁，主要和我在做data mining有關，這期間，我有兩次失敗的寫python指令碼的經歷與大家分享。
第一次是想寫乙個遞迴檢查某個資料夾下，是否有重複的檔案，作這個工作的軟體很多，我google過，發現都太複雜了，搞得我都不會用，終於一天，由於我的硬碟實在是沒有空間了，加上我還想騰出空間來裝ubuntu，於是決定動手寫這麼個指令碼。
我當時的思路時，判斷檔案的大小，是否一致，先把重複的檔案分組顯示出來提示你，之後再點y進行刪除，這裡面的核心是我用了乙個reduce函式，來將乙個檔案和其它所有的檔案進行比較，看看兩兩是否大小一致，如果一致就將它歸為一組。這個思路沒什麼大問題，但在細節處理上，可能有些疏忽，總拿不出正確的結果，結果這時同事說了，可以用md5的方式來進行校驗，我一想心就涼了，我走了彎路，不過我想，我都寫到這個份上了（已經寫了將近１００行**了，我不願意放棄重來），還是繼續寫，把bug找出來，頂多以後這段**不能復用了，這次用完就扔了，結果後面我折騰了兩個小時，搞得筋疲力盡還是沒有成功，到晚上８點多，只好下班回去了，很是鬱悶。
這件事情是由於我沒有果斷的放棄前面將近乙個小時寫的**，而再搭上了後面兩個小時企圖去找出bug，結果還是沒有找出來。
隔天，我還是使用md5的方法，不到半個小時把問題解決了。
總結一下我覺得有幾點啟示：
要判斷形式勇於放棄，不要一根勁式的一條胡同走到底，如果我知道後面要再花兩小時，當然我不會這麼蠻幹，缺少預見性。
在動手寫之前，思考的更加深入一些，多問一些為什麼，比如：
有沒有其它的解決方案？
把這個問題拋給別人，看別人是怎麼想的？
做一些計畫，接下來我準備投入多少時間到這個指令碼的編寫上，如果到時間還沒完成，那我下一步的策略是如何？
潛在的風險在哪一塊上
如何將指令碼良好的分解和劃分，
大致分多少個步驟來實施等等
另外一次失敗的經歷是發生在今天，乙個指令碼足足寫了半天，最後，真正從絕徑中走出來，僅花了二十分鐘，起因是這樣的：
利用sqlserver的多表關聯來構建高維矩陣，因為sqlserver每一張表最多是1024列，所以我需要乙個小指令碼，每1000維劃分在一種表內，因此我要生成這樣乙個建立多個表建立的sql指令碼的python指令碼。
之前做了乙個簡單的原型是直接讀出所有維數，存在乙個表中的py指令碼，於是我就想在此基礎上覆制了乙份指令碼，進行局佈的修改，這樣雖然有一些冗餘**，但是也能適合我的需求了。
指令碼修改的比較隨興（我還是有些注意的），但是在一些細節上除錯總是調不對，而且python在除錯方面，也挺麻煩，基本上我是打print的形式。
結果除錯了很久還是沒有成功，最後我決定，將最複雜的那段進行重定，使用最傳統，我最熟悉的方式去寫，結果沒多久就搞定了。
這次給我的啟示是：
記得寫注釋，在寫乙個函式時，我原先一般都是急於要把方法實現，看結果，等到真正實現之後，由於下乙個緊接著的函式或是問題困擾著我，所以我就將焦點聚焦到另乙個問題的解決上了，這樣一環一環下去，乙個指令碼下來，基本上也就沒有寫什麼注釋，有的注釋是因為某些原因將指令碼注釋掉的，但怕後面還要看，或者是把這段指令碼再恢復回來，於是寫一段注釋，因此一般來說我寫的注釋都是過時的。結果很可能，由於在寫到下乙個某個函式時，或是整個指令碼在完整進行高試找bug時，想看某個函式中的變數，或是函式的作用時，由於當時寫的很快，在變數的命名和實現上都很亂，這就給整體的除錯找bug帶來了很大的難度。
因次，我的建議是在開始寫函式之前，嘗試花五分鐘時間來寫一下這個函式的作用。不妨放慢編寫整體指令碼的速度，我們的思想總是比我們實際編寫的指令碼要快很多，那既然是這樣不妨再放慢一倍的時間來織寫我們的**，會收到效果。
另外我的一點特別深的感受是要抓住整個全域性的主幹，就是先將整個程式的主幹搭起來，大致思考分幾塊，比如乙個main程式，我們先把主幹搭起來，不要糾纏於具體的step1()裡的乙個sub()方法如何實現，很多時候我就是因為繞到sub裡的subsub方法如何實現，等到真的實現的時候，我已經忘，這個子程式是為了誰工作的了。
main()
這次重寫最複雜的部分的**我就用了這個思路去處理， 結果就很簡單了。
還有乙個心得是，一般來說完成指令碼的功能大家肯定非常開心了，要麼接著做下乙個指令碼的開發工作，或者是喝點水去休息休息，即使知道比如**有得改進，一般會這麼說，嗯，下次在這幾個方面改進一下，這個**還有得完善，結果這次用完這段**以後，以後就再也不會去改它的**，時間久了，下次看得時候誰還記得**需要改時，如果過段時間拿出來執行，只求能順利執行就不錯了，談什麼優化或是重構啊，所以我的觀點時，寫完一段小的指令碼，無論多小，花兩個小時，來看一下這段**，思考一下，哪些**片段值得復用（有點回到asp的時代了），把它放到自己的公用庫里，這用才不至於，下次要開始一段新的指令碼**的編寫時又要重0開始使勁的google,導致生產力低下。
我覺得可以用乙個字來形容編寫**——織
表明你是在注入心力在編寫程式。
漫談軟體開發過程
乙個合理而又有效的軟體開發過程對軟體開發人員來說是至關重要的，決定著開發是痛苦的掙扎，還是不斷進步的喜悅。目前軟體開發一般過程包含以下幾個步驟 理解需求 架構設計 單元測試 監控埋點 整合測試 效能測試 文件樣例 上線流程和變更管理，下面我將針對以上幾個步驟進行詳細闡述。需求向來就是軟體開發過程中最...
原創 漫談戴明管理哲學與軟體開發（二）
續前 2 採納新的哲學 必須絕對不容忍粗劣的原料，不良的操作，有瑕疵的產品和鬆散的服務。這個所謂 新的哲學 其實可以簡單點理解成 精益生產 任何環節的瑕疵，一旦到了下乙個環節，其糾正成本都會被放大。如果不堅持追求高質量，而是片面節約成本，那麼最終付出的代價會遠超這些 節省 在戴明管理哲學中，其成本核...
python軟體開發目錄 軟體開發目錄規範
為了提高程式的可讀性與可維護性，我們應該為軟體設計良好的目錄結構，這與規範的編碼風格同等重要。軟體的目錄規範並無硬性標準，只要清晰可讀即可，假設你的軟體名為foo，筆者推薦目錄結構如下 foo core 存放業務邏輯相關 core.py api 存放介面檔案，介面主要用於為業務邏輯提供資料操作。ap...