我在大學裡面學的專業是自動控制。反饋是任何自動化控制系統中必不可少的。比如，在控制鍋爐爐溫的控制系統中，想要把爐溫控制在600℃，那麼感測器必須週期性採集鍋爐的溫度，控制系統再根據爐溫來調整火力。溫度不夠的話，燒火的還得再給點力；溫度差不多了就可以一邊歇著了。
反饋的概念相當簡單，它在很多地方都發揮著重要的作用。本文拋磚引玉，初探軟體開發流程和實踐中的反饋以及利用反饋來改進流程的一些想法，並利用反饋的原理來分析現有的開發流程和最佳實踐。
大型軟體的開發是分布在世界各地的開發人員的數個月的體力和腦力勞動。各大公司都有一套開發流程來保證產品能夠按期交付。如果仔細分析這些流程以及流行的最佳開發實踐（best practice），它們無不是利用了反饋的基本原理。
在軟體開發中，我們應特別關注反饋的以下兩個因素：
反饋的成本(cost)：成本主要是指要花多少開發或者測試人員的時間來獲得反饋。
反饋的價值(value)：如果沒有這些反饋資訊，會產生什麼影響，以及在以後需要多大的成本來修復，這也就是反饋的價值。
仔細分析流程中反饋的這兩個因素，可以找到流程改進的方向：
關注流程中成本過高和反饋時間太長的反饋，想辦法使得某些反饋能夠自動化。儘量減少人工的參與，因為人的成本是很高的。
去掉或者優化流程中那些成本大於價值的反饋。反饋的引入是為了及早發現問題，因為通常問題早發現的修復成本更低。但是如果問題不嚴重，而且修復的成本也很低，為什麼要在前期花更多的時間來避免這樣的問題呢？
在專案正式開發之前，產品經理通常會和互動設計師一起設計系統的原型，然後邀請一些使用者來做測試。
原型測試將使用者對產品的想法，比如使用者是否對產品有需求，使用者是否願意掏錢買等資訊反饋給了產品經理，使得產品經理能做出相應的決策，比如如何去調整產品的方向，是否繼續在這個產品上投入。在這個反饋中，反饋的成本遠小於反饋的價值。如果方向錯了，後期開發和測試的時間都是白費了，所以原型測試被廣泛地採用。最沒效率的事情是在錯誤方向上努力做事。
我所在的公司，開發人員在開發與介面相關的功能時，也是首先用mockup工具或者畫圖板把介面先畫出來，找到相關的專家審核，通過審核後再開始寫**。雖然看起來正式寫**的時間比較晚，但是能避免後期返工，所以總的時間比一上來就寫**花的時間要少。
2.1.整合開發環境（ide）中的反饋
用過eclipse的程式設計師都知道，假如寫錯了乙個關鍵字或者方法的名字，eclipse會立刻高亮顯示錯誤的關鍵字，這樣程式設計師就可以立刻修改錯誤。ide將語法和編譯錯誤及時地反饋給了開發人員。在這個反饋中，反饋幾乎是實時而且幾乎沒有成本的，極大提高了生產效率，所以在實際的開發中沒有不用ide的。
2.2 單元測試
單元測試是對乙個類或者方法進行的測試，它保證你寫的類或者方法是按照你的想法工作的。
單元測試將乙個類或方法中的錯誤反饋給了開發人員，使得開發人員能及時修復錯誤。單元測試中發現的問題通常很快就能修復因為測試的範圍僅限於乙個類或者方法。在這個反饋中，寫個測試案例可能只要幾分鐘，但是如果不進行單元測試而是直接就把整個系統跑起來測試，很有可能你的乙個拼寫錯誤（比如把!=寫成了==）要花上1個小時才能發現，或者你沒有考慮的邊界情況在客戶現場導致很詭異的問題，要花上幾天才能找到原因並且給客戶不好的印象。僅僅從這個角度來講，單元測試也是很有必要的。想要做好單元測試，需要良好的環境支援，參見這裡。
2.3 **審查
醫生通常不會乙個做手術，那麼同樣程式設計師也不能乙個人寫好**就提交了。因為是人就會犯錯誤，**審查是讓其他同事幫助發現**的問題。
**審查者將**中如下問題反饋給開發人員，比如**風格是否統一，新寫的**是否符合系統的設計思路，是否重新發明輪子等等。
真要做好**審查，成本還是蠻高的。首先，為了讓別人能看理解你的**，特別是**比較多的時候，要組織大家來介紹一下背景，然後被邀請的同事再去閱讀**並提出修改意見。其次，爭議比較大的時候，還要組織會議來討論這些修改意見。可以看到，**審查不是占有乙個人的時間，而是幾個人的時間。所以，從提交**審查到拿到審查意見的反饋週期還是有點長，一般需要1-2天的時間。
為了使得**審查的反饋更加及時，我所在的團隊採用的方法是，在做大的改動之前，先把修改思路和設計方案與審查者溝通一下（解決方案的審核），及時發現與當前系統設計不一致的問題，然後才開始編碼，從而避免**已經寫好了，審查者對系統設計提出大量的意見。
如果沒有**審查的話，
這些問題在後期是很難修復的，特別是涉及到系統設計的問題，開發人員會說，「已經通過qa的測試了，再修改的話，他們還得測試呢」，最後也就只好那樣了。新加入的開發人員由於不知道一些歷史原因，修改**的時候參考現有**，經過幾個版本後，**的設計和最初的思路完全不一樣，然後大家就會抱怨系統設計得太爛了，之前的**寫得太爛了。
雖然**審查的反饋成本高，但是沒有**審查的影響也很大。因此，在各大軟體公司和開源專案中一直都是必須的，
產品好不容易上線後，使用者有沒有使用新加入的功能，用得爽不爽，花了多少時間完成乙個典型的任務。這些問題是產品經理們非常關心的，它們關係著產品是否達成預定目標以及未來產品改進的方向。不只是產品經理，開發人員也常抱怨自己不知道自己做的功能使用者的反饋怎麼樣，如果能夠得到使用者正面的反饋對開發人員是極大的鼓舞。
收集產品運營的資料能夠給產品經理提供這些方面的反饋。在這個反饋中，收集使用者使用產品的資料的成本是非常高，需要在軟體裡面加入相應的功能模組，並且想辦法把資料從客戶那裡傳回來（這裡針對的是客戶端軟體），最後還得有程式來分析資料。但假如沒有來自使用者使用行為的反饋，做產品就是盲人騎瞎馬，加了一堆使用者根本不用的功能，而對使用者的痛點卻一概不知。因此，現在很多軟體裡面都會收集使用者使用行為，有的會告訴你蒐集了哪些資訊，有的流氓一點就悄悄地蒐集了。
這個反饋的時間很長，必須要等到產品做出來之後，並且使用者使用一段時間後才能得到反饋，這就需要利用原型測試來得到使用者早期的反饋。
持續整合的基本思想是每當有人簽入**的時候，都會觸發一次系統的構建（build），並且執行所有的單元測試。如果有問題，立刻通知最後一次簽入**的開發人員。在沒有持續整合的時候，系統的構建通常是在夜深人靜的時候啟動，每天就構建一次。
每天構建一次的問題是什麼？如果一天有很多人提交**，並且當天的構建失敗了，或者有單元測試失敗了，大家只有在第二天來的時候才知道，這將影響到等待需要用當天構建做測試的同事。同時，因為有很多人簽入了**，誰都有可能是導致構建失敗的人。如果有持續整合，構建一旦失敗，肯定是最後簽入**的那個人的**造成的，問題的原因很快就能找到。
持續整合將新簽入**對系統的影響的反饋時間從一天下降到一次系統構建的時間。持續整合的成本很低，一旦配置起來，無需開發人員的參與，一切都是機器自動完成的。因此，現在持續整合是個非常熱門的話題的。
傳統的瀑布開發流程是全部開發好了再交給客戶。而敏捷開發的思想之一是在每個迭代結束都向客戶交付可以執行的軟體並聽取客戶的意見。顯而易見，客戶反饋的時間明顯減少，客戶的需求也能在下乙個迭代中得到解決。
結對程式設計可以解決**審查反饋時間過長的問題。當你在寫**的時候，你的夥伴就扮演了**審查者的角色，並持續地給你反饋。但是其成本較高，沒有被大規模地採用。
軟體開發流程和實踐非常多，在決定是否增加乙個步驟到流程中或者是否採用某種開發實踐的時候，看看它是否在流程中增加了反饋，並利用反饋的基本原來來分析一下，它帶來了什麼，成本是什麼，沒有它又會怎麼樣，有沒有替代的辦法來平衡反饋時間和成本，這樣才能調整出適合自己團隊的流程。
軟體開發的本質
關於這個話題，我似乎說過好多次了。軟體系統其實就是現實系統的抽象，就是現實系統的模型。最近，看到乙個論點，是這樣說的 軟體建模 架構 的過程其實就是乙個定理證明的過程。我得說，在我看來，這有一定的真理性。但是事實有一定的差異。基本原因是 我們碰到問題的時候，並不總是對問題的解決方案一無所知的，或者更...
軟體開發流程
課程的主講老師是msdn的特約講師邵志東先生。課程中間，邵志東老師介紹了軟體開發流程 程式設計師基本素質 關於質量控制和開發模板及專案組建設。邵老師首先介紹了軟體開發的流程，他把軟體開發分為了兩大類，即專案開發及產品開發。專案開發是公司根據某一客戶的需求單獨為某一客戶訂製的軟體 產品開發是公司針對某...
軟體開發流程
軟體開發流程 software development process 即軟體設計思路和方法的一般過程，包括設計軟體的功能和實現的演算法和方法 軟體的總體結構設計和模組設計 程式設計和除錯 程式聯調和測試以及編寫 提交程式。第一步 需求調研分析 1相關系統分析員向使用者初步了解需求，然後用word列...