軟體設計與實現過程中，著實有這麼一句話：在理論上，理論和實踐是一回事；在實踐上，理論與實踐卻是兩回事。若是只是在理論階段討論著實踐，就永遠不知道想象中的目標實現難度與實際的目標實現難度差距有多麼的大。這在課程結對程式設計中有所體現，也感觸頗深，動手前將設計思路商量地基本完美，大多會遇到的問題也都通通解決，然而到了實現環節就出問題了，發現原來之前商量的方法並不可行，還有很多突發的問題沒有考慮到……所以，有的程式可以「一拍」即得，有的不行。
構建是軟體開發的基石。
程式不能避免的會有很多bug，所以才會有測試人員這一必不可少的角色。之前提到的**覆蓋率測試，就是測試方法的一種，但是100%的**被執行了也並不代表不用再寫新的測試用例了。於此同時我認為做好錯誤報告是非常重要的。
以前團隊合作時會說：「等你做好了…我才能做…啊！不然怎麼…」，我們會把乙個工作的兩個部分在時間上分開來完成，結果可能沒那麼可觀。
後來我意識到這種想法是非常幼稚和有害的，和認為工程師只能等著設計師的線框圖才能開始工作同樣幼稚。
我學到認識問題要全面，不能以偏概全，站在問題外面看問題會有不一樣的解決之道。
構建之法閱讀筆記05
時隔多日，自己又重拾 構建之法 今天對需求分析這部分進行了閱讀。當我們程式設計師在編寫軟體之前要做的就是了解使用者的需求，準確而全面地找到需求主要有以下幾個步驟 1 獲取和引導需求 elicitation 我們需要找到軟體的利益相關者，了解和挖掘他們對軟體的需求，引導他們表達出對軟體的需求。很多時候...
構建之法閱讀筆記05
本次閱讀了第十三 軟體測試 十四章 質量保障 在軟體發布前基本沒有進行測試，直到上台講述的之前的一段時間才發現了一些問題，甚是著急 第十三章中excel計算1900閏年錯誤的例子給了我乙個全新的概念 要服務於最主要的功能.傳說中的拐點 小飛 我聽說在軟體專案中，有這樣乙個拐點存在 在這一點之前，新的...
構建之法閱讀筆記05
這是構建之法的最後一篇閱讀筆記 這幾天主要閱讀了it的創新這一章，創新在現代的社會中是乙個被說爛了的詞語，各行各業都在提倡創新，就連學校裡也在提倡什麼創新創業大賽 在 構建之法 的創新迷思一節，列舉出了七個迷思，接下來分別作出乙個簡要的概述。迷思之一 偉大的創新總是靈光一現。迷思之二 大家都喜歡創新...