軟工網絡15我的閱讀做業2（201521123007譚燕）

提出問題

快速通讀教材《構建之法》，並參照提問模板，提出5個問題。
如何提出有價值的問題？ 請看這個文章：http://www.cnblogs.com/rocedu/p/5167941.html ，以及 在互聯網時代如何提問題。 還有這些要點：

• 在每一個問題後面，請說明哪一章節的什麼內容引發了你的提問，提供一些上下文
• 列出一些事例或資料，支持你的提問。
• 說說你提問題的緣由，你說由於本身的假設和書中的不一樣而提問，仍是不懂書中的術語，仍是對推理過程有疑問，仍是書中的描述和你的經驗（直接經驗或間接經驗）矛盾？
  一個模板能夠是這樣：

我看了這一段文字 （引用文字），有這個問題（提出問題）。 我查了資料，有這些說法（引用說法），根據個人實踐，我獲得這些經驗（描述本身的經驗）。 可是我仍是不太懂，個人困惑是（說明困惑）。

或者這樣：

我反對做者的觀點（提出做者的觀點，本身的觀點，以及理由）。

大學生應該能寫出本身的思考， 而不是摘抄書本內容。

提示：編程經驗很少的同窗，建議看16章 「創新」， 提出本身的問題。

---

讀《構建之法》的的問題：

Q1：在《第3章 軟件工程師的成長》中第P49頁提到：

初級軟件工程師如何成長呢？我認爲有下面集中成長。
3.對通用的軟件設計思想和軟件工程思想的理解。
這一方面就比較虛，什麼是好的軟件設計思想？什麼是好的軟件工程思想？一個工程師開了博客，轉發了不少別人的文章，這算有思想嗎？另外一個工程師堅持作任何設計都要畫UML圖，這算有思想嗎？

可是沒有說明做者認爲的好的軟件設計思想和軟件工程思想究竟是什麼。我網上百度了一下，有人提到：
IBM 提出了軟件開發思想的4項要點——迭代開發、以系統架構爲中心、持續的質量保證以及管理變動和資產。

  這四項要點稍微理解一下就是說，迭代開發，開發工做能夠在需求被完整地肯定以前啓動，並在一次迭代中完成系統的一部分功能或業務邏輯的開發工做。再經過客戶的反饋來細化需求，並開始新一輪的迭代。優勢是能夠下降風險，獲得早期用戶反饋，持續的測試和集成，使用變動，提升複用性。以架構設計爲中心，體現設計爲重的思想。持續集成、持續構建、全程測試，有效的持續改進過程，驗證和確認缺一不可，質量保證和測試融爲一體。圍繞項目管理開展工做，包括風險預防、里程碑控制和關鍵路徑法等。
  書中提到的還有兩個反問，我認爲第一個問題的答案是一個工程師開博客卻只是轉發別人的文章，這樣的工程師沒有本身的思想，他只是別人思想的傳播者。第二個問題我認爲這個工程師作任何設計都畫UML圖，是一個有思想的人。

Q2：在《第4章 兩人合做》中P85頁提到：

在結對編程中，由於有隨時的複審和交流，程序各方面的質量取決於一對程序員中各方面水平較高的那一位。這樣，程序中的錯誤就會少得多，程序的初始質量會高不少，這樣會省下不少之後修改、測試的時間。

  我認爲，上面提到的結對編程的好處是創建在結對編程的雙方水平相差不大的基礎上。若是結對雙方的水平相差太大，則編程工做會極大地推向能力高的那位，另外一位可能不只跟不上他的編程進度，可能還沒法完成複審的工做，這樣結對編程將毫無心義。有時候工做中結對編程對象沒法更改且一方水平實在有限，這時候該怎麼辦呢？在學習過程當中也可能出現這樣的狀況，老師讓學生結對編程，關係好的兩個同窗結對了，一個能力很強而另外一個不好，水平高的那個同窗不忍放棄水平差的同窗，這時候要怎麼辦呢？

Q3：在《第7章 實戰中的軟件工程》中P136頁提到：

在一個高效的團隊中，全部成員都應該能獲得充分的受權，他們有權在職權範圍內按照本身的承諾完成任務，同時，他們也充分信任其餘同事能實現各自的承諾。

  充分受權後，每一個人都是按照本身的時間完成任務，那麼假如一我的的任務是要在另外一我的的任務完成後才能開始，且若是按照那我的本身的時間，這個任務會比較遲完成，這時該怎麼辦呢？另外充分受權以後，好像無需領導的存在，由於團隊中每一個人都有本身的角色，完成本身的任務且徹底相信其餘人能很好的完成任務，這時領導就是開會？

Q4：在《第16章 IT行業的創新》中P347頁提到：

不但大衆不喜歡創新，甚至連創新者本身都不例外，有些創新者甚至恨創新。

  這段話的小標題叫作「迷思之二：你們都喜歡創新」，但是看徹底篇，都是在說你們都不喜歡創新，若是都不喜歡創新，那爲何還有那麼多人在堅持着創新呢？

肩負鼓勵創新責任的科學期刊審稿人都未必真的鼓勵創新。

  人們討厭顛覆式創新，但是卻能接受創建在前人基礎上的「線性擴展」，若是是這樣咱們只能被迫選擇「創新」？或者不創新？

Q5：在《第15章 穩定和發佈階段》中P329頁提到：

全部軟件公司都但願在修正全部的缺陷以後才發佈軟件。可是，第一，什麼叫「缺陷」？若是隻是一些無關大局的問題，用戶能夠繞過去的，咱們非得立刻解決麼？第二，什麼叫「改正」？若是修正方案中又有「缺陷」怎麼辦？作商用軟件的人都在爲此苦惱，只有優秀的軟件公司能找到一個平衡點，及時發佈可以解決用戶問題的軟件，而且能及時修改軟件中的問題——注意，這兩個「及時」並不必定是同一時間。

  若是在正式發佈以前發現很嚴重的缺陷，還要按計劃發佈軟件嗎？文中又舉了蘋果公司的一個例子說明就算世界著名公司發佈的軟件都不是最完美的，但仍是發佈了軟件，是說就算有缺陷仍是要發佈軟件嗎？發佈過程當中會刻意避免缺陷嗎，就算這個缺陷關係了用戶需求？