第15章 穩定和發布階段
這個章節是程式準備誕生的準備階段，最後的包裝和測試要在這個階段內完成
軟體團隊的各個角色代表組成了會診小組，處理每乙個影響產品發布的問題。
must——必須修復，缺陷很嚴重，修復方案可行，相關的測試都通過。
第16章 it行業的創新
提出來幾點軟體的謎題：要成為領域的專家，才能創新？
要及時找到創新的時機，創新的招數、創新和作坊
創新, 創新型人才, 創新型企業, 創新型國家, 這些都是最近時髦的詞彙, 我在微軟亞洲研究院創新工程組工作, 看過創新的豬跑, 也吃過創新的豬肉, 在這裡和同學們分享一下我的體會。 這些內容好多可以從各種參考書中得到，並不是我獨創的見解。 迷思之一 innovation starts with epiphany很多人聽到發明創造, 都會想起故事書裡的聰明人忽然靈光閃現 的故事， 靈光閃現, 頓悟這個詞叫 「epiphany」, 這些著名的例子有:阿基公尺德在洗浴城裡泡澡, 忽然跳出浴池, 跑到大街上, 大喊 「eureka」, 他老人家發現了浮力定律。牛頓同學當年沒事坐在蘋果樹下, 忽然一顆蘋果砸到他頭上, 他也靈機一動, 揭示了萬有引力等等理論。所以現在社會一般創新的東西比較吃香點。
第17章 人，績效和職業道德
能動手去開發當然對於我們來說是一件好事，但如果因為自己的開發而損害了他人的利益，就不太好了，乙個好的軟體是為了幫助自己，不能以損害別人為代價。選取最近it 界發生的一些事件，對照軟體工程師職業道德的條款， 評價當事人的軟體工程師職業道德如何。這從職業道德來說是毫無職業道德可言，是從業人員對這個行業的不尊重，也是給自己的人品抹黑，應該有相應的法律條款來制裁和懲罰。
所經歷的痛苦，可以用更形式化的方法，或者"最佳實踐"得以解決。這比你自己另搞一套，閉門苦苦鑽研十年，一抬頭發現古人早完成了要好得多。沒有先前的經驗，固然不會讓我體驗這麼深刻，如果沒有讀到前人的總結，我們就不過是一次次重複失敗而已。
《構建之法》閱讀筆記06
最近我們要開始進行團隊合作，所以重點閱讀了 構建之法 與團隊合作有關的部分。首先團隊合作有很多模式，我們應該確立我們的模式，這樣才能更好的分配任務，並且對團隊的每個成員利益最大化。我覺得我們的團隊更像是交響樂團模式，大家都有各自的有點，但是更要跟隨指揮的節奏，這樣才能把曲目演奏好，同樣的，我們的團隊...
構建之法閱讀筆記06
夢斷 06 程式設計師常依賴一種稱為 媽媽測試 的手段，以對計算機一無所知的父母為假象用例，有時甚至請這類使用者親自體驗。這是現在程式設計師的通病，做出來的軟體或許在計算機上是完美無誤的程式，甚至是最優化做快的演算法，但是使用者的體驗和反饋卻並不是很好，這就要考慮到軟體設計的問題了，良好的軟體設計像...
《構建之法》閱讀筆記06
最近我們要開始進行團隊合作，所以重點閱讀了 構建之法 與團隊合作有關的部分。首先團隊合作有很多模式，我們應該確立我們的模式，這樣才能更好的分配任務，並且對團隊的每個成員利益最大化。我覺得我們的團隊更像是交響樂團模式，大家都有各自的有點，但是更要跟隨指揮的節奏，這樣才能把曲目演奏好，同樣的，我們的團隊...