其他

表結構是這樣的CalssId 標識id Sid        上級id (就是上級的標識Id)填充資料後是這樣 CalssId        Sid   1                  0   2                  1   3                  1   4                  2   4                  2   5                  3  

我在做分詞模組時,對每個詞分配hashcode,但是發現其值並非唯一;比如 "公出"和"古色"這兩個詞得到的值都是 6237203.為什麼會出現這樣的問題呢,其實在MSDN裡面有解釋:備忘GetHashCode 的行為取決於它的實現，此實現可能會從一個公用語言運行庫版本更改為另一個版本。原因可能是為了提高 GetHashCode 的效能。如果要求 GetHashCode 的行為不變，請使用您自己的、確定不會改變的實現來重寫 GetHashCode

Normal07.8

做了2次程式碼檢閱，Java和.Net都做了大約3個小時。最大的收穫就是將調度方法與原子操作方法區分開。 調度方法一般就是根據不同情況，調用別的方法來實現某個功能的方法。調度方法體現的是流程。原子操作方法，一般就是功能單一，只完成一個簡易功能的方法，他將被調度方法調度。原子方法體現的就是原子操作。 這兩個方法的有效區分是提高代碼品質的重要手段。當我們開始重視代碼品質的時候，定義了很多規則，如：變數命名，常量定義等等。這些規則應該是開發人員必須遵守的最基本的要求，這些規則是可以通過某些輔助檢查工具

我不多寫了。。網上現有的代碼演算法有問題。把代碼放上來，需要的同志可以參考。Code highlighting produced by Actipro CodeHighlighter (freeware)http://www.CodeHighlighter.com/--> IFeatureClass featureClass =GetLayerByName("網路攝影機").FeatureClass;                    IFeature featureForDraw;    

作者一開始講解了為什麼要建模，接下來講述了四種關鍵的結構化分析的模型工具，這四種工具就是我們所熟知的DFD（Dataflow Diagram)、ERD(Entity Relationship Diagram)、STD（State Transition Diagram）、SC(Structure Chart)    下面是簡單的說明1. DFD(Dataflow Diagram)       

Mordern

     很久沒有買書了，今天去china-pub看了看，發現China-pub現在的設計真是挺爛的，一點都不方便客戶。     就說新書一覽那個吧，純粹就是一個按時間排序或者點擊量排序的東東，一大堆數堆在那裡，眼睛看花也沒找到自己想要的。     至少也應該將專業書籍和使用書籍分開吧。不知道他們怎麼想的。    再看看電腦書籍的首頁，一點業務思想都沒有，就那麼放幾本書，搞得我點來點去。儘管那個搜尋有點意思，其他就太爛了。   

什麼是團隊精神，世界盃給了我們很多的啟示。目標，團隊首先有一個明確的目標。世界盃上32支隊伍各有不同，如果都奔冠軍而去其中的30支隊伍都會受到羞辱，因此每個球隊都有自己的目標。德國隊進入八強，巴西隊想再次折桂，一個達到目標，一個黯然離去。目標對一個團隊來說非常重要，項目組的目標就是項目按時、按質、按量、按成本的完成。根據項目的不同目標也有所變化，有的是按時為主，有的是按質為主，各有不同，當然就各有差異。 職責，11人的隊伍，各司其職，教練組也要各司其職。後衛和前鋒之間的要求職責不同，要求也就不同

列表性資料處理時，ID等隱藏列的位置    每到項目維護階段，很多人就不得不為這些隱藏列原來的位置頭疼，最近考察的幾個項目中，隱藏列一般都放在顯示列的後面，在處理單擊、雙擊或其他要擷取這些列的位置的時候，如果修改了顯示列的列數，增加或者減少了這些列，就不得不尋找那些使用隱藏列的地方，去修改相應的代碼，為此我強烈建議大家：將隱藏列放在表格的前面，ID都放在第0列，這樣既可以統一處理擷取ID的地方，又不會影響將來修改列數的時候的代碼

