模板，軟體開發中的應用
自六十年代中期到七十年代人們感覺到「軟體危機」以來，軟體工程也已經經理了整整35個年頭了；然而，手工作仿式的軟體開發形式在這兒依舊那麼嚴重，而更讓不解的是，每個人工作已經相當一段時間了，竟然沒有去嘗試著尋求新的解決方法（已經被別人用過很多次的方法）；結合於實際情況談一談自己幾年來的軟體開發經驗，以便於和更多的同道中人交流；應該具備的前提條件： l
模板的概念； l
重構的方法； l
oop思想何以出現如部門經理以及開方人員的困惑？
為什麼會讓乙個開發人員感覺到厭倦？其實問題就在於一慣的惰性開發方式(copy-paster)佔據著他們的頭腦，而沒有想著借鑑別人的或自己嘗試著利用更好的方式去解決自己面臨的困惑；軟體開發的本質就是製造軟體，然而和其它的製造業不同的是軟體開發裡的評測標準是乙個相當抽象的過程，然而，在開發過程中，有很多的模式是相同的或是有共性可找的；縱然不能說每個軟體按照某個特定的開發模式去做，但是找到了這些共性，我們同樣可以達到**的重複利用，再加之**的一次次重構，如何做到這兩點？可以從下邊的情況進行分析：
乙個優秀的開發人員會在工作中總結出很多開發經驗；而將這些開發經驗用了進行一定的分析，完全可以利用模板將其來實現**的重複利用，而不需要進行每個軟體開發過程中都進行copy-paster甚至重新手寫**；特別是在多人合作的專案中，當專案經理進行了概要設計、詳細設計之後，對其成員進行了各盡其責(此處並非是在排斥敏捷開發方法)，但是需要做到這一點著要要進行介面設計，即使按照螺旋式、級端開發模式也同樣需要定義各個模組的介面，而介面混亂將會的結果將導至軟體合併的災難，此時就根本也無法再提到「測試先行」；而大的方向如此，我們將問題範圍縮小到具體的某個功能模組中，其實，乙個小的功能模組也如乙個軟體一樣，裡邊包含了方方面面；同樣，以物件導向的方式來分析，即使乙個很小的模組也可以按如下所示的方式進行分析：
功能模組->細分為各個物件->物件於物件之間的介面定義->具體到每個物件的開發；
根據如上可以很清楚的看到，我們將乙個軟體開發過程化分成了很多個原子(object,物件)，既然可以劃會出各個物件程式設計，那麼模板也便應時而生，模板更新是一些物件集合，對於本程式中來說，它僅僅是乙個多功能物件或多功能模組的載體，然而，模板的應用並非僅此，既然做為模板，它就可以為多個應用程式所共享，而從所周知，每個開發工具，或每種oop語言都支援元件形式的重複利用，那麼我們當建立了乙個完整的模板之後，就可以進行模板註冊！繼而進行多個軟體的共享，如此便實現了**的重新利用，而且，它的優點也不僅僅如此，模板，是乙個靈活的小型元件，使用者(程式設計師)可以根據自己的需求，定製模板的功能、擴充套件模板的介面，使模板的oo思想完全的體現到每乙個軟體之中！那麼如何來制定乙個模板？這就是我們大家都需要知道的，也許，您已經在您的程式中經常的用到模板，或是已經將模板的概念引入到您的程式中，但是您還尚末進行模板的進一步優化，讓我們一起來分析這個過程；模板給我們的程式帶來的好處就是：靈活、**重複利用、業務規則的明確、商業規則的清晰化……從它給我們帶來的效率的方面就可以清楚的了解乙個模板甚至就是乙個object!或是乙個component!既然程式**現了很多的**重複的地方，當我們還沒有能力將設計模式晤的很透或是還沒有把握將**重構、業務邏輯、商業規則等充分的進行偽**的劃分或是模型式的機制還尚末成熟的情況下，很難做到**的再生應用，但是至少我們已經可以感覺的到，**有很多重複的地方讓我們厭倦，甚至在乙個軟體中、或是乙個單元體中就有很多重複的**，可我們又不能借用data option public unit 來進行統一歸劃時(我並不提倡用data option public unit進行重複**的集中處理)，我們其實完全可以做到將經常性的、容易發生的重複**進行整理，至少在頭腦中有乙個清晰的概念！特別是資料庫繁雜的操作；然而，回過頭看一看我們曾經寫的**，不但凌亂不堪，沒有什麼邏輯可尋，也許還會發現程式中，到處可見的copy –paster的痕跡，那麼我們是否應該安靜下來整理一下這些凌亂的**？理順各個邏輯上的規則呢？勢在必行！否則將會產生新的「軟體危機」；當我們整理清楚了我們那些凌亂的**，理順了各個邏輯規則，並進行了**重構，還應該做些什麼呢？是否就到此為止呢？答案是否定的。因為我們不可能只做乙個工程，而如何將我們這次辛勤的勞動收穫帶給下乙個軟體中呢？毫無疑問就是將我們此次整理的結果「放」進乙個「物件」中，用這個「物件」來處理本軟體中將相似的規則、問題，以及將這個「物件」擴充套件到下乙個軟體之中！而這個物件就是我們所說的模板；它不僅僅是一些**的集合；它是給我們提供了很多輸入、輸出介面的物件（black box，黑匣子）；此處想說的是，如果乙個程式設計師還末曾理解oop的話，他是無法構造出這樣的乙個「物件」的。因為模板就是乙個」物件」；不曾理解oo，如何理解模板？又何談構造模板？
我們已經知道了，模板是乙個什麼東西，那麼我們再來看一下它將會包含或是應該包含什麼東西在裡邊？我們都知道，物件就是乙個封裝了各種業務、邏輯規則於一體的實現體，而且，它應該為我們提供一些介面，我們只有通過這些介面來改變這個物件的狀態，否則，這個物件將是乙個「死」的物件，對我們沒有多大的意義；由此可見，這個「物件」是乙個活的實體；並且是乙個很抽象的東西，因為脫離了本軟體，它只是乙個概念意義上的元件；作為乙個規則載體，它就不僅僅是一public個code unit!它並不僅僅是乙個public code unit，否則我們完全可以由乙個puplic unit來完成我們的操作，而不必再去費心的構造乙個物件！雖然，它只能稱為乙個概念意義上的元件，它將無法為我們實現跨平台、語言的操作；可它既然存在，就要為我們實現某種範疇內的統一，在構造模板的同時，我們不能為有這麼乙個概念而去構造；而應該想到，它將可以應用在別的地方！這就是它存在的意義，所以，這個「物件」將還要包含一些靈活的規則再其間，如何做到靈活的規則實現？很明確，就是為我們提供介面！然而，也同軟體一樣，太多凌亂的**、過程、事件將使軟體維護的費用大大增加，介面也同樣，我們不能憑空的任意增加或修改；既然是介面，一當確定下來，就不要再想著輕易的改變它！(此處和敏捷方法沒有任何衝突)；所以，此處的忠告就是：仔細的整理的**，理順所要實現的邏輯規則，用技能、經驗去構造的模板；
當然，模板也並非是一成不變的，根據快速元形法或是級端開發方法的形式，我們的模板也有可能將會是乙個時刻處於變化的「物件」，但是我們改變它也是有規則的，並非是任以的去改，而是如乙個object tree的形式去改變它；模板應該包括什麼東西，想必說的已經很清楚了，但是，它做為了乙個規則載體，就必須要考慮到效能、效率、以及可維護性、可擴充套件性等，此處希望可以提醒一部分朋友那種：「以為低成本的硬體可以帶起整個系統效能的提高」！我們能處理的問題就不要懶惰；如果達到這種目標？提出兩個方面：實現**的合理重構和測試先行！而關於具體的**重構以及測式先行的方法可以參考很多現存的資料；我們前邊已經提到，乙個模板可以是乙個概念意義上的「元件」，所以，模板記著註冊；此篇文章主要是想著將模板引入到你的軟體開發的過程中，不，是每乙個軟體開發過程中；
模板，軟體開發中的應用
模板，軟體開發中的應用 自六十年代中期到七十年代人們感覺到 軟體危機 以來，軟體工程也已經經理了整整35個年頭了 然而，手工作仿式的軟體開發形式在這兒依舊那麼嚴重，而更讓不解的是，每個人工作已經相當一段時間了，竟然沒有去嘗試著尋求新的解決方法 已經被別人用過很多次的方法 結合於實際情況談一談自己幾年...
設計模式 在軟體開發中的應用
論設計模式在軟體開發中的應用 在解決這個論題之前，我們首先要了解設計模式的概念，及其基本的分類。設計模式 這四個字，相信大家在很多地方都會看到，什麼是設計模式呢?乙個設計模式提供一種提煉子系統或軟體系統中的元件的，或者它們之間的關係的綱要設計。設計模式描述普遍存在的在相互通訊的元件中重複出現的結構，...
MBTI在軟體開發團隊中的應用
人絕不是一種資源。一方面我們不可能因人設崗，另一方面也不能忽略人性的差異。面對問題時，不要總是單純地從人的態度或品德上查詢問題，而是要反思人事安排和流程建設上的不足。奢望乙個人改掉他的缺點，還不足充分發揮他的優點。mbti將人區分為16類人格特質，我無法斷言是否真得能表達出人的真實一面，畢竟只是統計...