高效開發的6個技巧
1.開放**庫，提倡資源共享
在我所管理的每乙個開發團隊裡，都要求開發人員開放各自的開發成果，有用的源**都需要集中存放在cvs**資源庫中，cvs**庫的模組對開發人員全部是開放式的。因為**庫是開發人員智慧型的結晶，看看彼此間的**，能提高整體開發水平，特別是對新來的職員，更是乙個非常好的借鑑前人經驗的過程。更有價值也富有趣味性的是，通過開發人員之間交錯的**瀏覽，有時還猶如白盒測試，**瀏覽者會無意中發現**中隱藏的錯誤。
但在面對目前越來越嚴峻的技術保密及安全問題上，需要對相關的部門和團隊組織從制度上加以約束。對於還沒有正常融入團隊的新聘人員，需要乙個階段考查期，**中隱含著技術保密及安全內容，不得不加以預防。
2.未雨綢繆，學會技術探索
由於技術障礙而延誤專案工期的先例也不算少，其中既有對技術需求評估的過於樂觀，也有開發人員的麻痺心態或者冒險心裡所引發的。比如當乙個元件公升級後，未經測試而直接置入實際專案中，可能是開發人員覺得憑著自己多年的設計經驗以及對此元件先前的認識，堅信能夠馬上使用，蜀不知有的公升級並非只是停留在修正小錯誤，而可能對結構、介面、甚至實現機理也會變動。當然有如此大變的不是很多，但所謂不怕一萬就怕萬一，要保障專案的成功，不可疏忽任何小節。
一般的，在系統分析師作專案分析時，就應該安排部分開發人員對即將應用的技術進行預先測試了，這既有對新技術的**，也有對久經未用的老技術的熱身。對決定著軟體核心、體系架構等的測試更需要提前，在作技術可行性研究時，就應該模擬簡單環境來嘗試了。
另外，設計之前的預先測試，不可能面面俱到，還有開發人員本身的差異性也很大，有些開發人員對某項技術很熟悉，但有些開發人員可能很陌生。對於陌生的技術千萬不要拿專案來邊學習邊測試，這包括元件、資料結構、演算法等，如果先前未經實踐應用而只停留在理論認識，可以單獨另外建立乙個測試工程，專門對陌生技術進行模擬測試，等測通可行之後，再搬遷至實際工程（當然複製、引用都行）。如果直接在實際工程中測試應用，或多或少的會留下無用**或破壞**整潔性，因為在嘗試的過程中很少能順利的一路過關斬將，勢必會有頻繁改動，有的改動甚至是漫無目的，難免會破壞原本寫好的的部分**。
3.每日整合，只有經整合後的半成品軟體才能準確體現整體進度
每乙個軟體專案，一般都有好幾個開發人員，較大的專案還可能是好幾個開發組一起參與設計的。在這樣的環境下，多個人一起投入設計的時候，難免會出現步調不一致，甚至某些成員在設計上會背離整體要求。為了減少某些成員設計偏差所帶來的損失，只有盡早把每個人的設計成果拿出來，整合構建在一起。而且這個構建的過程是不斷重複，整合的**是不斷累積的。即便上次構建很成功，也難以保證當前的設計都很正常，為此就需要重複構建。每天下班前構建一次，是比較常見的做法，下班前每個人的工作都有乙個小段落了，不會引起寫了一半的演算法，為整合編譯過去而不得不注釋掉正常的一段**。
或許有人認為，頻繁整合會浪費很多時間。其實不然，雖然每天得花上半個小時左右的時間整合，一星期累積也就兩三個小時。如果你的小組在一星期之內只整合一次，唯一的一次整合未必能在半天之內成功。更為嚴重的是，如果有乙個開發人員的設計偏離了方向，不僅是浪費他自己一星期的時間，可能會導致其他人的工作無法繼續，只得先等他糾正。
從專案進度的角度來看，也只有經完全整合的半成品軟體才能充分的體現整體進度。否則無法把握每個人所寫的部分**是否真正滿足專案的需求，更無從真正知道能否和其他人無縫結合。所以，如果認為每個人完成了90%的工作，整體完成量就是90%，那是絕對的錯誤，真正的結果是或許只有50%，或許更少。
4.關注介面友好，適時視覺凍結
發人員往往沉迷於**質量以及程式功能，不注重介面的友好，包括介面布局的雜亂、表現不直觀，提示資訊的不全、有歧義或過於專業，以及操作繁鎖等。好多軟體原本核心功能做的不錯，卻因操作介面不友善而失敗，或者重新返工。windows的成功也得益於介面友好，能讓乙個沒接觸過電腦的人很容易學會上網。我們做的軟體何不讓客戶也能快速的學會使用呢？開發人員要學會換位思考，設計的時候，多想想開發的軟體是給誰用的，要站在使用者的角度來看待這個軟體。有條件的專案團隊中，要有相當數量的專業介面策劃美工人員，十人以下的團隊一般有一至兩名介面設計師足夠了，在分工上好多介面設計師同時也可以參與文件編輯和產品包裝。
"視覺凍結"一詞引自馬魁爾的《微軟研發致勝策略》，意思是說在開發後期，介面就固定不動了。這樣做能使手冊文件可以定稿，以便能讓手冊也能盡快與客戶見面。在開發後期這樣做的確很有必要，否則也容易引起文件編輯和開發人員的內部矛盾，如果有非不得已的介面更改，開發人員應該及時與文件編輯人員溝通。
5.**少不了重構，但不可過頻，需要計畫
重構就是在不改變外在行為的前提下，對程式的內部結構做出調整、修改，以改善效能、減少隱含的錯誤。成功的重構，花很小的代價，就能給軟體注入新的生機，從而延長軟體的生命週期。
重構的好處顯而易見，能使老牛變快車，能讓軟體更加穩定。也正因為，好多程式設計師都沉迷於重構，今天寫明天構，頻率過高，最終延誤進度。我理解每一位程式設計師對**的成就感，也理解乙個善於創新的程式設計師，每當回頭看原來寫的程式時，總會發現許多不足。（這個不足並非說原先分析不到位、設計沒規劃好，而是等有了一定的經驗積累，或通過其它途徑學到新知識之後，會覺得原來做的不夠好。）但是重構是需要有計畫的，一般而言普通的專案計畫裡是不含有重構日程安排的，除非是純粹的重構專案計畫。
當然，不讓原始設計和重構並行，也並不是死搬硬套的，比如在專案開發中，如果某個常用函式不加以重構，呼叫的地方速度明顯過慢，就該考慮及時採取動作了。一般的，不是為迫切解決錯誤，而對其它地方影響面又較少的**，如果專案時間不寬餘就不應該重構（或者更確切的說是設計與重構並行），應以進度里程計畫為重。
6.**不僅要易讀，易用，更要追求多用
在軟體度量上，經常把**行作為衡量軟體規模的標準之一，正由此，有些程式設計師經常以為自己寫過的**行數可以作為資歷或能力的證明。其實不然，軟體是由眾多**通過一定的邏輯堆積而成的，而非機械可見物的形體堆積，量大並不代表功大。
我經常在程式設計小組會上強調**要以"易讀，易用，多用"為原則。
易讀這一點很好理解，學過程式語言的人都明白，不過易讀強調的是能讓人家容易讀懂你的程式，所以在乙個團隊裡一般都要求一致的**風格，包括注釋、命名、空格等，有時還考慮**整潔美觀。
易用，一般指一些公共的函式庫，能夠很方便的供他人呼叫。其中涉及到的有，引數的初始化，物件的建立、釋放，函式的健壯性等。
多用，一方面指執行概率，比如乙個公共的函式被別人呼叫次數越多，說明這個函式的價值越大；另一方面指生命週期，比如乙個軟體經過無數次的重構或者公升級，其中的一段**還是被原樣保留（當然覺得好才保留），說明這段**的價值就大。
所以，多用才是重點，其最能體現**的價值，也是評價程式設計師優劣的標準。
Bottle高效開發的幾點技巧
在 你已經學到一些開發基礎，並想寫你自己的應用了吧？這裡有一些 bottle 開發小技巧可提高你的生產力。預設應用 bottle維護乙個全域性的 bottle 例項的棧，模組層面的函式和修飾器使用棧頂例項作為預設應用。例如 route 修飾器，相當於在預設應用上面呼叫了 bottle.route 方...
11個高效的VS除錯技巧
介紹 除錯是軟體開發周期中的乙個很重要的部分，有時很有挑戰性，有時候則讓程式設計師迷惑，有時候讓程式設計師發瘋，但是。可以肯定的是，對於任何不是太那個微不足道的程式來說，除錯是不可避免的。近年來，除錯工具的發展已經使得很多除錯任務簡單省時了。本文總結了十個除錯技巧，當你使用vs的時候可以節省你很多時...
11個高效的VS除錯技巧
介紹 除錯是軟體開發周期中的乙個很重要的部分，有時很有挑戰性，有時候則讓程式設計師迷惑，有時候讓程式設計師發瘋，但是。可以肯定的是，對於任何不是太那個微不足道的程式來說，除錯是不可避免的。近年來，除錯工具的發展已經使得很多除錯任務簡單省時了。本文總結了十個除錯技巧，當你使用vs的時候可以節省你很多時...