捷對編程

㈠ 編程必須明確清楚這幾點，學習C語言和C++

一、宏觀：
將C++視為C、面向對象C++、模版C++、STL C++組成的語言聯邦。
任何人不得添加任何東西到STL命名空間
不要輕易忽略編譯器的警告
一定程度的使用測試驅動的開發方法
軟體實體（類、模塊、函數）應該是可擴展的，但是不可修改的
多採用敏捷的設計方法（個體和交互勝過過程和工具、可以工作的軟體勝過面面俱到的文檔、客戶合作勝過合同談判、響應變化勝過遵循計劃）
經常性的交付可以工作的軟體，交付的時間間隔越短越好
在整個項目開發期間，業務人員和開發人員必須天天都在一起工作
圍繞被激勵起來的個人來構建項目
在團隊內部，多進行面對面的交流
提倡可持續的開發速度
使要構造的系統最簡單（不要設計不需要的功能，不要過分設計）
最好的架構、需求和設計出自於自組織團隊
每隔一段時間，團隊會在如何才能更有效的工作方面進行反省，然後相應的對自己的行為進行調整
結對編程是一種比較好的選擇
不能容忍重復的代碼
持續的對代碼進行重構
要做計劃游戲
高層模塊不應該依賴於底層模塊。二者都應該依賴於抽象
盡可能的保證：抽象不應該依賴於細節，細節應該依賴於抽象（任何變數都不應該持有一個指向具體類的指針或引用；任何類都不應該從具體類派生；任何方法都不應該覆寫它的任何基類中已經實現了的方法）
每個編程單元盡可能的向使用者提供使用承諾：例如資源回收保證、數據一致性保證、無異常保證
盡可能的在程序中處理所有可能的異常，而且盡可能的精細。（try...catch）
應該讓程序體面的退出：在出現非計劃內問題時自動產生mp文件。（利用SetUnhandledExceptionFilter調用MiniDumpWriteDump）
要先設計好類，建好各個類的文件，才能寫代碼。
用pragma once代替h文件頭
二、類：
讓介面容易被正確使用，不易被誤用
設計class猶如設計type
將成員變數聲明為private
盡量不要讓類支持隱式類型轉換
friend成員函數是類介面的一種表現方式，但能避免使用就盡量避免
避免使用handles指向對象內部成分
慎重使用inline（小函數的確該用inline，但是考慮到inline函數無法調試，所以應謹慎）
確定public繼承表現出is-a關系（即Liskov替換原則，永遠可以用派生類取代基類）
避免覆蓋繼承而來的名稱（基類函數重載，派生不重載，則其他覆蓋；派生重載基類函數，則基類函數覆蓋；變數也可以覆蓋）
區別介面繼承和實現繼承（純介面（virtual=0），介面+樸素實現(virtual=0+實現)，介面+強制實現（non-virtual）,以上為public繼承，private繼承全部是為了繼承實現，而不繼承介面）
根據上一條，只要出現virtual，就盡可能讓它=0（成虛基類）
根據上上條，派生類不應該覆寫non-virtual函數
絕不重新定義繼承而來的預設參數值
private繼承意味著繼承實現，是composition，實現的是has-a邏輯。protected繼承盡量少用。兩種繼承在設計層面完全沒有意義，只是實現層面的代碼重用。
凡是獨立的對象都必須有非0大小（空對象會安插一個char）
一個類只負責一件事
一個類只提供一種內聚的介面（不應該讓用戶依賴於他們不使用的方法）
類內部的類型定義盡量放在public，否則不能作為返回值
類中的大屬性都應該用智能指針(或返回STL時應使用move語意）
凡是類內私有變數加m前綴，凡事類似私有仿函數，加or後綴
靜態成員初始化函數用靜態類替代,可以順便用個functor
四大函數（構造函數、拷貝構造、賦值、析構）
若有多態繼承體系，基類析構函數盡量聲明為virtual
如果類內new了對象，並且該類負責delete，則必須要定義拷貝構造函數和賦值操作符。
若不想使用編譯器自動生成的函數，就該默認拒絕（將其聲明在private或protected）
別讓異常逃離析構函數，C++不喜歡析構函數吐出異常
絕不在構造函數或析構函數中調用virtual函數（當然其他函數調用virtual可以實現template method等有趣的模式）
拷貝函數應該確保拷貝了對象內所有成員和基類部分
不要以某個拷貝函數去實現另外一個拷貝函數（一個是函數，一個是 assignment函數），應該把共同部分放在第三個獨立函數
三、函數：
盡量將函數參數聲明為const
另operator =返回一個*this的引用，並且在operator =中處理自我賦值
函數參數的構造順序不確定，所以不要在函數參數中執行new操作，或將多個函數參數都用函數來表示（否則若一個發生異常，其他有可能不會執行）。
盡量用傳遞const 引用代替傳值
non-member,none-friend函數有封裝性好，跨類型操作等能力，因此在需要的時候沒有必要局限於把函數全部放到類里的傳統規則。
若所有參數都需要類型轉換，請為此採用non-memeber函數（典型的是雙目操作符重載）
凡是需要對指針參數做提領操作，都需要檢查是否為BULL
發布版程序維持程序的勉強工作比crash更好；debug版讓程序盡量crash。
希望可以幫到你，謝謝！

㈡ 結對是什麼意思

在不同場合下有不同意思，最基本的是結成一對的意思，其他的比如：
結對助學
要求單位選出幾名學習優秀分子採取"一帶一"或"一帶二"的形式,結對助學.
結對編程
簡介結對編程技術是一個非常簡單和直觀的概念：兩位程序員肩並肩地坐在同一台電腦前合作完成同一個設計。同一個演算法、同一段代碼或同一組測試、與兩位程序員各自獨立工作相比．結對編程往往只需花費大約一半的時間就能編寫出質量更高的代碼， 但是，人與人之間的合作不是一件簡單的事情——尤其當人們都早已習慣了獨自工作的時候、實施結對編程技術將給軟體項目的開發工作帶來好...
結對資助
結對資助是指捐贈者通過希望工程辦公室的安排與受助學生建立直接聯系，或形成一對一的資助關系。該種捐款方式可以通過書信直接聯系，可以讓貧困生在捐贈者的關懷下健康成長，同時可以有效保證希望工程的透明度。結對資助的方式已經成為社會上人們最樂意採取的奉獻愛心的方式。結對資助-捐款批次1、一次性捐款結對資助：即捐贈者將受助學生所需學費，一次性捐贈給希望工程工作機...
結對幫扶
概述結對幫扶是一項扶貧政策，即黨員幹部一對一結對子，幫扶城鄉困難家庭的活動。為貫徹落實黨的十七大和十七屆三中全會精神，加快推進以改善民生為重點的社會建設，讓城鄉困難群眾共享改革開放成果，我國普遍深入開展結對幫扶活動。 具體來說，結對幫扶是以先進帶動後進，優勢帶領劣勢的一種優勢群體幫助扶持相對弱勢群體的形式和手段。可以是一對一，也可以...
雙結對
背景「雙結對」活動是區委貫徹落實市委「高興、放心、凝聚、覆蓋」主題活動要求，切實開展先進性教育活動的重要載體和抓手。龍柏街道在推進「雙結對」活動中，一方面認真做好上級要求的規定動作，街道機關黨支部與龍柏三村第一居民區黨支部結對，與龍柏三村困難同學、困難黨員結對；居民區26個黨支部與區委辦局20家單位26個黨支部結成對子。另一方面積極做好街道自選動作，...

㈢ 敏捷開發、極限編程和結對編程這三者什麼關系啊

敏捷開發是十幾種開發方法的統稱，極限編程就是這十幾種開發方法之一。
極限編程包括了十幾種實踐（就是一些具體做法），結對編程是極限編程的一種實踐。

㈣ 程序員，如何少走彎路，成為一名技術專家或者架構師

#1 專業技能

@首先當然基礎知識要扎實，一些經典的專業書籍一定要看。比如，設計模式，演算法，數據結構，所在領域的編程語言的專業書籍等.關於不同的能力階段，需要讀取什麼類型的書籍，請參考ThoughtWorks(中國)程序員讀書雷達,每年都有更新。
@作為架構師，review別人的代碼並給出合理的建議是基本功，比如變數或者方法命名的規則；所以代碼大全，重構，改善既有代碼的設計，Clean code 等等肯定需要看。
@ 對於某一個技術領域或者業務領域，一定要有一門技術是精通的，因為這樣你才能體會到以後遇到自己不懂的技術的時候，如何能夠快速成為這一方面的行家。
@ 平常有時間一定要多多進行代碼的訓練，也就是Martin Flower常說的Kata練習，這個比喻來自於跆拳道，跆拳道選手一般每天都會找一些基本的招式，進行反復的練習，從而訓練肌肉的條件發射，那麼對於我們程序員來說，一定也要進行持續的編程訓練，比如上面提到的那位同事，給的建議是，雖然把大部分時間花在了溝通和協調上面，沒有機會寫代碼，但是自己一定要利用業余時間，自己找一些例子來聯系，比如，參與開源項目，或者到網上去搜索一些大師的經典Kata聯系的例子；或者看工作裡面是否有一些小工具，是否能夠提升自己的溝通效率，當然已經天天寫代碼的童鞋們除外。請參考我轉發的另外一篇文章和另外一篇介紹能在線練習Kata code的文章.
@ 最好能夠在精通一門語言的基礎之上，學習其他的語言，從而站在一個更高的角度，對於程序語言有一個更高層次的抽象認識，比如，學了java之後，可以學學Ruby，Groovy，C#等等，其實語言之間都是相互借鑒的，比如Lamba表達式，連java也慢慢的向函數式編程方向靠攏。
@ 如果有時間，一定要自己維護一個博客,既然選擇了架構師，就決定了自己以後不僅僅是一個技術專家，同時也要成為一個佈道師，為企業組織或者社會上的其他IT同行們貢獻自己的一些微薄之力。
@ 多參加一些社會上舉辦的軟體專業會議或者活動，了解當前比較流行的技術和框架。
@ 這條不提倡，我以前有一個同事，幾乎每年都要更新簡歷1~2次，目的不是真正的換工作，而是通過面試得到當前市場上大部分公司正在使用什麼技術和框架。對於這條，請慎用！！！！
@如果有結對編程的機會一定要好好珍惜，特別是和高手大拿一起結對的時候。
@如果大家上面都已經做的非常的好了，這個時候可以看看架構設計方面的書籍，比如企業應用架構模式，架構之美等等。
@ 去51Job上搜索架構師這個職位標簽，看看不同行業的企業對於架構師的技術要求和標准，然後結合自己當前所處的行業和你自己的技術特點，比如擅長前段或者後端，有選擇性的學習一些自己感興趣的技術或者方法。
@ 關於常用的網站，沒有定論，筆者主要是根據搜索的結果去發現適合自己的網站，所以需要讀者掌握一定的搜索的技巧，筆者一般喜歡用英文搜索，這樣的話資料比較全也比較新；如果下載電子書的話或者查看博客的話 一般會首選CSDN；如果是解決工作中的問題的話，在StackOverFlow上面被解答的概率是最大的,此外平常自己也需要去積累一些自己感興趣的技術的人氣比較旺的網站列表，比如一般和Window相關的就是MSDN；如果對Java入門比較感興趣，可以看看這個網站。對於一些開源的框架，一般都會有想對應的社區，google一搜索，很快就能找到。另外一個德國人寫的博客的非常的精緻，如果對Eclipse插件開發特別感興趣的朋友們可以去參考它。
@大家如果時間和精煉允許，最好能在Github開源和分享自己平常寫的代碼。這樣一方面可以熟悉git用法，另外一方面也可以把自己平常練手的代碼免費保存，何樂而不為呢？
@如果大家平常遇到什麼問題，可以到StackOverFlow上面去尋找答案；當然，如果你能自己注冊一個StackOverFlow賬號那是最好不過的，這樣不但可以提問，還可以幫助別人，同時上面還有很多工作簽證的工作機會。
#2 軟技能（現代社會，一個合格科學家不僅僅是某一個行業的技術專家同時也是一名專業的社會活動家）

@遇到問題，一定要多想，遇到一個問題，如果解決了，就要反思為什麼能夠解決，如果以後遇到類似的問題，
如何更快速的解決。
@英語的重要性，不言而喻，因為現在很多新技術的框架的中文文檔非常的少，即使翻譯成中文，也是二手的了（國內自己的開發的一些開源框架除外）
@ 有時間的話，看一些溝通方面的書籍，如果有參與溝通的機會的時候，一定要想如何把溝通做的更好更舒暢。
@ 如果有機會的話，可以參加PMP的考試，關於如何備考PMP，請大家參閱另外一篇文章:如何備考PMP，但是如果不想參加的話，也沒有關系，至少要涉獵到項目管理方面的書籍，否則以後如果成為架構師之後，客戶或者管理者給你說一些項目管理上一些專業術語時，到時候就會一頭霧水。
@架構師其實從某種意義上就是一種角色，而不是一種職位。一定要時時刻刻保持空杯心態。
@一定要有一顆保持飢渴學習和耐得住寂寞的赤子之心。
@當前的技術節湊是非常快的，特別是結婚以後又有小孩了。一定要好好的利用自己碎片時間，對於一些技術，當時讀不懂不要緊，但是一定要記住和了解其關鍵詞，這個主要是為了拓寬自己的視野。比如，當前你想自己開發一個系統，結果已經有一個開源框架實現了，而且還很穩定，這個時候，自己就沒有必要重復發明輪子了。
@與不同的技術、編程語言、設計模式和結構等（甚至是它並沒有在日常中給予你直接的幫助）打交道。你永遠都不知道這些知識是否會在未來派上用場，但是對你絕對是有益無害。
@在工作中，能夠幫助到別人解決技術難題，一定要盡量全力以赴，因為這不但可以贏得同事的好感和口碑，同時也能增長你解決問題的經驗和提高你的技術思維能力
@ 一定要掌控好自己的時間，對工作沒有幫助的會議，能不參加盡量不要參加，當然，企業安全，公司規章制度如果是強制性的，該參加還得參加，但是如果沒有工作效率和扯皮的會議，盡量避免參加。
@程序員要耐得住寂寞，要在自己的領域深挖，不能看啥火，就學啥，一定要有自己的想法和判定，如果決定不了，可以向資深的同事或者朋友溝通。
@盡量參與到項目中的編碼，因為架構師不能與項目脫離。
@ 如果有機會可以鍛煉一下自己在大眾環境下的演講和PTT的能力。
@有機會多做知識分享，因為你一旦分享了知識，你就會對這門技術有深刻的印象，同時也能樹立在同事中的良好的技術形象，從而贏得更多的專家影響力而不是職位影響力。
上面只是我當前能想到的，知易行難，知道了上面的一些經驗，並不代表年輕程序員們就能馬上成功，畢竟這需要一個鳳凰涅槃和實踐的過程，但是肯定能幫助有志於於此的年輕程序員們少走一些彎路，限於筆者水平，如有總結不恰當或者不到位的地方，還望批評指正。

㈤ 編程老手的哪些特點，是值得新手程序員學習的

有經驗的程序員會做到下面 29 項事情，這也是每個新手程序員應該知道的事情。
如果你想成為更好的開發者，你應該尤其注意第 15 點和第 29 點。
1.積極大膽地谷歌。你得知道如何有效地組織搜索關鍵字，查閱別人寫的代碼，然後合理地用在代碼里，從而解決問題。
2.擁抱變化，堅持不懈。老手程序員在接觸新技術時，能欣然接受像個初學者一樣處處受挫，並總能在完成工作的同時自學成才。
3.承認細節的重要性。例如變數和函數的命名、CSS 屬性的命名、該用哈希還是用數組，以及其他看起來微不足道，但可能對項目有深遠影響的事情。
4.承認大多數的「重要決定」其實並沒有那麼重要。一般的開發者經常在技術選型等「重大問題」上陷入唇槍舌戰，而程序員老鳥們會避免浪費時間在罵戰中。這一點上，他們就像禪宗大師一樣（zen-like）。
5.選擇合適的工具解決問題。網上有無數的開源庫、工具和框架，讓人眼花繚亂。而老手們清楚地知道針對怎樣的問題，應該用什麼樣的工具。
6.明白代碼「不值錢」（該刪就刪）。你必須習慣於刪掉幾百行代碼來重寫程序的某一部分，毫不留情。
7.在評估技術的時候要全面。例如，我一直在鼓吹Elixir。它語法優美，社區完善，有很大的潛力。但Elixir誕生的時間太短，所以如果要構建復雜的功能，可能會難以找到能幫你提高效率的開源工具。因此，在評估要不要選擇使用一項技術時，你得把所有這些因素都考慮在內。
8.學會說「我不知道」。沒有比拒絕承認自己不知道更能浪費一個開發者的時間了。
9. 仔細分析錯誤信息里的線索。傳統教育告訴我們：失敗是壞事。報錯信息這種東西也經常被跟失敗聯系起來，然而優秀程序員明白，這些錯誤消息里其實隱藏著能將你指向最終正確解決方案的線索。
10. 了解過早優化和必要的「炫技式」優化的區別。老手們清楚在什麼時候需要寫一些看上去沒那麼好懂，但會讓程序運行更快的代碼。
11.每個人都會犯錯，為自己的過失負責。而尤其在團隊里，把責任推來推去沒有任何意義，因為錯誤的發生往往不只是一方的因素造成的。
12. 成為你所用的開發工具的重度用戶。如果長期在某個開發環境下有相當比例的開發工作，那你應該去掌握使用它的細節。
13. 學會用Vim（至少會一點）。 你至少應該在這個編輯器里學會勉強地移動和翻頁。
14. 不要接陌生技術領域的私活。個人做自由職業項目，其中很大一部分挑戰就是評估項目時間。不要規劃自己未知領域的事情，那會讓你處於想當尷尬的境地。
15. 不要數你幹活花了幾個小時。技術大牛會把時間花在有深度的工作上，並且他們清楚花了多少時間完全不重要。
16. 學會坦然接受批評。當你的代碼因為各種原因四分五裂時，你需要培養用理性和邏輯的方式來應對（而不是情緒化處理）。
17. 同有更多經驗的人結對編程。沒有比這個更高效的編程學習方式了。
18. 一定要先自己做一遍代碼審查。當你在GitHub上發起一個pull request之前，先把代碼當成別人寫的，自己先審查一遍。
19. 認識到做自由職業的難點不是寫代碼，而是其餘的所有事情。銷售、推廣、客戶支持，質量保證以及產品管理，所有這些都會花費大量時間。
20. 發現並解決更大的問題。優秀的程序員不拘泥於眼前的問題，而是清楚如何用更長遠的方式徹底的解決這一類問題。
21. 深入了解一些大型開源項目的核心能讓你開發時如虎添翼。如果你知道如何給你的項目打猴子補丁(Monkey Patch), 那麼你將無所不能。
22. 跳過多數的會議。你的公司雇你是來寫代碼的，而不是談代碼的。當會議多到失控的時候，不去參加也沒有任何問題。而且一旦你開始這樣做，別人會更珍惜你的時間。
23.知道什麼時候開始回饋。到了某個時候你需要將你的技能和經驗傳授給年輕的開發人員，就像你的導師當時教授你一樣。
24. 能寫爛代碼。有時候可以當一當「膠帶式程序員」。關鍵是隨著時間推移，你需要弄清楚什麼時候可以走捷徑，什麼時候必須走捷徑。這其實是最難掌握的技能之一。
25. 禮貌地告訴別人你工作到很晚。如果你是辦公室里最後一個，可以發一封簡短的匯報郵件。別人一般會注意到郵件上的時間戳的。
26. 像一個領導者(Leader)一樣做事，而不是老闆(Boss)。老闆是讓別人為他工作的人，領導者是人們追隨的人。做個領導者。
27. 去打打桌上足球。從長期來看，同其他開發者（或不同崗位上的同事）建立聯系會比在緊巴巴的期限里交付一個功能更有價值。
28. 在壓力下學習。你需要知道如何應對像系統宕機而你要負責將它復原的情況，即使一開始你完全沒有頭緒。
29. 「Move fast and break things」別讓完美主義阻止你做事。錯誤往往是最好的學習機會。所以別把犯錯當作失敗，而應該把它們當作值得學習的經歷，並意識到：正是不斷克服和突破這些錯誤，作為一個程序員，你才能不斷成長起來。

㈥ 解釋XP中的結對編程有哪些好處弊端在哪裡

結對編程技術是一個非常簡單和直觀的概念，能達到事半功倍的工作效果。但是，人與人之間的合作不是一件簡單的事情——尤其當人們都早已習慣了獨自工作的時候。實施結對編程技術將給軟體項目的開發工作帶來好處，只是這些好處必須經過縝密的思考和計劃才能真正體現出來。而另一方面，兩個有經驗的人可能會發現配對編程里沒有什麼技能的轉移，但是讓他們在不同的抽象層次解決同一個問題會讓他們更快地找到解決方案，而且錯誤更少。

㈦ 什麼是結對編程

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

㈧ 結對編程中兩位程序員分別充當什麼角色

執行者和觀察者。

如果你是執行者，當以最快的速度完成了某個程序時，往往會忽略一些問題，在這個時候，搭檔就是保障。

如果你是觀察者，仔細審查對方的代碼，考慮可能的錯誤，以及如何簡化和改進設計。在無法讀取的時候找出bug，但是不要即時就要求刪改，而是等到對方專注編程之後，進行到一個程度再整體調控會有效。例如，如果你看到現在的代碼沒有考慮空輸入，在一張紙上寫下，「添加單元測試的零輸入。」
觀察者和執行者都是靈活互動的，而不是機械一成不變的完成任務即可。觀察者並不需要去研究小細節，但是要考慮更高的層次。例如「看起來不錯，但是如何處理遇到空指針的情況？」聽起來就比「好了，現在輸入'如果（S == NULL）{返回..}」」好很多。

㈨ 結對編程的時候:如何實現在線的遠程代碼審查和版本控制兩者如何才能相互結合在一起

其實使用版本控制工具git，就可以方便地實現了。
git還支持遠程訪問版本庫。

這樣代碼撰寫者與審核者，可以通過版本庫來交流了。

git還支持被部署到windows和Linux上。

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

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