結對編程的好處

1. 程序員與編程存在密不可分的關系，為什麼讓他如此厭惡

編程，有些人喜歡，有些人討厭，有些人從未嘗試過，還有一些人每天都在使用。

諷刺的是，要讓程序員在結對編程感到更加的舒服，我們需要在工作結束，或者在番茄鍾間歇的時候，多多交流，相互反饋。但程序員大多數沉默少言，並且很內向，他們之間的反饋和交流非常的不容易。

簡而言之，整個事情都不容易。

結對編程優勢不可能被否認，是有據可查的。但結對編程存在的問題卻很少被提到，但這些也非常重要。

鄭重聲明，我是一個結對編程的踐行者。對於我來說，和很多人一樣，我們都會對挑戰所帶來的收益進行評估，判斷是否值得自己去付出努力。但是我也相信，和其它的挑戰一樣，當你准備好，知道你自己應該做什麼的時候，事情就會變得很容易。

我們經常談論各種各樣的挑戰，我們可以使用我們的智慧來找到解決辦法。我們可以從中獲得好處並減少問題帶來的挑戰。舉個例子，我們並不需要對每一個任務都進行結對編程，我們可以間歇性的執行結對編程，更好地適合你團隊的現狀。

2. xp是什麼

xp

極限編程（Extreme Programming，XP）是一門針對業務和軟體開發的規則，它的作用在於將兩者的力量集中在共同的、可以達到的目標上。它是以符合客戶需要的軟體為目標而產生的一種方法論，XP使開發者能夠更有效 XP的響應客戶的需求變化，哪怕是在軟體生命周期的後期。它強調，軟體開發是人與人合作進行的過程，因此成功的軟體開發過程應該充分利用人的優勢，而弱化人的缺點，突出了人在軟體開發過程中的作用。極端編程屬於輕量級的方法，認為文檔、架構不如直接編程來的直接。

目錄

第三方的身份的事故發生過對方規范化和規范
黑屏警告
反盜版「黑屏」舉措
XP的核心思想
XP的十二種方法
四個核心價值
帶給我們的變化
極限編程的有效實踐
展開
編輯本段
第三方的身份的事故發生過對方規范化和規范

xp
編輯本段
黑屏警告

微軟中國正式宣布 xp黑屏警告，將從2008年10月20日起同時推出兩個重要更新，使用XP專業版盜版系統與OfficeXPe2003、Office2007盜版軟體的用戶將分別遭遇電腦「黑屏」與「提醒標記」等警告。
被稱為Windows正版增值計劃通知和Office正版增值計劃通知的這兩個項目均是可選擇式的服務。用戶可以通過微軟更新站點或自動跟新選擇下載安裝、經過驗證過程後了解自己使用的WindowsXP或Office產品是否為正版並獲得了相應的授權。
微軟方面透露，驗證通過的用戶直接使用WindowsXP或Office程序即可。對於因不同原因未通過驗證的用戶，將收到相應的系統通知。如：產品未激活或使用試用版下的「未激活驗證失敗」；因同步超時等原因引起的「驗證無法完成」；或「非正版驗證失敗」。
XP
xp如果WindowsXP用戶沒有通過正版驗證，將會體驗到：用戶開機進入後，桌面背景變為純黑色，用戶可以重新設置桌面背景，但是每隔60分鍾，桌面背景將重新變回黑色；會看到一個登錄中斷的對話框，並在屏幕的右下角會出現一個永久通知和持續提醒的對話框顯示「您可能是軟體盜版的受害者」等提示信息。
如果Office用戶沒有通過正版驗證，用戶體驗將分為三個階段：驗證失敗後的第1-14天內，客戶將在每天首次打開Office軟體和此後2小時分別收到一次對話框提醒；從驗證失敗後的第15天開始，提示信息將告知用戶如不採取行動，將在14天後，Office軟體被添加視覺標記；客戶在收到這些對話框通知30天後，Office軟體的Word、Excel，PowerPoint和Outlook程序的菜單欄中將被添加視覺標記。
微軟方面認為，這兩項計劃是旨在幫助中國用戶甄別電腦中安裝的微軟Windows操作系統和Office應用軟體是否是獲得授權的正版軟體，從而幫助那些在不知情的情況下安裝和使用了盜版軟體的用戶免受侵害。
XP實際上是一種經歷過很多實踐考驗的一種軟體開發的方法，它誕生了大概有5 年，它已經被成功的應用在許多大型的公司，如：Bayeris che Landesbank，Credit Swis s Life，DaimlerChrysler，First Union National BankFord Motor Company and UBS.XP 的成功得益於它對客戶滿意度的特別強調，XP 是以開發符合客戶需要的軟體為目標而產生的一種方法論，XP 使開發者能夠更有效的響應客戶的需求變化，哪怕在軟體生命周期的後期。
編輯本段
反盜版「黑屏」舉措

