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