Silver bullet
軟體開發的适應性和易變性使得開發過程變得異常複雜。面對不停的需求變化，開發人員必須根據需求來更改工程，有時這樣的更改會花費很高的代價。不可見性也是軟體工程的一個特性。機械零件的制造或是建築物的設計可以通過設計圖來較直覺地展現設計過程中的不足，使得改進方向較為明确，但軟體開發不同，工程與代碼的抽象性使得不能用直覺的方式找出錯誤或不足産生的地方，往往修複一個小bug都會耗去大量時間和人力。
軟體開發的過程遠沒有想象中的那麼簡單，各種意想不到的問題都會發生，需求的變更，錯誤的出現等等都會使開發過程變得艱難。雖然沒有一種可以本質上解決軟體開發的複雜性，我們人就可以通過前人總結的各種方法和工具使開發過程變得盡量高效。
大泥球
大泥球，是指雜亂無章、錯綜複雜、邋遢不堪、随意拼貼的大堆代碼。這些年來，為了對付這個泥球，我們看到了多種指導方法，與其他諸多年代久遠的、提倡高内聚、低耦合的方法一起出現。然而，實際情形沒多大變化，“大泥球”看起來仍然是設計軟體架構的最常見方法。大泥球發生的主要原因可以歸結為：一次性代碼，碎片式增長，為了讓軟體不出問題。
我們小組的工程是在前人工作的基礎上進行更改與擴充，在一開始閱讀他們的代碼時，我們就發現了類似大泥球的代碼，許多代碼重複備援。是以在改版的開發中，我們删去了所有雜亂的代碼，幾乎是進行了重寫。并且進行重新編寫時，注重擴充性和可重用性，盡量避免大泥球的出現。
CatB
世界上的建築可以分兩種：一種是集市，天天開放在那裡，從無到有，從小到大；還有一種是大教堂，幾代人嘔心瀝血，幾十年才能建成，投入使用。當你建立一座建築時，你可以采用集市的模式，也可以采用大教堂的模式。一般來說，集市的特點是開放式建設、成本低、周期短、品質平庸；大教堂的特點是封閉式建設、成本高、周期長、品質優異。
我們組的項目屬于教堂式，雖然開發周期不算長，但是開發過程沒有開放，對于軟體設計本身考慮了高擴充性，算法也經過仔細推敲，開發的成本不算低。
現在市面上軟體的數量在上升，軟體的品質卻在下降；對于軟體包的依賴性在增多但軟體的複用性在降低。開源雖然創造了史無前例的全民程式設計熱潮，但也導緻了無責任、非專業、淩亂的軟體開發。在浪潮退去後，傳統的緊密聯系的團隊開發，依然是現在軟體開發模式的主流。
Worse is better
Rechard P.Gabriel 于1989年最早提出“越差就越好”（worse is better or WIB），後來發展為一種軟體設計風格或理念。Gabriel的文章“the Rise of worse is better”中強調軟體的簡潔和界面。這同MIT approach(or the right thing)的作法形成鮮明對比，後者強調事前完美的設計。由于WIB可快速推出軟體應用，并持續完善，故而易于推廣。其觀點幾乎可以用另外一句話來概括：“Simple is Best”，
于我而言，我是支援這種觀點的，因為市場是最好的評判者，一款産品是否能去的消費者的信任并占領市場，是對其“好壞”最直接，最有效的判斷。簡而言之：成王敗寇，成功了就是好東西，不成功了就是壞東西。
瀑布模型
瀑布模型總的思想：将軟體生存周期的各項活動規定為按固定順序而連接配接的若幹階段工作，形如瀑布流水，最終得到軟體産品。它的核心思想是按固定的順序将問題化簡，将功能的實作與設計分開，便于分工協作，即用結構化的分析與設計方法将邏輯實作與實體實作分開。将軟體生命周期劃分為制定計劃、需求分析、軟體設計、程式編寫、軟體測試和運作維護等六個基本活動，并且規定了它們自上而下、互相銜接的固定次序，如同瀑布流水，逐級下落。
瀑布模型的最大特點是将開發過程分成了一個個明确的階段。為項目提供的按階段劃分的檢查點，分成不同的階段後可以使項目分成各個不同的小組，或是劃分成不同的開發階段。但是這個模型也存在着一些缺點，比如不适應使用者需求的變化等等。
Agile Method
靈活開發是針對傳統的瀑布開發模式的弊端而産生的一種新的開發模式，目标是提高開發效率和響應能力。除了原則和實踐，模式也是很重要的，多研究模式及其應用可以使你更深層次的了解靈活開發。靈活模組化的價值觀包括了五個價值觀：溝通、簡單、回報、勇氣、謙遜。
在我們小組的開發過程中，還是比較注重溝通的，代碼編寫中遇到什麼困難，都傾向與互相讨論，積極回報。
對于簡單的原則，考慮到時間的有限我們也避免過多的設計不必要或者次要的功能，盡量使系統簡單明了，保持功能的基礎上便于開發。