xp微軟中國正式宣布，將從2008年10月20日起同時推出兩個重要更新，使用XP專業版盜版系統與OfficeXP、Office2003、Office2007盜版軟體的用戶將分別遭遇電腦「黑屏」與「提醒標記」等警告。
XP
新聞發布後即引起了網友的極大反應。截止18：00，已有4萬名網友通過搜狐新聞的調查表達了自己的意見，其中22.7%的網友反對「黑屏」，認為微軟此舉太過分了。而66%的網友則堅稱要將盜版使用到底。
支持微軟的網友只佔7.8%。
不少堅稱繼續使用盜版。「不是不想用正版，而是太貴了。」類似該網友，希望微軟繼續降價的網友也不在少數。
XP-概述
同時，XP 也很強調團隊合作。團隊包括：項目經理，客戶，開發者。團結在一起來保證高質量的軟體。XP 其實是一種保證成功的團隊開發的簡單而有效的方法。
XP 強調四種價值：交流，簡易，回饋，勇氣。XP 程序員之間緊密的相互交流，XP 程序員也和客戶緊密的交流。他們總是保持他們的設計簡單明了。項目一開始，XP 就強調通過對軟體的不斷測試來獲得反饋，程序員盡可能早的把軟體交給客戶，並實現客戶對軟體需求提出的變化，有了這些基礎，XP 程序員就可以自信的面對需求和軟體技術的變化。
XP
XP 是與眾不同的，它有點象快步的舞蹈。XP 開發過程包括許多的小卡片，獨立的看，這些小卡片沒有什麼意義，但是當它們組合在一起，一幅完整的美麗的圖片就可以看見，XP方法有別於傳統軟體開發，它是軟體開發的一種新的重要的發展。它改變了用戶開發程序的傳統思維方式。下面用戶將介紹它帶給我們那些改變。
xpXP屬於輕量開發方法中較有影響的一種方法。輕量開發方法是相對於傳統的重量開發方法而言。簡單地理解，「量」的輕重是指用於軟體過程管理和控制的、除程序量以外的「文檔量」的多少。XP等輕量開發方法認識到，在當前很多情況下，按傳統觀念建立的大量文檔，一方面需要消耗大量開發資源，同時卻已失去幫助「預見、管理、決策和控制的依據」的作用。因此必須重新審視開發環節，去除臃腫累贅，輕裝上陣。
編輯本段
XP的核心思想

從長遠看，早期發現錯誤以及降低復雜度可以節約成本。極限編程強調我們將任務/系統細分為可以在較短周期解決的一個個子任務/模塊，並且強調測試、代碼質量和及早發現問題。通常，通過一個個短小的迭代周期，我們就可以獲得一個個階段性的進展，並且可以及時形成一個版本供用戶參考，以便及時對用戶可能的需求變更作出響應。
編輯本段
XP的十二種方法

規劃策略(The Planning Game)；
結對編程(Pair programming)
測試(Testing)
重構(Refractoring)
xp簡單設計(Simple Design)
代碼集體所有權(Collective Code Ownership)
持續集成(Continuous Integration)
現場客戶(On-site Customer)
小型發布（Small Release）
每周40小時工作制（40-hour Week）
編碼規范（Code Standards）
系統隱喻（System Metaphor）
編輯本段
四個核心價值

極限編程中有四個核心價值是我們在開發中必須注意的：溝通（Communication）、簡單（Simplicity）、反饋（Feedback）和勇氣（Courage）。
XP
XP用「溝通、簡單、反饋和勇氣」來減輕開發壓力和包袱；無論是術語命名、專著敘述內容和方式、過程要求，都可以從中感受到輕松愉快和主動奮發的態度和氣氛。這是一種幫助理解和更容易激發人的潛力的手段。XP用自己的實踐，在一定范圍內成功地打破了軟體工程「必須重量」才能成功的傳統觀念。
XP精神可以啟發我們如何學習和對待快速變化、多樣的開發技術。成功學習XP的關鍵，是用「溝通、簡單、反饋和勇氣」的態度來對待XP；輕松愉快地來感受XP的實踐思想；自己認真實踐後，通過對真實反饋的分析，來決定XP對自己的價值；有勇氣接受它，或改進它。
編輯本段
帶給我們的變化

