軟件工程
關于軟件工程理論、實踐、感想
摘要: 在我現在的項目中出現了這么兩個問題，大家可以來探討下這樣的兩個問題的解決方法，:)
1、從開發環境到正式環境的部署/校驗非常麻煩；
2、數據庫的頻繁移植/校驗非常麻煩。
我的解決方法：
對于上面兩個問題，我自己想到的解決方法是：
1、建立持續集成機制，編寫環境部署腳本和文檔，采用這兩種方法可保證從開發環境到正式環境的部署是非常簡單的；
編寫自動驗收測試腳本，可以基于Selenium進行編寫，這樣每次在升級版本的時候就不需要再人工的進行回歸測試了，這里面的問題是如何在測試完畢完畢后清除這些測試數據，因為這些測試數據是不能和正式數據共存的。
2、建立數據庫升級移植機制，每次升級時做增量的升級，不過這需要建立在對原庫建立版本記錄，這個方法對于我們的項目而言不太可行；
第二種方案就只能每次進行全面的重新移植了，但這個帶來的一個巨大問題就是存儲過程的重復修改，目前我還沒想到什么解決方法，而且；
至于如何校驗數據庫移植是否成功，我覺得可以建立數據庫移植校驗的Checkpoint，除了保證數據庫結構、數據量等的
閱讀全文
摘要: 最近用了下在php業界中非常出名的wordpress和mambo，使用下來的感覺就是這兩個東西易用性真的太好了，功能方面同樣非常的強大，實在想不出java界的CMS哪個能和它們進行對比的，引發自己的一些思考，java界的技術人員特別容易以技術觀點去評價一個東西的好壞，覺得這就是為什么java界的論壇、CMS這種東西總是無法和其他語言體系的相比的原因，并不是說java界就真的做不出象mambo這樣易用的CMS。
閱讀全文
摘要: 之前公司招高程，估計面試了不下30個人，覺得面試別人其實也是一種樂趣，和各種不同的人聊天會讓自己也學到很多，而且由于還是面試階段，會更容易進行沒有隔閡的技術交流，每次面試其實我都覺得是一次很好的技術交流機會，所以我很樂意面試，同時我也希望被我面試的人能夠享受著這種感覺.....
閱讀全文
摘要: 以前的自己一直認為做技術化性質的框架、產品是自己的職業發展之路，逐漸的慢慢而改變，發現以前的自己很陷入技術，不斷的追求技術，而忽略了軟件的本質，軟件的本質是為了提高在某種工作上的效率，其實就是讓業務能夠更高效的完成，而要做到這一點，依賴的重點并不是技術，而是對業務的理解以及將業務轉化為電腦化操作的能力，而這點是非技術能解決的，在業界可以看到很多公司，象浪潮，它在煙草行業的成功讓人嘆服，從技術人員的角度去看它的系統可能會覺得不過爾爾，技術人員往往會認為自己要做出一套這樣的系統來不過是小菜而已，但事實是如果讓你現在進入煙草行業，也許你做出來的系統從技術上是超越了浪潮，但從業務的理解上以及轉化為電腦化操作的能力上能超越浪潮嗎？這個不是一兩年的業務積累就夠的，^_^，從現在國內的軟件業界的情況來看，我覺得大部分技術人員的最佳發展方式還是深入理解業務，這才是自己的優勢，同時掌握將業務轉化為技術的能力，這樣的技術人員必將是強勢的，這樣做出來的東西才是有足夠的競爭力的，軟件是面向服務的，^_^，不要忘記了這一本質。
技術只是一種輔助而已，切勿反客為主.......
閱讀全文
摘要: 每個團隊都有它更為適合的軟件工程，因此不可一概而論，談談自己對于XP以及重型軟件工程象CMM這種更為適合的團隊。
閱讀全文
摘要: 想改良一個爛設計為好設計嗎？想增加或維護代碼功能時更加簡單嗎？重構無疑是其中最好的方法之一，既然它是好的，我們就要把它發揮到極限，把重構發揮到極限的方法就像kent beck說的，采用兩頂帽子的原則，工作中不斷的交換帽子，^_^
閱讀全文
摘要: 既然測試是好的，那就把它發揮到極限。
測試是好的，這一點無可厚非，幾乎做軟件的人都是認可的，本篇只是談談測試中的單元測試部分，單元測試的目的是為了保證類中的方法是符合設計時的需求的，需求驅動似的類實現，^_^
閱讀全文
摘要: 既然認為它是好的，就要發揮到極限，這是XP的思想。
持續集成無疑是一種非常好的方法，那么在實際的軟件開發過程中就應該把它的好發揮到極限，但就我自己經歷過的項目以來，只在一個項目中真正的較好的實現了持續集成，不知道大家的情況是怎么樣？持續集成的最出名的代表還是MS的Daily Build和冒煙測試了。
閱讀全文
摘要: 如何保證軟件的質量一直就是令人頭疼的事，這里列了一個自己實際運作的一套用于保證軟件質量的方法，還望大家多加指點。
閱讀全文
摘要: 昨晚看切爾西的比賽的時候突然聯想到了軟件開發，呵呵，來看足球賽：
1、根據比賽雙方的實力、主客場、天氣等等各方面因素來比賽雙方都會制定自己的目標，戰平、勝或別的目標。
2、需要在有限的時間內(90分鐘)達成目標。
3、多種角色構成。(守門員、后衛、中場、前鋒)
4、一定的陣型(4-3-3、4-4-2)和戰術(防守反擊、短傳滲透、長傳沖吊)。
5、多變的形式以及多種不定因素(裁判、球員狀態等)。
閱讀全文
摘要: 項目的第一迭代結束，在此對整個過程中Team的表現做的一個總結和分析。
閱讀全文
摘要: 在項目中正式的執行XP中的過程，除了PP由于暫時沒實施，其他的都在實施中，雖然這點會被很多xper說，^_^，其實我也知道PP非常好，畢竟以前經歷過，但由于某些原因，在現在的team中我還不好去執行，以后找到機會，呵呵.....
自己接觸XP說起來也有兩年多了，而且在以前的團隊中也是采用這樣的過程，但現在自己帶team真的執行的時候卻發現碰到一些問題，一方面可能是因為自己太久沒溫習XP，^_^，有些過程都不是那么記得了，另一方面是在執行的時候有些步驟確實不好走，在這樣的情況下，回顧了手頭的幾篇XP的文檔，從XP中對于整個軟件過程的推行來看自己實施過程中的問題。
閱讀全文
摘要: 本來作為客戶而言，它需要關心的是自己想基于系統做什么，實現什么樣的功能，而不會關心到技術層面，但如果碰到了關心技術的客戶怎么辦呢，客戶關心到你用的是什么平臺、什么框架、為什么要用以及它如果要基于平臺做自主開發要怎么做，感覺在這種情況下挺棘手的，客戶往往就變成了對于你實現需求的技術進行干預，而很多時候又沒法向用戶解釋清楚，而且在這種情況下往往是客戶根據你的介紹和講解來做出基于這樣的平臺是否能實現他們需求的評估，這就挺難搞了，也許是自己的技術不過關，不過覺得最缺乏的是溝通的方法，大家覺得在這種情況下會有什么比較好的方法呢？求教.......
閱讀全文
摘要: 從公司級來講，自己的資格是遠遠的不夠，在這里主要也是根據自己的項目經驗闡述下自己對中小型企業技術團隊的一種觀點，個人覺得對于中小型企業來講三級團隊的構成是比較理想的，就是支撐平臺團隊+應用系統開發團隊+實施團隊，從三級團隊的構成來講切忌企業的面鋪的太廣，那這三級團隊就很難形成了，但在國內大部分中小型企業仍然處于盈利為上的策略，這也是沒辦法的，畢竟求生才是最重要的，在這種情況下，我覺得在這樣的公司不如干脆由應用系統開發團隊+實施團隊來組成，而支撐平臺則選用開源的或進行采購，當然，選用開源的概念是某個可直接用的或者不需要進行太多集成工作的，這樣在公司發展到一定程度的情況下，在適當的時機下再進行升級到三級團隊的建設。
閱讀全文
Full 軟件工程 Archive