個人作業——軟體工程實踐總結作業

标簽（空格分隔）： 軟工實踐

一、請回望暑假時的第一次作業，你對于軟體工程課程的想象

1）對比開篇部落格你對課程目标和期待，“希望通過實踐鍛煉，增強計算機專業的能力和就業競争力”，對比目前的所學所練所得，在哪些方面達到了你的期待和目标，哪些方面還存在哪些不足，為什麼？

更加具體的了解了什麼是軟工，并且在軟體開發上的專業程度有了很大的提升，懂得了軟體開發的具體流程。

不足的地方則是項目的完成度還不夠高，代碼量不夠。具體原因有很多，比如團隊内溝通不夠到位，進度沒有推進。任務的期限也沒有硬性的名額，以及其他一些原因造成了這些不足。

2）總結這門課程的實踐總結和給你帶來的提升，包括以下内容：

• 1、統計一下，你在這門軟體工程實踐中，完成了多少行的代碼；3000行

• 3、哪一次作業讓你印象最深刻？為什麼？

  印象最深的是beta沖刺，大概是因為這次的沖刺是最有條理也是規劃的最好的一次，整體上完成了我們定的beta目标。

• 4、累計花了多少個小時在軟工實踐上？平均每周花多少個小時？

  截至16周總共400小時 每周25小時

• 5、學習和使用的新軟體；

  wamp,vs,insomnia

• 6、學習和使用的新工具；

  processOn

• 7、學習和掌握的新語言、新平台；

  php

• 8、學習和掌握的新方法

  單元測試，以及伺服器端的接口測試

• 9、其他方面的提升。

  基本能熟練的使用github

二、寫下屬于自己的人月神話——個人或結對或團隊項目實踐中的經驗總結+執行個體/例證結合的分析

經曆了整整一個學期的軟工實驗，我覺得團隊間的溝通和讨論是最重要的。

我們團隊就因為溝通不夠的問題造成了一些完全可以避免的麻煩。最經常發生的事情就是前後端的對接問題。因為後端沒有接觸過前端，是以後端不知道前端要的接口是怎樣的，後端按照自己的想法寫出了接口，因為一開始前後端沒有進行過交流，是以寫出的接口并不符合前端的要求，就又拿回去改，因為這個問題。我們浪費了不少的時間。

三、對下一屆實踐的建議，或者對于開學初的你，對于大一的你，對于開學初的我，你有什麼想建議和告知的呢？對于後來人的期許。特别地，特别地，下一屆要不要中途換隊員？

我認為有一個比較有能力的隊長是最關鍵的。可以是那種專業能力強的，也可以是很認真很負責的。當然兩者都具備的隊長最好。隻有在這樣子的人上司的團隊下，才能夠更好的去學習去進步，同樣也更能推動項目的進展。當然自己的努力是更重要的。

至于換隊員的事，因為我們班完成的早是以沒有換隊員。但是在我看來是沒必要換的。

四、分析一下自己所處的團隊。軟體工程實踐是大學裡少有的認真的團隊協作經驗。《建構之法》上說團隊的發展有幾個階段，你的團隊都經曆過麼，最後到達了“創造”階段了麼？（參考《建構執法》第17章 人、績效和職業道德)

隻能說經曆過大部分。因為并不是專業的團隊，這個軟工也隻是我們很多作業中的一科，是以我們花的時間也沒有想象的那麼多，是以我們中間有些經曆也暫時沒遇到。創造這個階段我們肯定是還沒達到的。但是基本達到了規範這個層次。

五、怎樣證明你學會了軟體工程？

1）研發出符合使用者需求的軟體

基本完成。
           

2）通過一系列工具，流程，團隊合作，能夠在預計的時間内釋出 “足夠好” 的軟體

基本完成
           

3）并且通過資料展現軟體是可以維護和繼續發展的。

基本完成
           

4）對着這個檢查表：http://xinz.cnblogs.com/p/3852177.html 檢查一下，自己如果去企業面試，這些常見的問題是否都能回答，并在此總結。

第一部分：硬的問題。