通過軟體工程設計的簡單而優美的軟體並不比那些設計復雜而難以維護的軟體有價值。這是真的嗎？XP認為事實並非如此。
一個典型的項目花在人力上的金錢是花在硬體上的時間的20 倍，這意味著一個項目每年要花200 萬美元在程序員身上，而僅僅花10 萬美元在電腦設備上。很多聰明的程序員說：「我們如此聰明，發現一種方法可以節省20%的硬體開銷」，然後他們使得源程序大而且難懂和難以維護，他們會說：「但是我們節省了20%或者2 萬美元每年，很大的節省」。反之，如果我們寫我們的程序簡單而且容易擴展，我們將至少節省10%的人力開銷，一筆更大的節省，這是你客戶一定會注意到的一些事情。
另外一個對客戶來說很重要的問題就是程序的BUGS 。XP 不只是強調測試，而且要求正確的測試。測試必須是能自動進行的，以便為程序和客戶提供一個安全的環境。在編碼的所有階段，我們不斷增加測試用例。當找到bug 時，我們就添加新的測試，一個緊密的安全網就這樣產生了。同一個BUG 不出現兩次，這些一定會引起用戶的注意。你的客戶必須注意的另外一件事情：XP 開發者擁抱需求變化。XP 使我們能夠接受需求的變化。
一般情況下，客戶只有在系統被開發完成以後能真正去體會它。XP 卻不一樣，它通過加強客戶的反饋來縮短開發的周期，同時獲得足夠的時間來改變功能和獲得用戶的認同。在XP 中，你的客戶應該明確的知道這一點。
XP開發過程的大多的革命是在軟體開發的方法上，代碼質量的重要程度超出人們一般所認為的。僅僅因為用戶的客戶不能明白用戶的源代碼並不意味著用戶可以不努力去管理代碼的質量。
五、用戶什麼時候用XP
XP方法的產生是因為難以管理的需求變化，從一開始你的客戶並不是很完全的知道他們要的系統是怎麼樣的，你可能面對的系統的功能一個月變化多次。在大多數軟體開發環境中不斷變化的需求是唯一的不變，
XP
這個時候應用XP 就可以取得別的方法不可能取得的成功。XP 方法的建立同時也是為了解決軟體開發項目中的風險問題。假如你的客戶在特定的時間內，需要一個相當難開發的系統，而且對於你的項目組來說，這個系統是一個新的挑戰（從來沒有做過），那風險就更大了，如果這個系統對於整個軟體行業來說都是新的挑戰，那麼它的風險就更大了，採用XP 將可以減少風險，增加成功的可能。
XP方法是為小團體開發建立的，在2-10 個人之間。假如你的團體恰好合適，你就不需要用其他的軟體工程方法了，就用XP ，但是要注意你不能將XP 方法應用於大團體的開發項目中。用戶應該注意，在需求一慣呈動態變化或者高具有高風險的項目中，你就會發現XP 方法在小團體的開發中的作用要遠遠高於在大團體的開發。
XP方法需要一個擴展的開發團體，XP 團體不僅僅包括開發者，經理、客戶也是其中的一員，所有的工作一環扣一環，問問題，商討方法和日程，增加功能測試，這些問題的解決不僅僅涉及到軟體的開發者。
另一個需要是可測試性，你必須能增加自動的單元測試和功能測試，然而在你進行這個需求的時候，你會發現有許多的問題很難測試，這需要充分發揮你的測試的經驗和智慧，而且你有時還要改變你的設計以便它可以更容易的進行測試。記住：那兒有需求，那兒就應該有測試的方法。
在XP方法的好處的清單上，最後一條是生產力。在同樣的合作環境下，XP 項目都一致的表現出比使用其他方法高的多的生產力。但這從來不是XP 方法學的真正目標。XP 真實追求的目標是：在規定的時間生產出滿足客戶需要的軟體。假如對於你的開發來說，這是很重要的方面，你就可以選擇XP 了。
編輯本段
極限編程的有效實踐

