三、
反饋1)
客戶對軟體的反饋
在極限程式設計中乙個很重要的實踐是有現場客戶，從此也可以看出來對客戶反饋的重視。有了現場客戶，就能夠隨時對軟體做出反饋，能夠保證在「瞄準」的過程中不斷調整，保證軟體前進的方向。而且，現場客戶還可以對開發人員在開發過程中遇到的問題隨時做出反饋，那樣開發人員就可以避免由於自己的主觀猜測而出現的錯誤了。而這正是在傳統的軟體工程的編碼階段程式設計師最容易犯的錯誤，因為在那個階段，已經沒有客戶的參與了，編碼人員只是根據詳細設計來編寫**，對業務的不了解往往會造成編碼和單體測試都非常困難，甚至於出現嚴重的錯誤，一直到最後驗收測試的時候才能夠被發現，而此時修改的代價是非常大的。由此我們可以看到由於現場客戶的存在，把這些可能出現的錯誤消滅在了萌芽狀態，很多時間、精力以及資金都節省下來了。
但是並非說我們可以從客戶的公司中隨便找乙個人來做現場客戶就可以了，現場客戶的選擇也應該是乙個可以直接影響到專案的成敗的因素。乙個好的現場客戶不僅可以準確的把握軟體的方向，回答業務問題，而且可以編寫驗收測試，保證軟體中的業務資料沒有錯誤。這樣就要求他不僅是乙個管理人員，而且計算機的水平也要有一定的高度。這可能在國外並不難找到，但是在國內可能會有很大的困難的。
如果一旦沒有現場客戶，那麼我們必須要有相對應的方案來應對。我想一種方式可以是這樣的：保證有乙個系統分析員級別的人，他可以少量的參與編碼的工作，因為結對程式設計的過程中他會給大家很多的幫助，另外他還有乙個更加重要的任務，就是負責與客戶之間的交流，及時的將經過短期迭代的小版本的程式交給客戶，並聽取他們的反饋意見，也就是要他起到開發人員和客戶之間的乙個橋梁的作用。
2)測試**對功能**的反饋
在極限程式設計中提倡的是「編碼未動，測試先行」，也就是說在編寫功能**之前就先要編寫測試**，測試**可以用來保證我們的功能**的執行是否正確。一般來說，我們都是使用xunit作為開發測試**的工具的。
有了測試**之後，功能**的編寫更加像是乙個解決問題的過程，什麼樣的問題呢？也就是讓xunit的那個狀態條變綠的問題。我們需要不斷的調整我們的功能**，讓狀態條不斷的從紅色變成綠色，看著那種環保的顏色，我們的心情也會變得好起來。
這個方法在程式需要不斷變化的時候尤其有用，因為我們在一般的情況下，如果修改了功能**，那麼以前所作的測試工作都需要重新來一遍，那樣既浪費時間，又容易出錯。有了自動化的測試**，我們只需要執行一下test case，看它給我們的反饋是什麼樣的就可以了。如果xunit**給我們的資訊是沒有錯誤，我們大可以放心的繼續我們的工作了。
但是，並非是說有了xunit工具就萬事大吉了，我們必須要很好的利用這個工具才可以。首先，一定要有一定的測試的理論知識，明白需要採用什麼樣的資料作為測試用例，那樣才能夠做到真正好的測試，才能夠保證程式的質量。另外，測試**的編寫不是一次就完成了，隨著功能的新增，我們的測試**也一樣要隨之而改變，在保證原有**沒有問題的前提下，繼續編寫新的**。
3)管理人員對開發人員的反饋
這一點看起來似乎不很重要，但是仔細想一想，軟體最終的完成靠的是誰呢？這個答案大家應該都非常清楚，其實就是所有的開發人員。沒有管理人員乙個專案可能會延期完成，或者說質量不高，但是如果沒有了開發人員，那麼專案是一定不能夠完成的。所以，為了保證開發人員的滿意度，管理人員對開發人員的意見的反饋是非常重要的。
開發人員在工作的過程中一定會遇到各種各樣的問題，比如說休息、待遇、工作的環境、工作使用的工具軟體等等，這些問題可能會直接影響到工作的積極性和效率，所以管理人員一定要時刻豎起耳朵來聽取這些意見，並及時的進行反饋，避免開發人員帶著情緒工作，那樣不僅僅會影響到自己，而且由於結對程式設計的特點，那樣的情緒會很快的傳遍整個團隊，等大家都對當前的專案有了牴觸情緒的時候，接下來的結果也就可想而知了。
我想，管理人員的任務就是要將開發人員團結起來，使得所有的人真正成為乙個團隊，而不是一團散沙。想要做到這一點，就需要時刻了解開發人員的要求，似乎看來他們所做的是類似於後勤的工作，但恰恰是這樣的工作往往是最重要的。
二、勇氣
1)接受任務的勇氣
在專案開始的時候，一般的情況是由管理人員來為開發人員分配任務。但是，這種分配只不過是根據管理人員自己心中對每個人的估量來做的，所以很難做到每乙個人都很滿意。有些時候某些人希望從事自己沒有做過的任務，從而學習新的知識；同時還有一些人想要從事自己熟悉的任務，那樣可以在更短的時間裡面做出更多的成績。不僅僅是對於每乙個人，就是對乙個人，可能在不同的時間裡面他們的想法都是不一樣的，所以說，憑管理人員主觀的判斷來給大家分配任務一定會有一些人對自己的任務不夠滿意。
在這個時候，我們不妨嘗試這樣的一種方法，將所有的任務公布給大家，然後讓開發人員自己來選擇自己想要做的任務。這樣，由於任務是自己選定的，那麼滿意度會有很大程度上的提高。
在這種情況下，重要的一點就是開發人員要有接受任務的勇氣，如果所有的人都選擇自己覺得容易的任務，而迴避困難的任務，那麼我們的方法就失敗了，因為必定會有一些任務無人選擇。在這個時候，管理人員應該採取適當的方式鼓勵開發人員，促使能夠選擇一些對自己具有挑戰性的任務，那樣對於個人的提高也是很有好處的。
其實想一想，作為開發人員，應該都不會有問題。勇於迎接挑戰，正是現在的程式設計師大多都具有的一種素質。
程式設計的四個層次
大學已經學了三年了，學了三年的計算機自己總結出來程式設計的四個層次。語法階段 專家階段 執行機理 設計模式 語法階段這是程式設計的最低階段，也就是熟悉一門語言的語法就和你學英語學習的句型語法一樣，自己覺得這個階段是十分簡單的，程式語言的語法比英語日語等的簡單多了，如果你是個老手的話最多花3個小時就可...
CSS 最核心的四個概念
摘要 學習web前端必看，最最基礎 核心的css概念，慕課網。html元素可以分為兩種 兩者的區別在於一下三點 塊級元素會獨佔一行 即無法與其他元素一同顯示在同一行內，除非你顯示修改元素的display屬性為block 而內聯元素都會顯示在一行中 塊級元素可以設定width height屬性，內聯元...
對三層的四個問題
表現層 ui 通俗講就是展現給使用者的介面，即使用者在使用乙個系統的時候他的所見所得。業務邏輯層 bll 針對具體問題的操作，也可以說是對資料層的操作，對資料業務邏輯處理。資料訪問層 dal 該層所做事務直接運算元據庫，針對資料的增添 刪除 修改 更新 查詢等。例子 飯店的這個例子很形象，很容易明白...