語言1： C   50000+
語言2： java 10000+
軟體實作：有能力處理基本的問題
軟體測試：能力比較一般
效能分析：能對速度慢的代碼進行初步的優化
需求分析：較差
行業洞察力： 無
項目管理： 無
軟體設計： 一般
品質意識：能
工具/社群：目前隻有這個部落格。
團隊協作：需要具體的人站出來定好具體任務以及相關的deadline，團隊才能協作的更好
理論素養：很多資料結構的知識都可以用到
           

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

人的能力和成長路徑都是有多種選擇，沒有一定之規。 但是很多人喜歡數量化， 是以下面的的每項回答都可以換算為一個分數， 以滿足部分讀者的需求：

1.保持高标準，不要受制于破窗理論(broken windows theory)[i]。
當你看到不靠譜的設計、糟糕的代碼、過時的文檔和測試用例的時候，不要想         “既然别人的代碼已經這樣了，我的代碼也可以随便一點啦。” C

a) 從來沒聽說過；   b) 我就是這樣随便過來的；  c) 如果有明确要求，我可以做好。  d) 一直主動這樣做     e) 不但主動做， 還會影響同僚一起做好

2. 主動解決問題。當看到不靠譜的設計，糟糕的代碼的時候，不要想“可能别人會來管這個事情” ，或者“我下個月發一個郵件讓大家讨論一下”。要主動地把問題給解決了[ii]。C

a) 不懂啥是靠譜的設計；   b) 随便應付一下即可；  c)     如果有明确要求，我可以做好。  d) 一直主動這樣做     e) 不但主動做， 還會影響同僚一起做好



3. 經常給自己充電，身體訓練是運動員生活的一部分，學習是軟體工程師職業的伴侶。每半年就要了解和學習一些新的相關技術。通過定期分享（面對面的分享，寫技術部落格等）來確定自己真正掌握了新技術。  C

a) 從來不看書；   b) 看了就忘；  c) 有時分享。  d) 一直主動這樣做     e) 不但主動做， 還會影響同僚一起做好



4. DRY （Don't Repeat Yourself）——别重複。在一個系統中，每一個知識點都應該有一個無異議的、正規的表現形式。B

 a) 從來沒聽說過；   b) 聽說過，但是認為意思不大；  c) 這要講場合。  d) 一直主動這樣做     e) 不但主動做， 還會影響同僚一起做好



5. 消除不相關子產品之間的影響，在設計子產品的時候，要讓它們目标明确并單一，能獨立存在，沒有不明确的外部依賴。C

a) 從來沒聽說過；   b) 出了問題再說吧；  c) 想做，但是不知道怎麼衡量效果。  d) 能夠在多種語言和架構中做到     e) 不但主動做， 還會影響同僚一起做好



6. 通過快速原型來學習，快速原型的目的是學習，它的價值不在于代碼，而在于你通過快速原型學到了什麼。C

 a) 從來沒聽說過；   b) 把原型直接用于産品，不然就浪費了；  c) 不用原型，一直在産品中直接改。  d) 一直主動這樣做     e) 不但主動做， 還會影響同僚一起做好



7. 設計要接近問題領域，在設計的時候，要接近你目标使用者的語言和環境。D

a) 從來沒聽說過；   b) 按我的想法設計，使用者以後會适應的；  c) 大概同意，但是怎麼接近使用者呢？  d) 一直主動這樣做     e) 不但主動做， 還會影響同僚一起做好



8. 估計任務所花費的時間，避免意外。在開始工作的時候，要做出時間和潛在影響的估計，并通告相關人士，避免最後關頭意外發生。工作中要告知可能的時間變化，事後要總結。C

 a) 做完了，就知道花費了，不用事先估計；   b) 大概估一下，不必在意時間   c) 如果有明确要求，我可以做好。  d) 一直主動這樣做     e) 不但主動做， 還會影響同僚一起做好



9. 圖形界面的工具有它的長處，但是不要忘了指令行工具也可以發揮很高的效率，特别是可以用腳本建構各種組合指令的時候。D

  a) 一直用滑鼠和GUI；   b) 到時候問牛人；  c) 正在學習指令行工具。  d) 一直主動這樣做     e) 不但主動做， 還會影響同僚一起做好



10. 有很多代碼編輯器，請把其中一個用得非常熟練。讓編輯器可以實作自己的定制，可以用腳本驅動，用起來得心應手。C

 a) 隻用老師教的一個；   b) 随意；  c) 沒有任何定制。  d) 會定制，并且分享給其他人     e) 還會學習和使用各種編輯器的擴充。