完整團隊
XP
XP項目的所有參與者（開發人員、客戶、測試人員等）一起工作在一個開放的場所中，他們是同一個團隊的成員。這個場所的牆壁上隨意懸掛著大幅的、顯著的圖表以及其他一些顯示他們進度的東西。
計劃游戲
計劃是持續的、循序漸進的。每2周，開發人員就為下2周估算候選特性的成本，而客戶則根據成本和商務價值來選擇要實現的特性。
客戶測試
作為選擇每個所期望的特性的一部分，客戶可以根據腳本語言來定義出自動驗收測試來表明該特性可以工作。
簡單設計
團隊保持設計恰好和當前的系統功能相匹配。它通過了所有的測試，不包含任何重復，表達出了編寫者想表達的所有東西，並且包含盡可能少的代碼。
結對編程
所有的產品軟體都是由兩個程序員、並排坐在一起在同一台機器上構建的。
測試驅動開發
編寫單元測試是一個驗證行為，更是一個設計行為。同樣，它更是一種編寫文檔的行為。編寫單元測試避免了相當數量的反饋循環，尤其是功功能能驗證方面的反饋循環。程序員以非常短的循環周期工作，他們先增加一個失敗的測試，然後使之通過。
改進設計
隨時利用重構方法改進已經腐化的代碼，保持代碼盡可能的干凈、具有表達力。
持續集成
團隊總是使系統完整地被集成。一個人拆入（Check in）後，其它所有人責任代碼集成。
集體代碼所有權
任何結對的程序員都可以在任何時候改進任何代碼。沒有程序員對任何一個特定的模塊或技術單獨負責，每個人都可以參與任何其它方面的開發。
編碼標准
系統中所有的代碼看起來就好像是被單獨一人編寫的。
隱喻
將整個系統聯系在一起的全局視圖；它是系統的未來影像，是它使得所有單獨模塊的位置和外觀變得明顯直觀。如果模塊的外觀與整個隱喻不符，那麼你就知道該模塊是錯誤的。
可持續的速度
團隊只有持久才有獲勝的希望。他們以能夠長期維持的速度努力工作，他們保存精力，他們把項目看作是馬拉松長跑，而不是全速短跑。
編輯本段
程序

：
XP，是英文Experience（體驗）的縮寫, 自從微軟發布windows XP後,成為軟體流行命名概念。
Windows XP原來的代號是Whistler。Windows XP的外部版本是2002，內部版本是5.1，正式版的Build是2600。 微軟最初發行了兩個版本：專業版(Windows XP Professional)和家庭版(Windows XP Home Edition)。
2001年10月，Windows XP問世了，這個版本在Windows 2000基礎上開發。微軟此次為Windows XP造勢的規模相當大，XP（eXPerience）這個詞隨之深入人心，越來越多的軟體公司為了搭這個順風車，不管相干不相干都為自己的軟體名字後面加一個XP，甚至連AMD的0.13微米Athlon也「非常巧合」地命名為Athlon XP，不過AMD對XP的解釋是eXtreme Performance。
編輯本段
停售

美國微軟公司從2007年6月30日起，停止向零售商和幾家主要電腦生產商銷售視窗xp操作系統。
據美國媒體30日報道，微軟今後將不再向戴爾、惠普等主要電腦生產商提供視窗xp操作系統，但這些廠商庫存的裝有xp系統的電腦仍將繼續銷售。從這些商家購買新電腦的消費者，如果仍想安裝xp，也只能先接受Vista操作系統，然後再合法地將操作系統「降級」至xp。
不過微軟宣布，到2008年1月之前，該公司仍將允許一些家庭經營的電腦商店等小型零售商銷售xp操作系統。此外，微軟仍會銷售一款針對超低價個人電腦的XP系統。
XP操作系統上市至今已有8年。Vista是微軟繼xp系統之後推出的最新版視窗操作系統，於2007年1月30日面向普通消費者發售。但一些消費者認為，Vista系統對硬體配置的要求太高。另外，2008-2009適逢「上網本」開始快速發展。「上網本」即目前日趨成為筆記本電腦中的主流的一類個人終端，搭載有無線網卡，方便隨時隨地登錄互聯網，這類電腦的配置普遍較低，價格便宜，適合對於移動網路要求比較高而對硬體配置要求並不高的用戶。Windows xp顯然是這類電腦的首選。迫於上述原因，2009年4月16日：微軟決定延長國內xp主流支持服務。
編輯本段
疾病

