之前寫典型使用者和場景的時候，越寫越發現這個分析的重要性。我那時以自己為原型，寫了幾個「我」，說幾個「我」其實也不完全是我，就是把別人架到自己身上。將大學生主要分成四五類，乙個窮人家的孩子，乙個公尺蟲，乙個僧人，乙個程式猿，只有寫了典型使用者之後，才能越來越清楚那些使用者究竟需要什麼功能。比如，窮人家的孩子必定精打細算，小公尺蟲（富二代）無所謂花錢的多少，僧人根本不看重錢，程式猿沒有意識去精打細算。不斷的琢磨，發現，小公尺蟲和僧人和那些沒有理財意識的人是不需要我們的記賬軟體的。需要我們軟體的，更多的是精打細算的人和那些不會合理分配金錢的人（月初有錢，月末沒錢的人）。接下來是場景分析，一開始是不太理解場景分析這個詞的，後仔細想想，也是挺好理解的。比如，用**之後會看看支付寶，出去買東西習慣性的看看支付寶，沒錢的時候看看這個月究竟怎麼花的錢，也看看支付寶。這些就是使用者場景了。
乙個軟體做的差不多，等待的就是使用者評價，在使用者評價之前有個使用者體驗。使用者體驗，即軟體留給使用者的感受和體驗。而我們做軟體的便需要再編寫的過程中考慮到可能會出現的問題和後果。至少可以考慮到前面講的目標使用者和盡可能為使用者考慮減少使用者點選的次數等各類小細節。其中最重要的是，人性化的軟體一定要注意的就是始終記住使用者的選擇！這個典型的例子就是上課所講的某銀行傳送給外國人的簡訊是中文的。同時，我們要讓使用者知道我們的軟體是越用越好用的，不然，使用者則會「擇良木二棲」。最最重要的是，我們不能讓使用者犯最簡單的錯誤，對於這一點，我深有體會，有的軟體確認和取消位置與我習慣的完全不同，每次都會讓我打了半天的資料「不翼而飛」，從此之後，不再用這款軟體，要我改掉乙個習慣已久的動作真的好難，至少比學習乙個新的軟體的使用方法要難多了！
這篇讀書筆記應該是近期最後一篇關於《構建之法》的閱讀筆記了。現在回想一下，軟體工程概論，或者說這本書，教給我們的更多的是方法，軟體怎麼做，做什麼，除了程式設計，我們還應該會的是什麼，有哪些方法是值得學習的，有哪些彎路是需要我們不應該走的。相比大道至簡，這本書，這門課，教的是更為具體的方法。
《構建之法》閱讀筆記06
最近我們要開始進行團隊合作，所以重點閱讀了 構建之法 與團隊合作有關的部分。首先團隊合作有很多模式，我們應該確立我們的模式，這樣才能更好的分配任務，並且對團隊的每個成員利益最大化。我覺得我們的團隊更像是交響樂團模式，大家都有各自的有點，但是更要跟隨指揮的節奏，這樣才能把曲目演奏好，同樣的，我們的團隊...
構建之法閱讀筆記06
夢斷 06 程式設計師常依賴一種稱為 媽媽測試 的手段，以對計算機一無所知的父母為假象用例，有時甚至請這類使用者親自體驗。這是現在程式設計師的通病，做出來的軟體或許在計算機上是完美無誤的程式，甚至是最優化做快的演算法，但是使用者的體驗和反饋卻並不是很好，這就要考慮到軟體設計的問題了，良好的軟體設計像...
《構建之法》閱讀筆記06
最近我們要開始進行團隊合作，所以重點閱讀了 構建之法 與團隊合作有關的部分。首先團隊合作有很多模式，我們應該確立我們的模式，這樣才能更好的分配任務，並且對團隊的每個成員利益最大化。我覺得我們的團隊更像是交響樂團模式，大家都有各自的有點，但是更要跟隨指揮的節奏，這樣才能把曲目演奏好，同樣的，我們的團隊...