其他

[譯者注]前不久翻譯了Eric Raymond對幾大開發語言的評價，引起了網友的熱烈討論。其中涉及到Eric Raymond對OO的批評，引起大家的爭議。為此我再翻譯他的一段相關文字，請大家閱讀思考。 模組化 —— Keep it clean, keep it simple    

近來在俠少（@永恒的俠少）的微博上看到一件弔詭的事情。《WCF技術內幕》的譯者指斥《WCF全面解析》的作者抄襲，而指斥的理由是：還有一個原因我要告訴你，為什麼是抄襲。因為《Inside WCF》是世界上第一本從內部機制剖析WCF架構的書！為什麼這本書只有Justin Smith可以寫出來，因為他是微軟美國WCF團隊的技術經理！他才是真正瞭解架構的人。2007年就寫出來了。。。國內有人寫出這種書，根本不可能！大量照搬原書小節這件事情之所以弔詭在於：當你有證據的時候，指斥別人抄襲無疑是非常值得稱讚的

近來看了2篇和讀書有關的文章，一篇提到Joel講現在程式員不太讀書了，主要靠在網上找各種參考資料；一篇則是馬總說的：成功與情商有關 與讀書多少關係不大。一定程度上這兩個觀點都有點道理，可以靠StackOverflow.com和搜尋引擎找到各種問題的答案和例子，劉邦項羽不太讀書一樣鬧革命，還成功了，但如果得出一個“讀書無用”的結論來就錯了。人類擷取知識的手段無非就兩個要麼靠實踐直接擷取，要麼間接擷取，而間接擷取中最關鍵的手段則是讀書。“實踐無疑是最有效提升自己的手段，但只依賴於實踐無疑也是愚蠢的。

如果以Turbo C為起點回看這10幾年的IT世界，就會發現每當新技術（C++,Java,OO,泛型,RAD,組件...）出來的時候，通常它會被認為是通解，而後在應用過程中才會逐漸發現它的限度。在這樣一種過程中，我個人就逐漸形成了這樣一種認知：對新技術而言，只有在不只知道它適合做什麼，也知道它不適合做什麼的時候，才算是真的掌握了它。在此之後才可能人駕馭技術，否則很容易出現技術駕馭人的情形。技術駕馭人是指由於狂熱和盲信，無原則的維護某種技術，把A推上天堂，把B踩下地獄。常見的程式設計語言爭執其實很

遞迴與goto                                   written by leezy_2000 記得剛開始學習C時，老師和教材都有明訓：“千萬不要亂用goto語句，否則將導致程式可讀性極度下降。但能夠極大提高效率地情況，可以考慮使用。”抱著不求有功，但求無過地心思，goto一度被我扔到了垃圾簍。後來隨著閱讀代碼量地增加，我發現goto至少在兩個方面可起到改善程式地作用。一是出錯處理，二是用來模仿遞迴。用來做出錯處理，在某些特定的場合可以，增強閱讀性。用來模擬遞迴，

因為看的書相對比較多，最近又寫了一本，感覺多少有點發言權，因此把自己的經過和感受寫出來，供想寫書的做些參考。現在浮躁的人比較多，所以我先說寫書不能達成什麼目標。最關鍵的一點是程式員寫書基本不能讓你發財，這裡有篇文章叫《寫一本書作者到底能拿到多少稿酬？》 

總目錄問題系列：之一，之二，之三，之四，之五，之六，之七，之八這句話的意思不是不讀書，而是讀書之外，先要思考，甚至是思考優先。開始中國有一段時間“特中國”，就是春秋戰國時代。現在我們所見的儒、道思想，以及潛移默化還在的墨、法思想，都是那個時代出現的。後來雖然尚有漢唐宋這些鼎盛朝代，但思想的類型整體沒有突破。而且春秋戰國雖然久遠，為人所記的人物事件卻多得出奇，春秋五霸且不說了，商鞅蘇秦張儀孫子孫臏龐涓管仲樂毅荊軻扁鵲……雖然並沒有《三國演義》這樣的通俗文學傳誦，但是仍然知名度很高。曾經和一位朋友討

