溝通，反饋，簡單，勇氣，尊敬是敏捷開發的五個價值觀， 它們深刻地反映了當前軟體開發組織中相對缺少但又對團隊建設和成功交付至關重要的東西。
這裡我想聊聊反饋，但並不討論關於反饋的全部，主要是集中在對「想」與「做」的節奏的**。
反饋是我認為最特別的乙個價值觀。實際上，做很多事情，我們總是重複著「想" - "做" - "想"- "做」...的迴圈。比如組織一場演出，我們需要多次彩排，每一次彩排前都有乙個計畫，彩排完後會有反饋，下一次彩排會根據反饋調整計畫，如此反覆。彩排之前不管計畫做的再漂亮，也都只是設想，只有去做了才能有反饋。再比如寫一段實現某一功能的**，我們會在頭腦中或在紙上表達乙個構想，此時還沒有反饋，然後再去編碼，如果實現時發現任何問題並決定調整設計再實現，這時反饋出現了，如此反覆。
我們每個人都有自己關於「反饋「的習慣，儘管很多人還沒有意識到這點。在上面的兩個例子中，不同人的做法是有區別的，我們這裡僅關注兩個區別，其一是習慣於「想」到了什麼程度才開始去「做」，其二是是否習慣於為在「做」過程中的「反饋」修改「想法」。
有些人習慣於在頭腦中或在紙上詳細決策好每一步，反覆構想，直到確信無疑時才去編碼，編碼前都沒有反饋，這樣做更有可能導致設計超出了問題的需要，或者做了很多未知的假設，甚至完全把設計導向錯誤的方向。有的組織將設計和編碼分為不同的階段，設計人員做完設計後就去幹別的工作了，對於他的設計工作，是很難有反饋的，這說明開發過程本身缺乏積極地接受反饋的意識。
反饋對設計的修正有非常積極的價值，這個價值有時甚至超過前期設計本身，而過渡設計則對專案有非常消極的影響，它不僅僅是浪費，這一點往往沒能被團隊發現並正確認識。
基於反饋的設計更容易體現真實的需求，更容易產生簡單的設計，增個過程中少了很多可能不需要的艱難決策。測試驅動開發包含了基於反饋的設計思路。
敏捷傾向於盡早製造反饋，頻繁產生和處理反饋。敏捷開發對前期設計持謹慎態度，設計就像計畫一樣，是用來被調整的假設，而不是要來嚴格執行的構想。前面想再多都只是設想，只有編碼才可能產生反饋，根據反饋的再設計比前期設計有更多的現實基礎。
敏捷團隊習慣於在「想」與「做」的快速節奏中保持對客戶價值的關注，這是一種不錯的感覺。常做過度設計的人往往不善駕馭反饋的節奏，經驗是保證不出大問題的關鍵。
聊聊軟體開發過程中的「怪現象」
本文所要分享的是軟體開發過程中，親身經歷過的 怪現象 為什麼說怪呢，人多力量大，似乎才符合常理，但是往往在軟體專案開展的過程中會出現人多 事少 工作量大的情況，這跟我們以往的認知大相徑庭。此處輸入描述 首先，要解釋下標題的意思。人多，指的是同乙個專案團隊 同乙個小組或者同乙個部門的範圍內 事少，指的...
開發過程中錯誤總結
1 18年5月28日 說明是.xml檔案的問題。去上.xml排查，看是不是註解。或者檔案本身書寫有誤。2 linux下 webstorm,ppt,wps不能書寫漢字。在啟動檔案中修改 啟動 sudo sh webstorm.sh export xmodifiers im fcitx export q...
開發過程中的加解密
1.加密演算法分為 可逆加密 對稱加密 des，3des，aes，pbe 非對稱加密 rsa，dsa，ecc 不可逆加密 單向加密 md5，sha，hmac 2.金鑰的介紹 對稱加密 將明文 密文 連同金鑰放入相應的加密 或加密容器 即可得到密文或者明文，實現加解密。在對稱加密中金鑰必須是相同的才可...