軟工網絡15我的做業4——alpha階段我的總結

軟工網絡15我的做業4——alpha階段我的總結

1、我的總結

在alpha 結束以後， 每位同窗寫一篇我的博客， 總結本身的alpha 過程；
請用自我評價表：http://www.cnblogs.com/xinz/p/3852177.html 有比較纔會有進步。

---

第一部分：硬的問題

類型	具體技能和麪試問題	如今的回答（目前大三）
語言	拿手的語言（偏web前端，PC/Mobile App）	Javascript
語言	拿手的計算機語言（偏後端，數據處理，網站後臺，機器學習等）	JAVA 和 c語言
軟件實現	（閱讀代碼的能力，實現，單元測試）有沒有在別人的代碼基礎上進行改進，你是怎麼讀懂別人的代碼，你採起什麼方法不影響原來的功能，遇到的bug是什麼，怎麼解決，bug出現的緣由	有，看變量名、類名。bug、通常多是變量是局部或者全局的問題，或者是算法描述有誤
軟件測試	（測試方法、測試工具、測試實踐、代碼覆蓋率）你如何測試本身的代碼？如何測試別人的代碼？掌握了多少種測試工具和方法？寫過測試工具麼？如何對一個網站進行壓力測試和效能測試？	使用一些測試工具如testcomplete，loadrunner對網站進行壓力測試
效能分析	（效能分析，效能改進）你寫過的最複雜的代碼是什麼？如何測量和改進他的效能的，用了什麼工具，如何分析的？	最複雜的就是記帳小程序，這是團隊的成果。
需求分析	（需求分析，典型用戶，場景，創新）你作過多少個有實際用戶的項目，用戶最多有多少？你的項目的創新之處？	記帳小程序， 目前是8個用戶
行業洞察力	你最感興趣的領域是什麼，這個領域過去十年有什麼創新？你分析過這個領域前十的產品嗎？請分析一下他們的優劣。你要進入這個領域，如何創新？	我就一直想作一個我微信小程序的快遞帶領功能，近幾年快遞物流火熱，本身領快遞很麻煩，創新就是將他與微信結合，擺脫其餘app
項目管理	你參加過項目管理嗎？請描述兩個當下流行的開發方法在你的項目中的具體應用狀況。如何決定各個任務的優先順序，有什麼理論支持你的作法？若是項目不能及時完成，有什麼辦法	我此次是作的記帳小程序的記帳頁面。先把頁面的大概結構設計好，而後針對一些按鈕進行功能代碼的編寫，針對各個功能模塊寫出各個方法模塊。後期調整顏色透明度
軟件設計	你作過架構設計、模塊化設計、接口設計嗎？請說明如下你爲什麼是這樣設計，你比較過什麼不一樣的設計方式，你的設計取得了什麼成果？	目前爲止尚未作過
質量意識	（代碼複審/代碼規範/代碼質量）你是怎麼作代碼複審的，你加入咱們團隊後，能幫咱們提升代碼質量嗎，請具體說怎麼提升？	代碼複審時候，我把他排版更清晰了，增長詳細的註釋，這是爲將來使用以及版本升級作鋪墊，方便之後改進
團隊協做	描述你在項目中如何說服同伴採起你更好的方案？或是聽取別人的意見改進本身的方案？如何說服懶惰的同伴加緊工做？	同伴懶惰或是玩手機，我會指出來，是的一直可愛的耿直girl，毫無技巧套路
理論素養	你上過什麼數學，計算機或是理論課，舉出具體的例子，如何幫你解決問題	高數，操做系統，計組，c語言，數據結構，java等，使用數據結構裏面學到的算法，利用離散數學的邏輯
自我管理	整年級你專業排名多少？你從剛入學（大一）到如今排名有變化嗎？如何解釋這種變化？	從第6名到30名，主要是大一的時候高數和其餘基礎課比較好。大三明顯感受有些吃力，雖然也很努力，但競爭激烈啊

---

第二部分：軟的問題，在成長路上學到了什麼？