XP也是著色性干皮病（xroderma pigmentosa）的縮寫。著色性干皮病是一種發生在暴露部位的色素變化，萎縮，角化及癌變的遺傳性疾病，屬常染色體隱性遺傳病。在某些家族中，顯示性聯遺傳。表現暴露部位發生針頭至1mm以上大小的淡暗棕色斑和皮膚乾燥，日曬後可發生急性曬傷樣或較持久的紅斑，雀斑可相互融合成不規則的色素沉著斑。也可發生角化棘皮瘤，可自行消退，疣狀角化可發生惡變。避免日曬，不宜室外工作。可用2－5%二氧化鈦霜外用，腫瘤及早切除。
編輯本段
口語

在如今網路終於豐富多彩的時候，XP在一些不願說臟字的人嘴裡就代替了牛X。
基督Χριστοs 的首兩位簡寫 ，羅馬皇帝君士坦丁大帝曾在夢中夢到基督，醒來後便讓手下正准備出征的戰士在盾牌上刻上XP，即基督之意。後來君士坦丁使基督教獲得了前所未有的地方，讓基督教真正的與政治統治結合了起來。
編輯本段
eXtreme programming

XP（Extreme Programming），它是由Kent Beck大師提出的。大師在經歷傳統軟體開發的痛苦之後，希望能夠找到一種優秀的軟體開發方法。大師總結了大量的軟體的成功和失敗的因素之後，提出了改進軟體開發方法的四個要素：溝通（communication）、簡單化（simplicity）、反饋（feedback）、勇氣（courage）。這形成了XP的核心價值觀。在經歷了數年的發展，XP在軟體開發的各方面都發展出了眾多的方法來支持軟體開發。
經驗值
在某些單機游戲與網路游戲中，XP就是EXP的簡稱，指的是經驗值。

3. 國內為何很少有人做結對編程呢是確實不好還是屬於中國特色

結對的代碼質量應該高於單干，單乾的效率可能高於結對。對於一個沒有敏捷基因，看重效率大於質量的團隊來說，結對的投入產出比太低，採用傳統方式也就理所當然。

4. 為什麼要Code Review

Code Review是我們項目成功的最有力的武器。下面我先談下我理解並實施的Code Review.

1. Code review的層次。
最基礎的，也是所有人都會想到到的，就是編碼規范，類，方法命名什麼的，還有代碼格式...這些是程序員的基本功底，默認選項；多年前領導要我搞個編碼規范，我說大家都熟知的規范就已經很好了啊；當然公司內部也需要這方面的規范，比如項目如何命名，包如何命名等這些。
更高一層次的，也是說的比較少的，是代碼的質量。前面能保證代碼寫的好看，大家看了都還順眼，但並不能保證代碼的可工作性，合理性，健壯性，可維護性。我們需要可以解決問題的代碼；我們需要最合理（最是相對的）的代碼；我們不希望破壞現有的架構搞特殊處理，如果架構本身不適應，那就可控制的重構；我們不希望有個工作很好的功能被破壞。

2. Code Review的好處
第一，最少有兩個人對同一段代碼深刻理解，並且認同。如果不能做到敏捷要求的「結對編程」的味道，我們就打個折執行吧。這一點從公司正常運營上，也是有好處的。
第二，開發人員可以放心的把自己的創造性發揮出來，因為他知道他有個堅強的後盾，絕不會等到QA發現不可饒恕的錯誤，然後經理過來罵你一頓。
第三，開發人員都會盡全力寫最好的代碼；軟體開發人員都是要"face"的，不想當時就被別人找到缺陷，尤其是你身邊的同事。再也不會只顧今天，不管明天會怎樣；對軟體的可維護性更加盡心。
第四，極大的提高軟體質量，以及可維護性。當然這要求Review人員的責任心，以及專業精神。如果是維護性項目，經驗也是相當重要的。

3. Code Review的重要性
至此，其重要性以已經不言而喻了。個人認為某種程度上其重要性以及你改超過Unit Test.

