11 2005 檔案
摘要: 在項目中正式的執行XP中的過程，除了PP由于暫時沒實施，其他的都在實施中，雖然這點會被很多xper說，^_^，其實我也知道PP非常好，畢竟以前經歷過，但由于某些原因，在現在的team中我還不好去執行，以后找到機會，呵呵.....
自己接觸XP說起來也有兩年多了，而且在以前的團隊中也是采用這樣的過程，但現在自己帶team真的執行的時候卻發現碰到一些問題，一方面可能是因為自己太久沒溫習XP，^_^，有些過程都不是那么記得了，另一方面是在執行的時候有些步驟確實不好走，在這樣的情況下，回顧了手頭的幾篇XP的文檔，從XP中對于整個軟件過程的推行來看自己實施過程中的問題。
閱讀全文
摘要: 前天那篇blog更多的是講了下數據驅動、模型驅動的大致概念，今天更多的是講數據驅動以及模型驅動在進行系統實現時的方法、過程以及自己的一些思考。
閱讀全文
摘要: 數據驅動、模型驅動作為如今軟件設計中兩種不同的模型驅動方法，應該說各有各的優缺點以及適用的場合，不能就一概的去認為哪種必然就是更好的。
閱讀全文
摘要: 軟件建設需要考慮的重要的兩點我覺得是：
1、客戶的功能需求以及非功能需求。
2、軟件的維護性。
軟件的技術架構就是為了滿足以上重要的兩點而誕生的，同時由于軟件的技術架構決定了使用它的開發人員所需的水平以及開發的難易，此時又要盡量做到降低對使用者素質的要求以及開發的門檻，以保證開發的高效性，但這個相對上兩點來說更沒那么重要。
閱讀全文
摘要: 寫這篇和以前的意思不一樣，這篇主要是對現在的動輒采用aop思想、采用插件架構、采用SOA、大集成技術這些東西的一個個人的看法，象這種思想級別或者架構級別的東西來說，是很多人采用，但真的發揮了它的作用嗎？不敢認同，呵呵，其實象一旦采用aop、插件體系架構這樣的思想或架構級的東西，帶來的是設計時，甚至是分析時的思想轉變，^_^，否則采用了甚至比不采用還慘，不僅帶不來效果反而會受很大的"傷害"，呵呵，所以在要采用思想級別和架構體系級別的技術轉變的時候真的要慎重思考，需要的是對采用的思想以及架構體系的深入了解，畢竟做軟件不是為了技術而技術的，當然，自己小玩玩當然是可以了。
閱讀全文
摘要: Equinox是Eclipse的OSGI RI的Project，它的目標是建立成一個獨立應用的Plugin Framework，因為現在Eclipse的那個是不好做剝離的，翻譯了一篇它的編碼實踐，希望能有些指導。
閱讀全文
摘要: 插件架構體系是我一直就非常關注的內容，其實插件架構體系的發展已經有很久的背景了，插件架構體系的優點我們也是能看的非常明顯，象硬件一樣的即插即用、無論對于公司還是業界而言的良好的積累方式、為公司或業界提供統一而規范的開發方式以及穩定的內核架構等等，這些優點無論對于公司還是業界來說都是非常重要的。
插件架構體系基本的一個概念就是基于松散的模塊積累方式，通過新增插件以及擴展原有插件的方法來完成系統的實現，凡事有利必有弊，在看到插件架構體系的這些優點的同時，在實現和使用插件架構體系的時候仍然會碰到不少的問題，在本文中大概的整理了一些也相應的提出了一些自己的看法。
閱讀全文
摘要: 在和一個朋友交流權限系統方面的實現時，朋友提及到JAAS，我自己對JAAS不是那么了解，不好去評價，后來去網上查閱了不少JAAS的文檔，應該說現在大致的對JAAS有些的理解了吧，個人覺得JAAS只能算是實現權限系統的另一種方式，相當于提供了一個框架，至于這個框架基于什么模型我無從評價，對比下來我仍然認為基于RBAC自行實現是更佳的方案，不過JAAS中也有可取之處，那就是它的PAM思想。
閱讀全文
摘要: 本來作為客戶而言，它需要關心的是自己想基于系統做什么，實現什么樣的功能，而不會關心到技術層面，但如果碰到了關心技術的客戶怎么辦呢，客戶關心到你用的是什么平臺、什么框架、為什么要用以及它如果要基于平臺做自主開發要怎么做，感覺在這種情況下挺棘手的，客戶往往就變成了對于你實現需求的技術進行干預，而很多時候又沒法向用戶解釋清楚，而且在這種情況下往往是客戶根據你的介紹和講解來做出基于這樣的平臺是否能實現他們需求的評估，這就挺難搞了，也許是自己的技術不過關，不過覺得最缺乏的是溝通的方法，大家覺得在這種情況下會有什么比較好的方法呢？求教.......
閱讀全文
摘要: 幾乎在所有的系統中對于權限控制都有直接的需求，而這類需求往往有其相似性，綜合常見的對于權限系統的需求構成了本文檔，文檔主要從功能復用以及模型復用的角度來對權限系統進行總結，以便在各種系統中可對照此篇文檔來進行權限系統的實現，考慮到文檔的關注點在復用度，在文檔中不會過多的去描述功能點到模型產生的過程，而是采用直接通過產生的模型來說明基于此模型如何實現功能點的需求。
閱讀全文
摘要: 從公司級來講，自己的資格是遠遠的不夠，在這里主要也是根據自己的項目經驗闡述下自己對中小型企業技術團隊的一種觀點，個人覺得對于中小型企業來講三級團隊的構成是比較理想的，就是支撐平臺團隊+應用系統開發團隊+實施團隊，從三級團隊的構成來講切忌企業的面鋪的太廣，那這三級團隊就很難形成了，但在國內大部分中小型企業仍然處于盈利為上的策略，這也是沒辦法的，畢竟求生才是最重要的，在這種情況下，我覺得在這樣的公司不如干脆由應用系統開發團隊+實施團隊來組成，而支撐平臺則選用開源的或進行采購，當然，選用開源的概念是某個可直接用的或者不需要進行太多集成工作的，這樣在公司發展到一定程度的情況下，在適當的時機下再進行升級到三級團隊的建設。
閱讀全文
摘要: 大家都知道Eclipse是一個典型的插件系統，而從3.0起其插件體系架構就重構為基于OSGI規范來實現的，從這也可以看出osgi必然與Plugin Architecture是有很多的關聯性的，在這里就來說說自己對Osgi R3與Plugin Architecture的關聯。
閱讀全文
摘要: 本文主要對于軟件過程的整體規范進行較為完整的描述，來源于個人的項目經驗、所在team使用的軟件過程以及個人的一些想法總結而成。
文章按照對項目中采用的軟件過程進行描述，之后對保證整個軟件過程有效執行的工具、制度等進行描述。
本文意并不在標明這個軟件過程是多么的優秀，關鍵是要找到適合自己團隊的軟件過程，沒有最優秀的，只有最合適的。
閱讀全文
摘要: 根據自己的經驗整理一篇軟件過程規范的文章，主要是根據自己的經歷以及目前的情況來完整的描述一個軟件項目過程中規范性的東西。
遵循的一個原則是："規范不是萬能的，要不斷調整，每個Team有每個Team適合的規范。"
這篇是序，明天整理一份完整的文檔，對整個軟件過程中涉及的規范的東西進行較為完整的描述。
閱讀全文