工程師的能力和成長路徑都有多種選擇，沒有必定之規。IT 行業變化也很快，例如 Swift 語言剛出來兩年的時候， 一些招聘廣告上就要求 「有 3 年以上 Swift 實際開發經驗」， 那麼，一個寫了 5 年 C++，學了三個月最新版本Swift 語言的工程師能算夠格麼？ 除了每一門具體的語言和工具， 工程師在行業中不斷磨練，和各類人合做，參與了各種開發活動，一個優秀工程師是否會培養出獨立於具體語言的 「工程師能力」？ 若是一個項目領導帶領團隊作了幾年的項目，團隊中的工程師用各類編程語言解決具體問題， 他和不作領導的工程師相比有什麼特別的能力？他在每個具體的編程語言上可能都不如某個工程師， 那他的獨特價值是什麼？
咱們把這些叫作 Soft Skill， 軟的能力。
不少時候，咱們但願得到一些能夠跨專業衡量和交換的數字，這樣便於比較，因此下面的的每項回答均可以換算爲一個分數， 以知足部分讀者的需求：

1.D
保持高標準，不要受制於破窗理論(broken windows theory)[i]。
當你看到不靠譜的設計、糟糕的代碼、過期的文檔和測試用例的時候，不要想 「既然別人的代碼已經這樣了，個人代碼也能夠隨便一點啦。」
a) 歷來沒據說過； b) 我就是這樣隨便過來的； c) 若是有明確要求，我能夠作好。 d) 一直主動這樣作 e) 不但主動作， 還會影響同事一塊兒作好
2.D
主動解決問題。當看到不靠譜的設計，糟糕的代碼的時候，不要想「可能別人會來管這個事情」 ，或者「我下個月發一個郵件讓你們討論一下」。要主動地把問題給解決了[ii]。

a) 不懂啥是靠譜的設計； b) 隨便應付一下便可； c) 若是有明確要求，我能夠作好。 d) 一直主動這樣作 e) 不但主動作， 還會影響同事一塊兒作好

1. D
   常常給本身充電，身體訓練是運動員生活的一部分，學習是軟件工程師職業的伴侶。每半年就要了解和學習一些新的相關技術。經過按期分享（面對面的分享，寫技術博客等）來確保本身真正掌握了新技術。 a) 歷來不看書； b) 看了就忘； c) 有時分享。 d) 一直主動這樣作 e) 不但主動作， 還會影響同事一塊兒作好
2. C
   DRY （Don't RepeatYourself）——別重複。在一個系統中，每個知識點都應該有一個無異議的、正規的表現形式。 a) 歷來沒據說過； b) 據說過，可是認爲意思不大； c) 這要講場合。 d) 一直主動這樣作 e) 不但主動作， 還會影響同事一塊兒作好
3. E
   消除不相關模塊之間的影響，在設計模塊的時候，要讓它們目標明確並單一，能獨立存在，沒有不明確的外部依賴。 a) 歷來沒據說過； b) 出了問題再說吧； c) 想作，可是不知道怎麼衡量效果。 d) 可以在多種語言和架構中作到 e) 不但主動作， 還會影響同事一塊兒作好
4. D
   經過快速原型來學習，快速原型的目的是學習，它的價值不在於代碼，而在於你經過快速原型學到了什麼。 a) 歷來沒據說過； b) 把原型直接用於產品，否則就浪費了； c) 不用原型，一直在產品中直接改。 d) 一直主動這樣作 e) 不但主動作， 還會影響同事一塊兒作好
   7.D
   設計要接近問題領域，在設計的時候，要接近你目標用戶的語言和環境。 a) 歷來沒據說過； b) 按個人想法設計，用戶之後會適應的； c) 大概贊成，可是怎麼接近用戶呢？ d) 一直主動這樣作 e) 不但主動作， 還會影響同事一塊兒作好
   8.C
   估計任務所花費的時間，避免意外。在開始工做的時候，要作出時間和潛在影響的估計，並通告相關人士，避免最後關頭意外發生。工做中要告知可能的時間變化，過後要總結。 a) 作完了，就知道花費了，不用事先估計； b) 大概估一下，沒必要在乎時間 c) 若是有明確要求，我能夠作好。 d) 一直主動這樣作 e) 不但主動作， 還會影響同事一塊兒作好
   9.C
   圖形界面的工具備它的長處，可是不要忘了命令行工具也能夠發揮很高的效率，特別是能夠用腳本構建各類組合命令的時候。 a) 一直用鼠標和GUI； b) 到時候問牛人； c) 正在學習命令行工具。 d) 一直主動這樣作 e) 不但主動作， 還會影響同事一塊兒作好
