標籤(空格分隔): 軟件工程html
快速通讀教材《構建之法》,並參照提問模板,提出5個問題。
如何提出有價值的問題? 請看這個文章:http://www.cnblogs.com/rocedu/p/5167941.html ,以及 在互聯網時代如何提問題。 還有這些要點:程序員
在每一個問題後面,請說明哪一章節的什麼內容引發了你的提問,提供一些上下文
列出一些事例或資料,支持你的提問。
說說你提問題的緣由,你說由於本身的假設和書中的不一樣而提問,仍是不懂書中的術語,仍是對推理過程有疑問,仍是書中的描述和你的經驗(直接經驗或間接經驗)矛盾?編程
相關知識點:
1.代碼覆蓋(Code coverage)是軟件測試中的一種度量,描述程式中源代碼被測試的比例和程度,所得比例稱爲代碼覆蓋率。(來自:百度百科)
2.單元測試(unit testing),是指對軟件中的最小可測試單元進行檢查和驗證。對於單元測試中單元的含義,通常來講,要根據實際狀況去斷定其具體含義,如C語言中單元指一個函數,Java裏單元指一個類,圖形化的軟件中能夠指一個窗口或一個菜單等。總的來講,單元就是人爲規定的最小的被測功能模塊。單元測試是在軟件開發過程當中要進行的最低級別的測試活動,軟件的獨立單元將在與程序的其餘部分相隔離的狀況下進行測試。
文中與問題相關的內容:
100%的代碼覆蓋率不等於100%的正確性!代碼覆蓋率對於「應該寫可是沒有寫的代碼」無能爲力。代碼中有效能問題,雖然代碼執行了,而且也正確返回了,可是代碼效率很是低。多線程環境中的同步問題。其餘與外部條件相關的問題網絡
其餘與外部條件相關的問題(例如與設備、網絡的相關問題),這些問題具體指什麼,以及如何用具體的方法來解決這些問題?多線程
文章內容以下:框架
在中國,軟件工程師的職業資格考試有:
計算機等級考試和全國計算機技術與軟件專業技術資格考試
基於筆者有限的經驗和觀察,此類考級有這樣的好處:
國家級認證,有必定的權威性和通用性
任何人均可以參與
也有這樣一些侷限性:
以答題、評分爲主要考試形式,沒有面對面的口試
考試中每一個人單獨行動,不能考量團隊的合做能力
要考慮到通用性和穩定性,考題和內容相對滯後於工業界的發展,部份內容至關滯後函數
由於我本人也將參加計算機等級考試和軟考,可是在備考過程當中,發現知識點的確有不少滯後和死板,可是不少公司和部門都還認可這是證書的價值性,公司是看中了同窗的學習能力仍是其餘緣由?還有國家的認證考試明明知道不少知識點滯後於工業界的發展,以及一些公司的認證考試都有題庫,他們爲何不嘗試改革和改進,真正地作到考察相關職業從事人員的能力?單元測試
相關知識點:學習
一、敏捷開發
敏捷開發以用戶的需求進化爲核心,採用迭代、按部就班的方法進行軟件開發。在敏捷開發中,軟件項目在構建初期被切分紅多個子項目,各個子項目的成果都通過測試,具有可視、可集成和可運行使用的特徵。換言之,就是把一個大項目分爲多個相互聯繫,但也可獨立運行的小項目,並分別完成,在此過程當中軟件一直處於可以使用狀態。
二、極限編程
極限編程(ExtremeProgramming,簡稱XP)是由KentBeck在1996年提出的。KentBeck在九十年代初期與WardCunningham共事時,就一直共同探索着新的軟件開發方法,但願能使軟件開發更加簡單而有效。Kent仔細地觀察和分析了各類簡化軟件開發的前提條件、可能性以及面臨的困難。1996年三月,Kent終於在爲DaimlerChrysler所作的一個項目中引入了新的軟件開發觀念——XP。適用於小團隊開發。
三、結對編程
結對編程技術是指兩位程序員坐在同一工做臺前開發軟件。與兩位程序員各自獨立工做相比,結對編程能編寫出質量更高的代碼。
實施結對編程技術將給軟件項目的開發工做帶來好處,只是這些好處必須通過縝密的思考和計劃才能真正體現出來。而另外一方面,兩個有經驗的人可能會發現配對編程裏沒有什麼技能的轉移,可是讓他們在不一樣的抽象層次解決同一個問題會讓他們更快地找到解決方案,並且錯誤更少。測試
文章內容以下:
既然代碼複審能力能發現這麼多問題,有這麼好的效果,若是咱們每時每刻都處在代碼複審的狀態,那不是很好嘛?事實上,極限編程正是這一思想的體現——那爲何不把一些卓有成就的開發方法用到極致,讓咱們無時不刻地使用它們?
經過查閱資料找到了相關名稱敏捷開發、極限編程和結對編程,那麼這三者的關係是什麼?
敏捷開發是十幾種開發方法的統稱,極限編程就是這十幾種開發方法之一。
極限編程包括了十幾種實踐(就是一些具體作法),結對編程是極限編程的一種實踐。(來自百度知道)
在《構建之法》初版第6章中出現如下問答內容:
問:敏捷宣言是否是軟件開發思想的頂峯?
答:敏捷宣言當然好,然而人的認識老是在發展,軟件行業也不斷地有新的思想出現,或者是舊的思想從新浮現。例如,2009年有人提出了軟件匠藝宣言。
請問具體的軟件匠藝宣言是什麼?以及與敏捷宣言的異同點?
在《構建之法》初版的16章,我看到了如下文章的內容:
那怎麼樣才能讓別人喜歡(至少不痛恨)你的創新?在咱們提出一個創新的想法時,應該考慮這麼幾點:
對利益相關人要講清楚「你能從中獲得什麼」。
創新的想法和目前流行的作法對比,有什麼相對優點,能讓別人清楚地看到這個區別,並可以嘗試。
創新和目前大衆習慣、已有系統是否兼容。
避免過分描述複雜的技術。
文章裏做者提問讀者,「你可否用簡明的方式把你的創新描述出來?能夠實踐一下本書「需求分析」裏講過的NABCD方法?」
查閱第八章需求分析內容:
N(Need,需求)、A(Approach,方法)、B(Benefit,好處)、C(Competitors,競爭)、D(Delivery,推廣)
看完以後,關於如何提出靠譜的項目仍是不太理解,後來百度之後搜到鄒欣老師的博客文章:
https://www.cnblogs.com/xinz/archive/2010/12/01/1893323.html
經過兩章的學習,瞭解了創新的提出,知足用戶的需求很重要。創新的東西不但要「新」,更重要的是利用本身的框架和判斷,更好地推廣它,使它的價值最大化。但是,我想問,在創新的路上,知足用戶的需求的創新仍是堅持一些顛覆性的創新哪一個對於如今的社會發展幫助比較大?是否是有必定資本的我的或者團隊,比較適合作後者這件事?可是通常有資本或者成功的我的或團隊,在書中你也提到有許多因素影響着他們創新,那在中國這個大環境下,是否是通常由國家來主導這些項目?那麼假如由國家來主導這些目前暫時看來收益不大的創新項目,有什麼優點又有什麼不足?雖然想得有點多,但願做者可以解答一下。
請將問題提交至豆瓣:https://book.douban.com/subject/27069503/, 並在博客中給出連接在豆瓣頁面的最下方 「讀書筆記」 那裏發言,《構建之法》的做者會親自答覆問題。
連接:https://book.douban.com/annotation/54360971/