第一種方法：運行sudo gedit /etc/default/grub 輸入密碼將GRUB_DEFAULT=0改為GRUB_DEFAULT=4（如果沒做過其他設定，即啟動時win7為第5項。可根據自己情況更改）然後運行sudo update-grub第二種方法：sudo chmod +w /boot/grub/grub.cfg(賦予該檔案寫入權限）sudo gedit /boot/grub/grub.cfg 將set default="0"改為set

CMMI批判之一CMMI實施中的偶然和必然從方法論的來源來看，必然是先有實踐，而後對實踐進行抽象，基於其相同部分，進行進一步的分析和歸納，最終形成方法論。所以方法論本身必然即是有限正確的又是不完備的。

總目錄：之一，之二，之三，之四，之五，之六，之七，之八 是否見過這種情境：一堆人在會議室，談論一個亟待搞定的客戶：“這個客戶可難纏了……”“可不是，我給你說……”“對對，我也是有親身體會的，比如……”“別提了，上一次……”又如一堆人在會議室，討論一個新的市場方向：“這個新方向不好開拓，……”“咱們剛開始，你看人家IBM……”“別提IBM了，就光一個XX就夠我們受的……”“咱們一無案例，二無資金，三無人才，……”暫且不管他們討論的事務本身，而來看一個問題：人們為何會向鯊魚撲向鮮血一樣，爭先恐後地表

作者：陳勇出處：blog.csdn.net/cheny_com     有沒有遇到某個重要的條目每次都被漏下完不成的情況？    有沒有遇到衝刺結束的時候發現一大堆條目都已經開工了但都沒有完成的情況？    有沒有遇到Product Owner想用一個重要的變更來替代原來Sprint Backlog中的某些條目卻發現這些條目都已經“開發中”了？   有沒有遇到團隊爭議每次都應該完成所有條目（這真的很難）還是只需要完成最重要的一些？  

這是敏捷開發日常跟進系列的第六篇。 （欄目目錄）產品負責人常常被描述成在計劃會前準備好使用者故事，在計劃會上講解並協助Team

程式員這個行業裡，加班多似乎已經成為一種共識。好多人是抱著即將“水深火熱”的心情加入這個行業的。在任何行業中，不加班是一定不可能的，那程式員可能少加班嗎？答案是有的時候是可能的，但也是艱難的。在看具體手段前，我們先來看一下加班的原因。導致加班的核心原因可以分為三類：人為的行政上的原因。這可以進一步劃分為兩類情境：一類是，在有的公司裡，不加班被等價於工作不努力。所以不管需不需要，那怕磨洋工也先加了再說。一類是，在有的公司裡，利潤和工作時間成比例關係，所以潛在的公司會推動多加班。 商業原因。這說的是

作者：陳勇出處：blog.csdn.net/cheny_com 在敏捷中直接估算天數最大的好處是直觀，壞處是很難衡量是否有故意的高估和低估，也不能比較生產力是否在提升，於是基於故事點的估算應運而生。基本使用方式故事點的基本做法是：把一些常見的“標準任務”給出一個“標準點數”，形成比較基準，估算的時候只要是同一類型的任務，直接寫上故事點數而非天數。比如：1. 對單個表進行增刪改查2. 為一個已經存在的資料表增加一個複雜報表3.

 win7下安裝svn伺服器端及用戶端詳細步驟1.下載伺服器端Setup-Subversion-1.6.16.msi，由於我是32位的系統所以選擇Windows列表下的Win32Svn (32-bit client, server and bindings, MSI and ZIPs; maintained by David Darj)2.安裝伺服器端，安裝路徑可以自己改，我的安裝路徑是D:/Program Files/Subversion3.下載用戶端TortoiseSVN-1.6.15.21

       作者：陳勇       出處：blog.csdn.net/cheny_com       自相似性是指一個事物的局部與其更大的局部乃至整體具有相似性。從大的方面看，敏捷開發具有重視客戶價值，提倡持續傳遞等思想。但一般而言，Product

曆時2周才完成的敏捷遊戲研發過程海報。整體思路是在遊戲研發過程中應用Scrum敏捷方法進行管理，在其他大團隊/長周期項目，或普通團隊實施Scrum時也可以借鑒。最上面的標題對應Scrum的各個活動，左邊則以概念-活動-實踐-文化-目標來詮釋各個活動的精華內容。如果想從頭讀到尾，請按各個文字框中間的串連箭頭逐個閱讀。中下部的大圖和Scrum常見的圖差不多，但由於遊戲團隊往往是大型團隊，必定存在Scrum of Scrums

作者：陳勇出處：blog.csdn.net/cheny_com 定義簡單看，139團隊就是1個專案經理，3個小組長，9個開發人員，小組長管理各自管理3個左右開發人員。139團隊從管理上縮減了團隊規模，可以被視同只有1個專案經理和3個小組長，細節交由小組長處理。這樣就方便在大型團隊中進行敏捷開發了。角色在Scrum敏捷團隊中，隊員們是平等的，只有Scrum Master是個個例。但由於在國內很難找到Scrum

這是敏捷開發日常跟進系列的第六篇。 （欄目目錄）要想不在評審會上得到“驚喜”，Product Owner最好提前約定好使用者故事的驗收標準，而且每個使用者故事可能各不相同。面向客戶價值設定驗收標準簡單說，就是客戶看到說“完成了”，才算完成了。從這一點上說，使用者眼中的“可工作軟體”和我們認為“可以運行，自動化測試了的，沒有缺陷的”軟體還是有差別的。使用者拿到軟體，是要使用從而獲得價值的，這常常需要多個功能聯合運行，前後資料完整一致才可以做到。在“敏捷產品管理”系列中，還會更加深入地探討這個話題。

諾基亞標準是諾基亞內部的一個簡單測試問題列表，用於判斷一個團隊是否真的在使用Scrum。問題如下：PART 1: ARE YOU DOING ITERATIVE DEVELOPMENT? 你們是否在使用反覆項目測試（做Scrum的一個基礎）1.1 Iterations must be timeboxed to less than 4 weeks * 迭代周期必須是限制長度的且少於4周？Yes our iterations are 4 weeks or less No 1.2 Software