5. E
   有不少代碼編輯器，請把其中一個用得很是熟練。讓編輯器能夠實現本身的定製，能夠用腳本驅動，用起來駕輕就熟。

a) 只用老師教的一個； b) 隨意； c) 沒有任何定製。 d) 會定製，而且分享給其餘人 e) 還會學習和使用各類編輯器的擴展。
11.C
理解經常使用的設計模式，並知道擇機而用。設計模式不錯，更重要的是知道它的目的是什麼，何時用，何時不用。

a) 歷來沒據說過； b) 模式沒用； c) 每寫100行程序，我就儘可能用一個模式。 d)有實際使用的經驗 e) 能用具體代碼說明模式的利弊

1. C
   代碼版本管理工具是你代碼的保障，重要的代碼必定要有代碼版本管理。

a) 歷來沒據說過； b) 用QQ，u盤便可； c) 領導要求才用。 d) 常常用 e) 不但主動作， 還會影響同事一塊兒作好

1. D
   在debug的時候，不要驚慌，想一想致使問題的緣由可能在哪裏。一步一步地找到緣由。要在實踐中運用工具，善於分析日誌（log），從中找到bug。同時，在本身的代碼裏面加 log.

a) 歷來沒據說過； b) 只會printf； c) 加log 太麻煩，個人代碼不會有bug 的。 d) 一直主動這樣作 e) 不但主動作， 還會影響同事一塊兒作好

1. D
   重要的接口要用形式化的「合同」來規定。用文檔和斷言、自動化測試等工具來保證代碼的確按照合同來作事，很少也很多。使用斷言 (assertion) 或者其餘技術來驗證代碼中的假設，你認爲不可能發生的事情在現實世界中每每會發生。

a) 歷來沒據說過； b) 太麻煩，不用； c) 想用，但沒有時間。 d) 一直主動這樣作 e) 不但主動作， 還會影響同事一塊兒作好

1. C
   只在異常的狀況下才使用異常 (Exception), 不加判斷地過多使用異常，會下降代碼的效率和可維護性。記住不要用異常來傳遞正常的信息。

a) 歷來沒據說過； b) 抓住全部異常 c) 若是有明確要求，我能夠作好。 d) 一直主動這樣作 e) 不但主動作， 還會影響同事一塊兒作好
16.D
有始有終。若是某個函數申請了空間或其餘資源，這個函數負責釋放這些資源。

a) 歷來沒據說過； b) 隨緣； c) 有時這樣作。 d) 一直主動這樣作 e) 不但主動作， 還會影響同事一塊兒作好
17.E
當你的軟件有多種技術結合在一塊兒的時候，要採用鬆耦合的配置模式，而不是要把全部代碼都混到一塊兒。

a) 歷來沒據說過； b) 沒有實踐的機會； c) 代碼都在一塊兒比較好管理。 d) 一直主動這樣作 e) 不但主動作， 還會影響同事一塊兒作好

1. C
   把經常使用模塊的功能打形成獨立的服務，經過良好的界面 (API) 來調用不一樣的服務。

a) 歷來沒據說過； b) 拷貝代碼過來用也能夠 c) 若是有明確要求，我能夠作好。 d) 一直主動這樣作 e) 不但主動作， 還會影響同事一塊兒作好

1. D
   在設計中考慮對並行的支持，這樣你的API 設計會比較容易擴展。

a) 歷來沒據說過； b) 並行不會出錯的； c) 任何代碼都應支持並行。 d) 考慮在適當的層次支持並行 e) 不但主動作， 還會影響同事一塊兒作好

1. E
   在設計中把展示模塊 (View) 和實體模塊 (Model) 分開，這樣你的設計會更有靈活性。

a) 代碼都在一塊兒比較好改； b) 隨緣啦； c) 沒搞清楚啥是V，啥是M。 d) 一直主動這樣作 e) 不但主動作， 還會影響同事一塊兒作好

1. C
   重視算法的效率，在開始寫以前就要估計好算法的效率是哪個數量級上的（big-O）。

