其他

昨天遇到一段棘手的程式，嘗試了各種方法，忽而在SubmitChanges的時候沒反應（無錯誤，也不更新），忽而發生ChangeConflict，經過幾個小時，終於大致理清了思路，也順便把DataContext/UpdateModel/SubmitChanges給搞得更明白了一些，特此分享。 先大致看看代碼： xxController{        AgileRepository _repAgile = new AgileRepository();

本文是“松結對程式設計”系列的第十篇。（松結對程式設計欄目目錄）主題：如何用更少的代碼寫相同的功能，怎樣的團隊結構可以推進這一點。如果你也希望只用國際先進水平的1/4代碼量，就實現相同的功能，歡迎閱讀本文。本文會多次切換技術和管理兩個平行線，所以結構會複雜一些。前言一直對代碼有效性比較感興趣，所以今天早上重新排布了功能樹後，仔細計數了功能點和程式碼，大致如下：代碼9883行，來自VS的統計資料（只計算CS檔案），加上cshtml中的1420個分號計數（此方法低於VS的統計方法約10%），大約是1

文章目錄 “川”型代碼結構的品質“三”型代碼結構中的品質L型代碼結構的誕生L型代碼結構的管理L型代碼結構的品質L型代碼結構的工作效率L型代碼存在的品質問題 本文是“松結對程式設計”系列的第十二篇。（松結對程式設計欄目目錄）有沒有一種管理方法，無需額外的測試活動，就能大幅度提高產品品質？L型代碼結構就是其中一種候選方案。缺陷的來源要減少缺陷，就要先弄清楚到底缺陷是從哪裡來的？就我自己的經驗而言，大概20%的新手，製造了系統中50%以上的缺陷；

這是敏捷Team

本文是“松結對程式設計”系列的第十三篇。（松結對程式設計欄目目錄）松結對程式設計包括L型代碼結構的一個很大的問題，是在於由於人們複用了太多的代碼，以至於所有代碼牽一髮而動全身。這很容易導致一個底層庫改動後，很多地方編譯不通過，或編譯通過但運行不通過。本人曾經擔任過底層庫的編寫者，在修改和維護底層庫的過程中遇到了很多問題，也發現了一些訣竅，下面是一些編碼層級的處理訣竅。這些訣竅其實都寫在教科書上，學習和使用起來也很簡單，只是到用的時候，被很多人忽略了。1.

本文是“松結對程式設計”系列的第十五篇。（松結對程式設計欄目目錄）之前的L型代碼結構的前三篇提到過，L型代碼結構的微觀計劃和估算過程會與一般的編程方法不同，今天正好要編寫一些新代碼，邊寫邊記錄整個過程。如果中間卡殼了，我也會盡量記錄下來。業務需求這是《火星人》中的一個功能，以往使用者故事是使用故事樹來展示的（就是有父子關係的使用者故事），故事樹隸屬於一個產品Product。但是最近要發版了，感覺一個以前認為暫時用不上的功能，現在變得很急迫，那就是在當前這個版別Edition（比如“線上版”）的目

作者：陳勇出處：blog.csdn.net/cheny_com 迭代期間無變更？支援派說：對，如果經常變，我們怎麼開發啊。反對派說：不對，敏捷開發不能上來就確認了需求，要的就是在開發中逐步瞭解需求，怎麼可能不變呢。只在開發層面，這個問題無解。讓我們站在研發心理學的高度來看這個問題。 先看看如果變更了，團隊會有哪些不利的心理變化。1. 咱們不要在開始承諾能完成，一旦變化承諾就落空了2. 既然總是在變，每次我們都預留點估算餘地吧3. 別著急，你忙也完不成的，到最後一天還給你變4.

這是敏捷開發使用者故事系列的第四篇。（欄目目錄）優先順序排序聽起來是一個很簡單的工作，一個欄位無外乎“重要/一般……”，調整一下然後按排序，就出來了。但其實裡邊有不少名堂：誰應該負責排序工作？誰最終拍板？研發因素要不要考慮？需求依賴關係導致的順序如何處理？持續傳遞的考慮？商業決策的考慮？以下知識與經驗，來自於多個來源，主要是部分網上資料、實際項目的訪談，並在自己現在正在做的一個項目中得到驗證。具體應用時，應靈活掌握。誰負責排序？Product

這是敏捷開發使用者故事系列的第三篇。（欄目目錄） 使用者建模的目的，是為了更好地分析使用者行為和使用者價值，並因此獲得商機。使用者建模四部曲有一次培訓中，分組建模的時候，一位學員就自言自語地說了一句話：“真的啊……我好像不知道誰會使用我的產品……”這其實是一種常見的現象。比如前文所說的敏捷開發管理軟體，如果想把一個使用者故事描述為“作為一個使用者，可以登入“我的空間”，以查看我我在的所有項目的進展以及自己的任務”，就會遇到這個麻煩。所謂領導，肯定想淺層次低能看到多少項目，就看到多少項目，而且最好

文章目錄 介系嘛故戲分類目的 （序言，之一，之二，之三，之四，之五） 介系嘛故戲         使用者故事嘛誰還不知道，如果大家仔細看我們第一個月的，就能看到所有故事的描述都被預先置為模板“作為……，可以……，以便……”，就等著填入實際內容了，可是沒想到，怪物來了。請看介幾個都系嘛故戲：1. 如果把“儲存按鈕”統一放在頁面上端而非下面，有些螢幕上側控制項的修改，就無需滾屏即可儲存。2.

這是敏捷開發使用者故事系列的第二篇。（欄目目錄）敏捷開發中的使用者故事採用的文法模式看似簡單，卻蘊含著深刻的思想。“作為一個……，可以……，以（以便）……”不同於一般專註於功能的需求條目描述方法，三個……把角色、功能、價值躍然紙上。然而使用不當，卻有可能形似而神不似。下面就三個部分分別舉出一個例子。網路遊戲的熱門排行榜功能“作為一個玩家，可以通過顯示排名，以便讓自己在伺服器中的地位獲得認可。”這個功能可以激發玩家的“鬥志”，鼓勵購買道具，是個不錯的想法，但實現起來卻有技術問題：伺服器中的玩家太多

文章目錄 故事表？故事樹！ （序言，之一，之二，之三，之四，之五） Product Backlog到底長什麼樣子？最開始看到Backlog這個詞，看成Back bag（“背包”），感覺挺形象的，有一包東西挺沉的背著，看大家也畫成一摞大磚頭的樣子，自己就照著畫。比如下邊這個，就是我在PPT裡邊用的最多的。不過這堆磚頭到了現實世界，到底什麼樣子？尤其是Product

本文是“松結對程式設計”系列的第十六篇。（松結對程式設計欄目目錄）今天正好要複用一段架構（asp.net MVC3，服用範圍包括Controller和View），把過程記錄一下。與複用一般的過程相比，L型代碼結構有這麼幾個特點：1. 如果複用有難度，在複用之前，一般不刻意形成“可複用代碼”。順便就能寫成函數的例外。2.

這是敏捷開發使用者故事系列的第一篇。（欄目目錄）全系列將涉及何為使用者故事，面向客戶價值編寫故事，使用者建模，產品待開發項的分類，故事顆粒度，故事的組織圖，等等若干問題，力求將此中問題盡量解決乾淨。本系列文章假設正在編寫一個“敏捷開發管理軟體”，因為來閱讀的都是做敏捷開發的，又都是做軟體的，會更熟悉一些。使用者故事三要素：角色，功能，價值按“作為一個……，可以……，以便……”樣式和思路寫成的使用者需求，就是使用者故事。樣式是技法層面的東西，它保證了無需太多思考，使用者故事中即包含角色、功能、價值

剛開始的時候非常認同asp.net中MVC的Action的布局方法：無論大小，只要是一個動詞，都給一個單獨的頁面，比如Create/Edit/Detail/Index。編寫了一段時間後，又發現這樣很不方便，尤其是像“建立角色”這樣的頁面，就一個TextBox,其他什麼都沒了，單獨編寫一個Create一個Edit，不如在Index頁面上方放一個TextBox，底下已經存在的角色也直接用TextBox而不是文本，這樣想建立就建立，想編輯就編輯。又編寫了一段時間，又發現這樣有風險。因為在另外一個頁面上

（序言，之一，之二，之三，之四，之五） 本文是《火星人》系列的子系列，將分期向大家分享火星人敏捷開發管理工具的開發和管理實踐。一直以來，敏捷開發長期受困於各種名詞、術語的堆疊、羅列、解釋，而較少出現原創和實踐分享過程。而敏捷實際上本來只把自己作為一個起點，需要大家的豐富和擴充。這可能與中國的軟體業發展長期落後於國際所致，以及在PMP、CMMI推廣中所養成的重標準、輕實踐的的情況有關。本子系列會與大家分享我們自己的開發和管理實踐，它們可能不完美，也不是終極實踐（因為我們未來會做地更好），但卻是在時

麥思博正在策劃一個年底的最佳實務分享活動，作為會議形式的提出者我也參與了一些策劃，下面是現在官方的公開召集公告。強調一下裡邊要注意的內容：1. 必須是言之有物的有效分享才能通過評審，拒絕廣告和空談2. 寧肯分享一個可借鑒的點，不要分享多個空洞的面3. 只有50分鐘演講時間，大約15頁PPT足夠了4.

這是敏捷開發一千零一問系列的第二十五篇。（在這裡提問，之一，之二，之三，問題總目錄）問題：什麼是敏捷開發的根本基礎？What is the essence of Agile Software Development??來自LinkedIn熱帖http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&discussionID=156452723&gid=37631&commentID=93678048&

（序言，之一，之二，之三，之四，之五） 第一個月：一個產品的誕生 沒有國王，沒有宰相，沒有能講故事的王后，也沒有需求文檔，開發就這樣開始了：為何不先寫需求文檔？因為敏捷開發不寫文檔！不是的。策劃這個產品的時候，有一個大願：就是用這個產品管理這個產品自己的研發。雖然這不等於沒有“長得像”Word的文檔的需求，但是我們仍然想盡量只用產品本身的功能來寫需求。所在在項目開始的那天，我們手裡（確切說是腦海裡）只有一個商業計劃，外加這個產品的大致功能列表。那怎麼知道要開發什麼功能？        

作者：陳勇出處：blog.csdn.net/cheny_com 本文已經成為職場人生系列之七。 本人總共出國只有7天，也沒怎麼在地道外企用外語好好工作一下，所以沒海歸們學得地道。不過經不住常年修鍊，積累下來也幹過N次大小會議培訓翻譯，從30分鐘的到3天的都有，還有兩天趕鴨子上架的同傳。下面簡單分享一下經驗：如何利用極其有限的時間和條件學好外語。 立志篇 1. 千萬別拿太難的材料上手，書蟲系列圖書，《流行美語MP3》（絕對傻瓜）都很好。2.