4. Code Review不好實施的原因
Code Review如此重要，但是據我接觸的人跟公司來看，真正認真執行的並不多。其原因無非：
ü 項目時間緊，時間跟人員都不充足；如果是這種情況，建議招點人，項目計劃制定的更合理些。
ü 重視程度不夠；開發人員都覺得自己很牛，代碼不需要給別人Review。其實問題往往就是由於過分的自信造成的，需要公司高層多做宣導，並形成制度，強力執行。等過一段時間，大家都會體驗到其中的好處的。
ü 執行起來比較麻煩。這是大問題。如果你讓開發人員覺得做Code Review是件很容易的事，並且收益大於付出，大家就願意做了。我們Team大致經歷過三個階段。
第一階段，按制定的流程，開發人員把修改的代碼用郵件發給Review者，並說明改了什麼，對系統那些功能有影響。然後負責Review的人Copy到Eclipse，對比CVS, 看代碼的改動是否合理。然後再郵件通知合格，或不合格，並說明原因(口頭或書面)。
第二階段，開發人員都覺得這樣太繁瑣，費事費力；於是我們開發了個Eclipse插件，幫助開發人員對自動生成代碼改動細節的郵件，並把改動的代碼自動放到指定的公用文件夾中。如此一來開發人員生成一個Code Review的請求，就是分分鍾的事情了(右鍵，寫點什麼，完成)就好了。
第三階段，開發人員現在很Happy了，但是Review的人覺得還是有點麻煩，要Copy,要寫郵件。於是我們把插件又改進了下，Review的人也可以在Eclipse上一鍵把代碼進來；然後提供了一個Web Console供頭頭看我們Code Review的情況。

5. 什麼是結對編程

結對編程（英語：Pair programming）是一種敏捷軟體開發的方法，兩個程序員在一個計算機上共同工作。一個人輸入代碼，而另一個人審查他輸入的每一行代碼。輸入代碼的人稱作駕駛員，審查代碼的人稱作觀察員（或導航員）。兩個程序員經常互換角色。
在結對編程中，觀察員同時考慮工作的戰略性方向，提出改進的意見，或將來可能出現的問題以便處理。這樣使得駕駛者可以集中全部注意力在完成當前任務的「戰術」方面。觀察員當作安全網和指南。結對編程對開發程序有很多好處。比如增加紀律性，寫出更好的代碼等。
結對編程是極端編程的組成部分。

6. 什麼是pair programming

結對編程技術是一個非常簡單和直觀的概念：兩位程序員肩並肩地坐在同一台電腦前合作完成同一個設計。

1995年，Larry Constantine在他的專欄中第一次提到了在他在P. J. Plaugherís software company, Whitesmiths, Ltd觀察到一個現象：Collaborative Programming（合作編程）。

1996年，Kent Beck，Ward Cunningham 和Ron Jeffries一起提出了Extreme Programming（XP），其中吸收了Collaborative Programming，並稱為Pair Programming。

同一個演算法、同一段代碼或同一組測試、與兩位程序員各自獨立工作相比．結對編程往往只需花費大約一半的時間就能編寫出質量更高的代碼， 但是，人與人之間的合作不是一件簡單的事情——尤其當人們都早己習慣了獨自工作的時候、實施結對編程技術將給軟體項目的開發工作帶來好處．只是這些好處必須經過縝密的思考和計劃才能真正體現出來。

7. 為什麼軟體開發方法論讓你覺得糟糕