強烈建議公司進行單元測試，執行每日構建，以提高品質，降低成本。由於項目的特殊性，我們的項目需要於WebService進行掛接，並且這個部分是項目的核心部分之一，我們在此基礎上進行2次單元測試，以保證原始程式（J2EE環境）和調用環境（.Net 2.0）都是可用的。使用的工具：TestDriven.Net

     最近組織對一個系統進行分析設計工作，在初期檢查過程中，發現我們的分析師（設計師）按照自己的經驗（或者別的項目培訓的結果），根據不同的過程，進行分析設計，5個人5個做法，差異非常得大。覺得有必要對他們進行一次培訓，論題就是以用例為核心得OOAD，要求：大家做事的過程基本一致、做事的方法基本一致、做得的結果也要基本一致。基本思路就是圍繞用例，對每一個用例、每一個用例的說描述的功能都要被實現。       大致開發過程是：       前提：體繫結構概念已經建立、需求已經得到開發      

     新項目又要立項了,忽然又想起這句話。     這個項目是三年前就開始了，3年前開始使用，一直又維護，但就是達不到自己的理想要求。有一年，突然就有了這個感觸，當初做這個項目的時候，只是為了滿足一點管理的需要，根本上沒有什麼遠大的理想。做做停停，花費的成本足夠仔細的設計一個偉大軟體的1.0版，可是我們竟然沒有留下太多的東西。（當然也培養了一批人。這批人後來成為一個很重要項目的骨幹力量。）      當一切回到起點的時候，這個思想又重新回到我的腦袋裡面，自己也覺得受到震動。     

1.流量分析設計工具，任何時候都要使自己的分析設計模型與代碼模型保持一致。2.領域驅動3.利用分析設計工具自動產生部分代碼，盡量自動組建組態和有關屬性。4.在基類中就封裝好：Save、Delete、Load（好像NHibernate不能在基類中分裝Load，必須每個類寫一個靜態方法）等方法。對於父子關係、多對多關係、一對一關聯性等，都需要使用Transaction來處理，重載有關的Save、Delete方法。

每個人每天要做很多事情，有的人很累，有的人很輕鬆；有的人做的好點，有的人稍微遜色點。當然沒有絕對做的好的人和絕對做的壞的人。那麼我們如何能夠做的再好一點呢？      今天看柳宗元的《梓人傳》這編文章，心裡有很多感想。他說這個木匠師傅，已經脫離了具體的刀斧之類的技術，而使用自己的尺、丈、墨等工具，精心構建精美的房舍。      其之於使用具體的刀斧的師傅，他自己的床腳壞了，卻不會修，需要請具體刀斧的師傅來修。而他修房舍的薪水較之他們卻有3－5倍的差別，其之於一個大工程，他自己的薪水將超過一半。 

         做了這麼多年的軟體，我最愁的就是介面。什麼樣的介面是客戶所需要的，是客戶能夠滿意的？這個問題太難，太不好回答。       業務都調查好了，各方面都做好了，一到介面就懵了。業界介面設計的好的設計師真是鳳毛麟角，我所遇到的UI設計師，都和一樣，一說到這個問題就發愁。      如果UI做不好，你所做的一切努力都是白費勁。      今天突然來點靈感，趕快記下來。      

    周五，臨下班。電話響：    對方：“喂，老蔡，我在錦州出差！我明天去大連玩。”（心理疑惑，這老哥誰啊，一口廣東普通話）。    我：  “請問你是？”    對方：“我是深圳的，你想想.”(深圳的？我深圳的朋友都講粵語，講普通話還真聽不出來）    我： “不好意思，我還是不知道你是誰，你是誰？”（耐心中）    對方：“連我都忘記了，真不夠意思啊，我姓陳啊”（不知道，姓陳的深圳的，好幾個，不耐煩,也心理覺得有點愧疚，咋就忘了這老哥是誰呢）    我：

       我們經常需要校正資料是否存在，格式是否正確，如果每個函數都處理這些，導致函數中大量的代碼用於校正資料，那麼應該遵循下列規則，做到既滿足系統需要，又不會導致大量的校正代碼：1.集中進行資料校正，如：使用者輸入的資料，資料庫中查詢出來的資料等等，如果能夠做到集中校正資料，那麼將能夠省心、省力。做不到的話，那就請遵循第2條。2.在使用的地方校正，什麼地方使用什麼資料，就需要進行校正，特別是那些判斷對象是否存在或者其他的。3.校正些什麼資料：    基本規則，校正那些自己控制不了的資料  

本部分需要進一步完善1.      詳細設計流程在詳細設計前需要確認用例文檔是否是最終的文檔。保證概念的準確性的前提下，以介面為中心。  1.      介面：1)       從介面出發完成介面的功能，每一個事件都要說明，每一個動作均有事件對應2)       文檔畫面1.畫面LoadPage_load Button_click222212事件3 …… 2.Button_Click3.其他