a) 歷來沒據說過； b) 個人數據量不大，無所謂； c) 不會有效率問題的，如今CPU 都快了。 d) 主動測試程序效率，以驗證估算 e) 不但主動作， 還會影響同事一塊兒作好

1. D
   在實際的運行場景中測試你的算法，不要停留在數學分析層面。有時候一個小小的實際因素 (是否支持大小寫敏感的排序，數據是否支持多語言)會致使算法效率的巨大變化。

a) 歷來沒據說過； b) 想用，但不知道工具 c) 主要靠肉眼觀察算法效率。 d) 一直主動這樣作 e) 不但主動作， 還會影響同事一塊兒作好
23.D
常常重構代碼，同時注意要解決問題的根源。

a) 歷來沒據說過； b) 任何修改均可以叫重構； c) 天天應該重構兩次。 d) 一直主動這樣作 e) 不但主動作， 還會影響同事一塊兒作好
24.C
在開始設計的時候就要考慮如何測試 ，若是代碼出了問題，有log 來輔助debug 麼? 儘早測試，常常測試，爭取實現自動化測試，爭取每個構建的版本都能有某些自動測試。

a) 歷來沒據說過； b) 個人代碼不會出問題的； c) 項目沒有安排時間，我也沒有提這事。 d) 一直主動這樣作 e) 不但主動作， 還會影響同事一塊兒作好
25.D
代碼生成工具能夠生成一堆一堆的代碼，在正式使用它們以前，要確保你能理解它們，而且必要的時候能debug 這些代碼。

a) 歷來沒據說過； b) 歷來不看那些代碼； c) 那些代碼沒有bug。 d) 一直主動這樣作 e) 不但主動作， 還會影響同事一塊兒作好
26.E
和一個實際的用戶一塊兒使用軟件，得到第一手反饋。

a) 歷來沒據說過； b) 用戶太蠢，不值得聽反饋； c) 想作可是沒有機會。 d) 一直主動這樣作 e) 不但主動作， 還會影響同事一塊兒作好
27.C
在自動測試的時候，要有意引地入bug，來保證自動測試的確能捕獲這些錯誤。

a) 沒據說過； b) 沒必要這麼麻煩； c) 若是有明確要求，我能夠作好。 d) 一直主動這樣作 e) 不但主動作， 還會影響同事一塊兒作好
28.D
若是測試沒有作完，那麼開發也沒有作完。

a) 歷來沒據說過； b) 簽入代碼，就是作完了； c) 。 d) 一直主動這樣作 e) 不但主動作， 還會影響同事一塊兒作好
29.D
適當地追求代碼覆蓋率：每一行的代碼都覆蓋了，可是程序未必正確。要確保程序覆蓋了不一樣的程序狀態和各類組合條件。

a) 歷來沒據說過； b) 覆蓋20% 就行了； c) 要覆蓋至少60%。 d) 一直主動這樣作 e) 不但主動作， 還會影響同事一塊兒作好
30.D
若是團隊成員碰到了一個有廣泛意義的bug, 應該創建一個測試用例抓住之後將會出現的相似的bug。

a) 歷來沒據說過； b) 每一個bug都是特殊的； c) 測試用例不值得加 d) 一直主動這樣作 e) 不但主動作， 還會影響同事一塊兒作好
31.C
測試：多走一步，多考慮一層。若是程序運行了一星期不退出，若是用戶的屏幕分辨率再提升一個檔次，這個程序會出什麼可能的錯誤?

a) 歷來沒據說過； b) 若是有問題，用戶會報告的，咱們不用測這些； c) 若是有明確要求，我能夠作好。 d) 一直主動這樣作 e) 不但主動作， 還會影響同事一塊兒作好
32.D
（帶領團隊）瞭解用戶的指望值，稍稍超出用戶的指望值，讓用戶有驚喜。
a) 歷來沒據說過； b) 咱們決定用戶的指望； c) 若是有明確要求，我能夠作好。 d) 一直主動這樣作 e) 不但主動作， 還會影響同事一塊兒作好
33.B
（帶領團隊） 不要停留在被動地收集需求，要挖掘需求。真正的需求可能被過期的假設、對用戶的誤解或其餘因素所遮擋。