圍繞軟體開發實踐和方法論，總有很多教條式的口水仗。階段式（phase-gate）方法能夠有效管理軟體開發過程的風險，還是說只是風險管理中的花哨噱頭？TDD真的能夠促生出高品質軟體？結對編程是代碼評審的有效替代抑或只是增加了商議溝通代價？我想說，雖然缺乏證據判斷這些論調的謬處，但有兩條常用的法則能夠幫助我們選擇好的實踐，同時，提升我們所提供軟體的價值：劃小開發周期以及提升反饋效率。
Michael Feathers給出了以下觀點：
我認為，我們最終還是得倚重開發者的能力，這才是個更重要的考量因素，而非選擇哪門語言或糾結於方法論間的細微差別。坦誠地說，我們都清楚這點，但我們看起來好像過度糾結於開發能力是關鍵因素這事兒上。或許這是個經濟學里一個被廣泛接受的觀點的引申，要是人人都可以替代（隨便找個人都能頂上），那該有多好呀？但事實並非如些。
問題是，我們怎樣才能找到有（合適）技能的開發者？IT界從未很好地定義個體生產率，從這點來看，那麼，要找到合適技能的開發者就是個很難解決的問題。代碼行數（Lines of code） – 在現在仍然是一個主流的度量方法 – 深陷「一行代碼一個責任」泥潭，這並不是一個好的方法。而度量工作小時數則是鼓勵（個人）英雄式舉動 – 經驗表明，「英雄們」通常就是導致項目延期的人，依賴「英雄」往往是一開始就採取的不該採取的冒險行動，長時間工作導致人變得魯鈍，並導致低質量軟體出 現。目前還沒有被普遍接受的針對IT專業人才的專業要求系列標准和僱用範式，招聘好的人才，是一門（招聘）藝術，而非（招聘）工程。
心理學家至少對這個問題進行了研究：為什麼IT業的技能很難被掌握和度量？Daniel Kahneman說（Thinking Fast and Slow），掌握技能有兩個基本條件：一個環境足夠規律以便可預測；有機會通過長時間實踐來學習掌握這些規律。
但是典型的軟體項目往往是沒有規律及可預測環境的。項目成功的唯一正確度量就是：最終的結果通過整個生命周期里的實施達到了預期目標嗎？ 很難知道什麼關鍵活動導致了項目成功和失敗，很少有人能夠通過舊有或現有的項目獲得答案。幾乎不可能判定哪些決策導致了成功或失敗（在人工智慧領域，這叫作信度分配問題）。
這些因素造成了IT專業人員很難掌握引導產品和服務走向成功所需的能力。然而，開發者掌握能幫助他們更高效地達到目標的技巧，將使他們更有動力 – 通常稱之為「開發完成」，盡可能快的、不考慮是否功能被集成以及生產就緒。類似的場景也常出現在其他功能性實施領域。
實際的軟體項目是復雜的，沒有規律可循，這會導致另一個問題 – 為了證明某種技術、實踐和方法論是實際有效而收集相關數據是極度困難的，幾乎不可能在脫離收集環境的情況下歸納出這些數據。
在Laurent Bossavit的好書《The Leprechauns of Software Engineering》中， 他抨擊了軟體開發的一些慣式，比如「成本變化」（或「缺陷成本」）「曲線」，這些慣式是許多其它的軟體開發方法論知識基礎，稱開發人員生產率的變化是一個數量級（參照確定性金字塔原理）。Laurent Bossavit說明了相關依據 – 很多人依賴從計算機科學專業學生進行的非正式試驗或是從無法被有效控制的項目中收集小量數據。這些研究組織的給出的論調基礎往往是不健全的，數據缺乏分析，而且，最過分的是調查結果普遍遠遠超出了他們的適用領域。
因此，不太可能輕易下論斷敏捷開發實踐就比瀑布模式之流合適，反之亦然。「方法大師」的見解其實也沒太大指導意義，就像Kahneman說的，「人們在想法方面的信心，並非是有效行事可倚重的因素…當評估專家的想法，即使在有規律可循的情況下，你也一定要想清楚是否有合適時機可以引入其想法的可能性」。就像Ben Butler-Cole指出的（why software development methodologies rock），引入一種新方法往往會帶來一些影響。
你可能會認為當我們決定怎樣運作一個團隊時，我們就陷入了被動。但細想一下為什麼軟體開發無章可循？為什麼在這個環境里很難進行一些試驗以及獲取技能？什麼實踐和決定會導致成功或失敗？其中的根原因就是：環境是無規律的，做出變更與理解變更帶來的結果之間的反饋過程太長了。這里的「變更」一詞是指廣義上的需求變更、方法變更、開發實踐變更、商業計劃變更、代碼或配置變更等等。
還是有一些辦法幫助縮短周期的，比如當我們應用精益軟體開發思想 – 一個很重要的方法。縮短開發周期在大型產品開發中是很重要的：在Bret Victor的精彩視頻Inventing on Principle中提到，「如此多的創新被發現，只要你真正理解了你在做什麼，你就能發現任何事物」。
但對我而言就是這樣的：我們幾乎不可能實踐持續改進、學會怎樣使團隊或個人變得更好、掌握成功創建大型產品與服務所需的技能。除非我們聚焦於盡可能使反饋間隔時間縮短，以便實際洞察其間關聯，以及辨別原因和影響。
事實上，從想法到反饋的周期盡可能短的好處是如此明顯和重要，應該把其作為商業模式中要遵循的一個重要原則。如果你糾結於要把你的產品創建成一個用戶安裝式的軟體還是SaaS模式（Software-as-a-Service，軟體運營服務模式，軟體即服務），這時的想法會自然而然地推動你強烈考慮SaaS模式（有感而發）。如果你要重建你的系統（包含硬體），應該考慮怎樣盡快實現原型（how you can get prototypes out as quickly as possible），以及模塊化硬體和軟體，以便你可以快速和獨立地整合。3D printing（三維列印成型技術）技術看起來在這方面有著巨大的用武之地，因為它可以滿足軟體開發應用實踐朝硬體系統（原型呈現）的演進。如果你想如願以償地縮短周期，或多或少按多功能型團隊（cross-functional teams）方式運作是需要的。
軟體方法論，即使僱用一群牛人並讓他們自我組織，也是糟糕的，因為他們時常搞得「cargo-cult」（貨物崇拜，敏捷開發里的知名小故事，形而上）：我們在做stand-ups（每日站立會議），我們有優先順序的backlog（優先待辦事務），我們甚至看在老天的份上實踐了continuous integration（持續集成）。
我們的到頭來的結果為什麼還這么差呢？因為你忘了最重要的事情：建立一個學習能力和適應能力都很好的組織。