11. 了解常用的設計模式，并知道擇機而用。設計模式不錯，更重要的是知道它的目的是什麼，什麼時候用，什麼時候不用。A

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



12. 代碼版本管理工具是你代碼的保障，重要的代碼一定要有代碼版本管理。E

 a) 從來沒聽說過；   b) 用QQ，u盤即可；  c) 上司要求才用。  d) 經常用     e) 不但主動做， 還會影響同僚一起做好



13. 在debug的時候，不要驚慌，想想導緻問題的原因可能在哪裡。一步一步地找到原因。要在實踐中運用工具，善于分析日志（log），從中找到bug。同時，在自己的代碼裡面加 log. B

 a) 從來沒聽說過；   b) 隻會printf；  c) 加log 太麻煩，我的代碼不會有bug 的。  d) 一直主動這樣做     e) 不但主動做， 還會影響同僚一起做好



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

 a) 從來沒聽說過；   b) 太麻煩，不用；  c) 想用，但沒有時間。  d) 一直主動這樣做     e) 不但主動做， 還會影響同僚一起做好



15. 隻在異常的情況下才使用異常 (Exception),  不加判斷地過多使用異常，會降低代碼的效率和可維護性。記住不要用異常來傳遞正常的資訊。D

a) 從來沒聽說過；   b) 抓住所有異常  c) 如果有明确要求，我可以做好。  d) 一直主動這樣做     e) 不但主動做， 還會影響同僚一起做好



16. 善始善終。如果某個函數申請了空間或其他資源，這個函數負責釋放這些資源。C

  a) 從來沒聽說過；   b) 随緣；  c) 有時這樣做。  d) 一直主動這樣做     e) 不但主動做， 還會影響同僚一起做好



17. 當你的軟體有多種技術結合在一起的時候，要采用松耦合的配置模式，而不是要把所有代碼都混到一起。B

  a) 從來沒聽說過；   b) 沒有實踐的機會；  c) 代碼都在一起比較好管理。  d) 一直主動這樣做     e) 不但主動做， 還會影響同僚一起做好



18. 把常用子產品的功能打造成獨立的服務，通過良好的界面 (API) 來調用不同的服務。C

 a) 從來沒聽說過；   b) 拷貝代碼過來用也可以  c) 如果有明确要求，我可以做好。  d) 一直主動這樣做     e) 不但主動做， 還會影響同僚一起做好



19. 在設計中考慮對并行的支援，這樣你的API 設計會比較容易擴充。D

 a) 從來沒聽說過；   b) 并行不會出錯的；  c) 任何代碼都應支援并行。  d) 考慮在适當的層次支援并行     e) 不但主動做， 還會影響同僚一起做好



20. 在設計中把展現子產品 (View) 和實體子產品 (Model) 分開，這樣你的設計會更有靈活性。 D

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



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

a) 從來沒聽說過；   b) 我的資料量不大，無所謂；  c) 不會有效率問題的，現在CPU 都快了。  d) 主動測試程式效率，以驗證估算     e) 不但主動做， 還會影響同僚一起做好



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

  a) 從來沒聽說過；   b) 想用，但不知道工具  c) 主要靠肉眼觀察算法效率。  d) 一直主動這樣做     e) 不但主動做， 還會影響同僚一起做好



23. 經常重構代碼，同時注意要解決問題的根源。A

  a) 從來沒聽說過；   b) 任何修改都可以叫重構；  c) 每天應該重構兩次。  d) 一直主動這樣做     e) 不但主動做， 還會影響同僚一起做好



24. 在開始設計的時候就要考慮如何測試 ，如果代碼出了問題，有log 來輔助debug 麼? 盡早測試，經常測試，争取實作自動化測試，争取每一個建構的版本都能有某些自動測試。CC

 a) 從來沒聽說過；   b) 我的代碼不會出問題的；  c) 項目沒有安排時間，我也沒有提這事。  d) 一直主動這樣做     e) 不但主動做， 還會影響同僚一起做好



25. 代碼生成工具可以生成一堆一堆的代碼，在正式使用它們之前，要確定你能了解它們，并且必要的時候能debug 這些代碼。D

 a) 從來沒聽說過；   b) 從來不看那些代碼；  c) 那些代碼沒有bug。  d) 一直主動這樣做     e) 不但主動做， 還會影響同僚一起做好