a) 歷來沒據說過； b) 用戶不說的，咱們不作； c) 若是有明確要求，我能夠作好。 d) 一直主動這樣作 e) 不但主動作， 還會影響同事一塊兒作好

1. E
   （帶領團隊）把全部的術語和項目相關的名詞、縮寫等都放在一個地方。

a) 歷來沒據說過； b) 都記在我腦子裏； c) 你們看代碼就好 d) 一直主動這樣作 e) 不但主動作， 還會影響同事一塊兒作好

1. E
   （帶領團隊）不要依賴於某我的的手動操做，而是要把這些操做都作成有相關權限的人士都能運行的腳本。這樣就不會出現由於某人休假而項目被卡住的狀況。

a) 歷來沒據說過； b) 咱們沒有休假的，不要緊； c) 出了問題再說 d) 一直主動這樣作 e) 不但主動作， 還會影響同事一塊兒作好
36.E
（帶領團隊）要讓重用變得更容易。一個軟件團隊要創造一種環境，讓你們有輕鬆的心態來嘗試各類想法 （例如，模塊的重用，效能的提高，等）。

a) 都聽領導的； b) 團隊嚴肅緊張最好； c) 沒必要嘗試，失敗的可能性太大。 d) 一直主動這樣作 e) 不但主動作， 還會影響同事一塊兒作好
37.E
（帶領團隊）在每一次迭代以後，都要總結經驗，讓下一次迭代的進度安排更可靠，質量更高。
a) 沒有時間總結，直接作下一版； b) 總結用處不大； c) 若是上級有要求，就作一下； d) 一直主動這樣作 e) 不但主動作， 還會影響同事一塊兒作好
38.E
（帶領團隊）團隊中每每會有矛盾產生，做爲領頭人，怎麼辦？
a) 我沒看見矛盾。 b) 和稀泥，過得去就行 ； c) 若是沒有捅到上級那裏，就打哈哈，但願他們本身搞定； d) 有明確和一致的處理矛盾的原則 e) 不但有明確和一致的處理原則，並且對於影響團隊士氣的任何事情追究到底

---

2、回答問題

咱們在課程開始之初，曾經要求你們針對軟件工程提出問題：我的閱讀做業2，那麼在通過alpha階段，你們是否對軟件工程有了必定的瞭解？請結合本身提出的問題進行回答

Question 1:

軟件工程師的能力衡量

P45
原文:每一個人的工做質量直接影響最終軟件的質量。那麼,軟件工程師如何衡量、證實本身的能力?
問:你是職業軟件工程師麼?
問:你以爲你「職業」到哪個程度?
答:嗯,我在一個能發工資的地方上班,靠個人軟件技術掙錢,因此我至關的職業。
問:像職業籃球隊員那樣職業?
答:差很少吧。
問:職業籃球隊員都有很詳細的記錄說明,例如,圖3-1所示的表格說明了一個職業籃球
隊2010賽季隊員們的場上表現。

圖表顯示了隊員出場次數、場上時間、命中率、籃板、助攻、搶斷、蓋帽、失誤、犯規、得分、罰球命中率等。做爲一個職業軟件工程師,你有相似的數聽說明你全部的職業活動和成績麼?
答:嗯……沒有。惟一的數據是,個人「上場時間」仍是挺長的,並且常常打加時賽一加班。
什麼樣的數據能說明一個軟件工程師的技術和能力呢?衡量能力有哪些參數?沒有量化的指標,就談不上衡量和比較。咱們仍是看看搬磚的夥計們,關於工做量:
有多少塊磚?
要搬多遠?

我的思考看法:

• 如何衡量軟件工程師能力?能力分爲不少種，其中技術上的能力以及團隊協做的能力都相當重要。
• 技術上的能力是決定一我的可以在這個領域是否能夠有立足之地。
• 而團隊協做的能力倒是集合所有智慧以後最完美的成果。團隊的優秀會讓你走的更遠，保質期更長。
• 不過我以爲衡量一個軟件工程師的能力遠遠不只於此，他要保持源源不斷的求知的慾望以及創新能力，才能使本身永葆青春，不至於被新生力量所取代。

---

Question 2:

絞刑架和職業發展