8. 學習少兒編程，對孩子升學有幫助嗎

有用。
學習編程對孩子的幫助很大，可以歸納為以下10點：
（1）強化孩子的邏輯思維能力。
編寫程序最重要的是如何把大問題不斷分割成小問題。
編程中孩子要思考如何把代碼合理地安排在整個程序中，讓程序流暢地處理輸入、演算、輸出，這個過程對孩子分析事物的邏輯性有極大的幫助。
（2）培養孩子的專注力和細心度。
在編寫程序的過程中，排錯是無法敷衍了事的，這個過程能有效改正孩子馬虎行事的毛病，避免當個「差不多」先生。
（3）提高孩子的耐心。
編寫游戲和玩游戲的很大區別在於編寫游戲可以很好的鍛煉孩子延遲滿足感的能力，提高耐心，從編寫游戲，到玩游戲，是需要經歷一個比較長的過程。同時學會編寫游戲的小朋友，會在游戲過程中融入更多的思考，游戲視角會有明顯變化。
（4）增加孩子的抽象思考能力。
學習程序就是為了跟計算機溝通。這意味著孩子在學習的過程中需要一種化具體為抽象的能力，讓程序能夠按照孩子想像的方式運行，這是集思廣益的過程。讓孩子發揮無限想像並動手實踐，讓不懂得思考的電腦也能了解與表達抽象的事物。
（5）提升孩子整理信息、融會貫通的能力。
程序是一堆電腦指令的組合，程序中的基本指令就像是漢字，寫成可重復利用的方法或對象就像是成語。最終要完成項目，就必須融會貫通、學以致用，確保程序在執行中不會出現不可預期的錯誤。
（6）提升孩子國際性的溝通能力和競爭力。
編程語言已然成為一種重要的溝通工具，不但可以跟電腦溝通，還可以跟所有運用電腦的人溝通，這將會是他們面對國際和未來競爭的核心能力。
（7）讓孩子學會團隊合作和共同學習。
在適當的教學課程設計下，學寫程序就像玩游戲闖關一樣，同學彼此討論破關攻略。結對編程，你不會，我教你；我卡關，你幫忙；我設計，你闖關。同時，在互動中增進情誼，學習如何利用團隊的力量解決問題。比起老師在講台上單方面的講課，同學之間的探討更容易提高學習效率。
（8）訓練孩子的空間思考能力。
在編程中控制游戲人物的過程是訓練空間思考能力的一個很棒的方式。彷彿孩子自己在高低起伏中身陷迷宮，在闖關角色中置身於編程世界，在游戲中學習，明白方向感和立體的空間架構。
（9）增進孩子解決問題的能力。
面對一道道關卡的挑戰，孩子會不斷思考如何利用學到的知識、程序達到闖關的目的。一旦養成這樣的習慣，在碰到生活中或其他課業問題時，自然也會試著自己解決。父母只要給予適當的工具和提示，讓孩子自己動手、動腦去完成。
（10）Learn to code，code to learn。
學習編程，訓練編程的思考方式，父母再也不用逼著孩子學習數學，因為當他要完成按鈕、人物、得分、方向的同時必然需要用到許多數學的技巧，讓孩子在編程的同時自主學習。另外，還可以提高孩子的英文能力，編程讓接觸英文成為自然而然的事情。其他的科目（如音樂、藝術、文學等）一樣可以運用在編程的過程中，也就是我們所說的code to learn。