26. 和一個實際的使用者一起使用軟體，獲得第一手回報。 D

  a) 從來沒聽說過；   b) 使用者太蠢，不值得聽回報；  c) 想做但是沒有機會。  d) 一直主動這樣做     e) 不但主動做， 還會影響同僚一起做好



27. 在自動測試的時候，要有意引地入bug，來保證自動測試的确能捕獲這些錯誤。D

 a) 沒聽說過；   b) 不必這麼麻煩；   c) 如果有明确要求，我可以做好。  d) 一直主動這樣做     e) 不但主動做， 還會影響同僚一起做好



28. 如果測試沒有做完，那麼開發也沒有做完。D

 a) 從來沒聽說過；   b) 簽入代碼，就是做完了；  c) 。  d) 一直主動這樣做     e) 不但主動做， 還會影響同僚一起做好



29. 适當地追求代碼覆寫率：每一行的代碼都覆寫了，但是程式未必正确。要確定程式覆寫了不同的程式狀态和各種組合條件。D

  a) 從來沒聽說過；   b) 覆寫20% 就好了；  c) 要覆寫至少60%。  d) 一直主動這樣做     e) 不但主動做， 還會影響同僚一起做好



30. 如果團隊成員碰到了一個有普遍意義的bug,  應該建立一個測試用例抓住以後将會出現的類似的bug。D

 a) 從來沒聽說過；   b) 每個bug都是特殊的；  c) 測試用例不值得加  d) 一直主動這樣做     e) 不但主動做， 還會影響同僚一起做好



31. 測試：多走一步，多考慮一層。如果程式運作了一星期不退出，如果使用者的螢幕分辨率再提高一個檔次，這個程式會出什麼可能的錯誤? B

 a) 從來沒聽說過；   b) 如果有問題，使用者會報告的，我們不用測這些；  c) 如果有明确要求，我可以做好。  d) 一直主動這樣做     e) 不但主動做， 還會影響同僚一起做好



32. （帶領團隊）了解使用者的期望值，稍稍超出使用者的期望值，讓使用者有驚喜。B

  a) 從來沒聽說過；   b) 我們決定使用者的期望；  c) 如果有明确要求，我可以做好。  d) 一直主動這樣做     e) 不但主動做， 還會影響同僚一起做好



33. （帶領團隊） 不要停留在被動地收集需求，要挖掘需求。真正的需求可能被過時的假設、對使用者的誤解或其他因素所遮擋。C

  a) 從來沒聽說過；   b) 使用者不說的，我們不做；  c) 如果有明确要求，我可以做好。  d) 一直主動這樣做     e) 不但主動做， 還會影響同僚一起做好



34. （帶領團隊）把所有的術語和項目相關的名詞、縮寫等都放在一個地方。B

  a) 從來沒聽說過；   b) 都記在我腦子裡；  c) 大家看代碼就好  d) 一直主動這樣做     e) 不但主動做， 還會影響同僚一起做好



35. （帶領團隊）不要依賴于某個人的手動操作，而是要把這些操作都做成有相關權限的人士都能運作的腳本。這樣就不會出現因為某人休假而項目被卡住的情況。B

 a) 從來沒聽說過；   b) 我們沒有休假的，沒關系；  c) 出了問題再說  d) 一直主動這樣做     e) 不但主動做， 還會影響同僚一起做好



36. （帶領團隊）要讓重用變得更容易。一個軟體團隊要創造一種環境，讓大家有輕松的心态來嘗試各種想法 （例如，子產品的重用，效能的提升，等）。A

  a) 都聽上司的；   b) 團隊嚴肅緊張最好；  c) 不必嘗試，失敗的可能性太大。  d) 一直主動這樣做     e) 不但主動做， 還會影響同僚一起做好



37. （帶領團隊）在每一次疊代之後，都要總結經驗，讓下一次疊代的進度安排更可靠，品質更高。D

  a) 沒有時間總結，直接做下一版；   b) 總結用處不大；  c) 如果上級有要求，就做一下；  d) 一直主動這樣做     e) 不但主動做， 還會影響同僚一起做好