P68
原文：
移山公司的人力資源總監給同窗們作了職業發展的演講,大意是隨着軟件工具和軟件工程理論
的發展,開發軟件將會愈來愈容易,軟件企業的水平都是CMM14級以上。軟件白領的生活指
日可待,金領也不是夢,你們前途無可限量,學軟件工程的同窗愈來愈多,就是明證。你們紛
紛鼓掌。最後他分享了一個故事
兩個劫匪在亡命的路上看到一副絞刑架,劫匪小弟說,大哥,若是這世界上沒有絞
刑架,我們的職業就好乾多了。大哥說:你真笨!若是沒有了它,這世上作劫匪的
人怕是太多,我倆恐怕競爭不過同行,早就餓死了

我的思考看法:

• 這個故事對我的及軟件業發展的啓示實際是暗示着：現在是互聯網的時代，雖說軟件工程的形勢大好，不過目前競爭的人數逐年增多，咱們的壓力也隨之增大。
• 但我以爲，這並不可怕，合做與競爭都會促進社會的發展與自個人成熟。真正優秀的人是不害怕競爭的，由於不管「市場」這個分母有多大，他均可以汲取，去獲取的一切可能有助於提升本身的知識，見賢思齊，見不賢而內自省也。
• 所以，他只會愈來愈完美。薪水天然也會愈來愈多。
• 我以爲思考的角度不該該是考慮就業人數增多的問題。由於那不是問題的本質。何況，任何人也解決不了。咱們應該從提升自我着手，千方百計有本身的一技之長，並不斷完善那個技能，從而讓任何人沒法取代。
• That is the crux of the matter!

---

Question 3:

充分受權和信任

原文：
這一點的關鍵是「受權」這個詞,受權( Empower)有兩個意思。
一是給某人權力和權威;二是給予某人更多自信和自尊。

我的思考看法:

• 在一個高效的團隊中,全部成員都應該能獲得充分的受權,他們有權在職權範圍內按照本身的承諾完成任務,同時,他們也充分信任其餘同事能實現各自的承諾。相似地,團隊的顧客(包括內部和外部的顧客)也認爲團隊能兌現承諾,並進行相應的 規劃。
• 給予某人更多自信和自尊，纔會讓團隊更能在一種輕鬆的氛圍下，充分發揮本身最大的潛力。這樣效率更高且團隊合做更愉快，隊員關係更和氣。

---

Question 4:

成功的團隊更能創新

P332
成功的企業要知足股東們巨大的指望值。
成功的公司有價值觀–––追逐利潤。
成功的公司有流程。
成功的公司重視用戶
成功的團隊有老大的內心。

我的思考看法:

• 不如說是成功的團隊更會思考。這個思考包括主觀思考和換位思考。
• 主觀思考就是主觀行動力。一個想要成爲行業領頭人的團隊，一定是敢於創新，勇於突破，挑戰自個人。與此同時，天然也會不斷摸索，尋找自我問題，並及時改正。
• 所謂換位思考，就是站在用戶的角度思考用戶須要一個什麼樣的利益優惠，才能在一個正確的方向，作好服務令客戶滿意。是共贏。

---

Question 5:

不太作廣告,主要靠口口相傳,容易被技術進步淘汰.

P353
原文：
這的確是傳統的做坊的一個劣勢,現現在有互聯網、 App Store、SNS,若是你的產品真的好,
不想讓別人知道也挺不容易的。
做坊會被技術進步拋下?之前看到一個電視節目採訪一位修鋼筆的小做坊,那位師傅能把銥金
筆尖的那一點小「銥金」給點上去。這個技藝連同那小做坊聽說已經快失傳了。可是不要緊
有不少大型的企業,也會被技術進步拋下的。就像小說《神鞭》講到的,若是落後的絕技沒有
太多用處了,那就練點新的絕技,人又不笨,小做坊掉頭快,好辦。有一種意見認爲做坊只能獨立存在,和其餘機構都合不來。其實否則,在龐大的企業內部,也有一些人構建了一個小做坊,本身作主,作本身感興趣的事,例如:肯·湯普遜(KenThompson)和丹尼斯·裏奇(Dennisritchie)在貝爾實驗室決定本身作一個新的操做系統Unix,兩我的找了一兩臺舊機器就開始作了。
這些好的做坊，都有這些核心特性「從小事作起,重質量，講信用,對產品負貢,對工做自豪。」

我的思考看法:

• 首先就電子產品領域來講，咱們一般會在電視上看到oppo,vivo,金立等等的手機會重金聘請某某明星代言。而卻鮮少見到華爲作廣告。
• 而實際上，華爲的銷量位居中國市場第一，遠超蘋果。這是爲何？是實力。是真正意義上的NumberOne。
• 而假期的時候我去萃華金店實習，更讓我對此有了更深的領悟。與周大生六福等珠寶品牌不一樣，萃華並無請巨星代言。並且靠「售後服務第一」這個特色口口相傳。其實，百年誠信，就是最好的廣告！
• 所以我以爲專一技術、專一公司自我完善管理，纔是真正的主流方向。廣告只是調味劑，他能夠有，但不該該成爲主流。而消費者自身也要保持清醒的頭腦，不該盲目跟風。不是選漂亮，而是選品質。

3、再提問題

同時，你們必定會在實踐過程當中產生更多問題， 結合你的讀書（教材，博客，參考書）， 實踐， 再提出關於軟件工程的 5 個問題。

在每一個問題後面，請說明哪一章節的什麼內容引發了你的提問，提供一些上下文。
列出一些事例或資料，支持你的提問 。
說說你提問題的緣由，你說由於本身的假設和書中的不一樣而提問，仍是不懂書中的術語，仍是對推理過程有疑問，仍是書中的描述和你的經驗（直接經驗或間接經驗）矛盾？
一個模板能夠是這樣：
我看了這一段文字 （引用文字），有這個問題 （提出問題）。 我查了資料，有這些說法（引用說法），根據個人實踐，我獲得這些經驗（描述本身的經驗）。 可是我仍是不太懂，個人困惑是（說明困惑）。【或者】我反對做者的觀點（提出做者的觀點，本身的觀點，以及理由）。

Q1：關於團隊運做問題

alpha階段以後，咱們雖然大致完成了，但是咱們發現其實仍是存在許多問題。好比說某些組員能力不是很強，作的很少，這時候須要如何去解決呢？組員之間是否要採起一些行動來維繫整個團隊的正常運做呢？該採起什麼樣的行動？

我查詢了一些資料，有些說法是換隊友。但是我以爲每一個人都有長處，咱們應該思考如何發揮那我的的價值，而不是換人。

Q2：書上關於PM問題

如何纔算是一個合格的PM？

我的以爲PM要懂得統籌，以及必定要具體分工，PM要看到每名隊員的優勢。發揮他們的長處。這是一個優秀的leader

Q3：在測試上,開發人員應該負責哪些測試?(單元測試、模塊測試、集成測試、Beta測試、在正式產品中測試）

一個程序從開始開發到交付使用，中間涉及了包括單元測試、集成測試、接口測試、性能測試等許多測試環節。其中由開發者完成的代碼級測試部分稱爲開發者測試。開發者測試包括：單元測試 、DevOps和測試前移、覆蓋率

Q4：關於軟件工程對於同窗們畢業設計的影響。

軟件工程對於畢業生目前正在進行的畢業設計有什麼影響？

許多網絡大三的學長學姐說，多虧了軟件工程，是他們在大三積累了不少的經驗，纔是他們在現階段的畢業設計中有更多的想法思路，以及積攢了能力。他們十分感激那時不放棄，堅持下去的本身。

Q5：書上12章用戶體驗的問題

個人問題是：若是你明知徹底按照用戶的要求去作，會有不足，而若是按本身的思路又會比計劃耗時耗力。那你還會不會去多作。前提是用戶不會多給報酬？
這個問題我也問了不少人，但說法千奇百怪。我我的目前也給不出更好的答案，不過必定會秉承誠實信用原則。
至於答案，我以爲仍是要等到真的有接手項目纔會有感同身受，那時我會有更成熟的答案。

---

【附加題】：請將問題提交至豆瓣：https://book.douban.com/subject/27069503/， 並在博客中給出連接
在豆瓣頁面的最下方 「讀書筆記」 那裏發言， 《構建之法》的做者會親自答覆問題
個人連接：
https://book.douban.com/annotation/56789664/
個人評論提交截圖：