我的做業四--Alpha階段我的總結

1、我的總結

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

類別	具體技能和麪試問題	如今的回答	畢業找工做時
語言	最拿手的計算機語言之一,代碼量多少? (偏web前端，PC/Mobile App)	Java，大概應該有一萬吧
語言	最拿手的計算機語言之二,代碼量多少? (偏後端，數據處理，網站後臺，機器學習，等)	c++，大概五千？
軟件實現	(閱讀代碼的能力，實現，單元測試) 你有沒有在別人代碼的基礎上改進，你是怎麼讀懂別人的代碼的，你採起了什麼辦法來保證你的新功能不會影響原來的功能 ?你在開發中碰到最複雜的bug 是什麼，你是如何解決的?這個bug 出現的緣由是什麼，你在未來應該怎麼去避免bug 再出現?	有在別人的代碼上改進，讀懂別人的代碼首先要清楚各個類，變量的含義，其次經過註釋理解代碼，要是沒有註釋的話讀代碼就比較吃力。新開發的功能最好單獨作一個模塊，儘可能避免有所交集，實在沒法避免須要仔細縷清代碼，不能有二義性，影響原有功能。開發較少，尚未碰到很複雜的bug。
軟件測試	(測試方法、測試工具、測試實踐、代碼覆蓋率)你如何測試你自 己寫的代碼?你如何測試別人的代碼?你掌握了多少種測試工具和方法?你寫過測試工具麼?你如何對一個網站進行壓力測試和效能測試?你如何測試一個軟件的人機界面(UX/U1)?	經過本身寫測試代碼，eclipse有自帶測試工具，其餘沒用過，也沒寫過測試工具，不懂。
效能分析	效能分析，效能改進,你寫過的最複雜的代碼是什麼? 你是如何測量和改進它的效能的，用了什麼工具，如何分析的?	沒寫過
需求分析	(需求分析，典型用戶，場景，創新)你作過多少個有實際用戶的項目，用戶最多有多少?你的項目有什麼創新的地方?	作的項目沒發佈過，最近作的記帳小程序發佈了，目前用戶應該有20，由於還在開發階段，創新的地方還沒寫出來。
行業洞察力	你最感興趣的領域是什麼? 這個領域過去10年經歷了哪些創新?你分析過這個領域前10名產品麼? 請分析一下他們的優劣，你要進入這個領域，應該如何創新?	web前端技術，主要是網頁設計的核心技術--HTML、CSS和JavaScript
項目管理	你參與過項目管理麼? 請描述一下兩個當下流行的開發方法在你的項目中的具體應用狀況;請問你如何決定項目中各類任務的優先次序，有什麼理論來支持你的作法若是你忽然發現項目不能按時完成，你做爲項目領導，有什麼辦法?	最新的項目使用敏捷開發，目前alpha階段已經完成，剛開始beta階段。各類任務的優先次序取決於項目的進度和任務的緊迫程度。
軟件設計	你作過架構設計，模塊化設計，接口設計麼? 請說明一下你爲什麼是這樣設計，你比較過什麼不一樣的設計方式，你的設計取得了什麼結果?	作過設計，以架構爲中心，功能模塊化，具體到接口、類。
質量意識	(代碼複審/代碼規範/代碼質量) 你是怎麼作代碼複審的，你加入咱們團隊後，能幫咱們提升代碼質量麼，請具體說怎麼提升?	檢查是否符合代碼規範，檢查代碼的重複率，檢查是否代碼具有其功能。
工具/社區	Software Tools (performance tool,version control,work item,TFS)你在各類開發平臺(web,linux,PC,mobile,machine learning) 都使用過什麼樣的工具，本身寫過什麼工具來改進工做效率?給社區貢獻過什麼工具和代碼? Github有分享代碼麼?你寫的技術博客堅持了多久，讀者最多的是哪一篇?	vc6.0，vs2015，eclipse，微信web開發者工具、devC++等，代碼有上傳至git。大二開始有寫博客。
團隊協做	Work with others (協同工做，提供反饋，說服別人)請描述你在項目中如何說服同伴採用你提出的更好的解決方案，或者你如何聽取了別人的意見，改進了本身的方案?你如何說服懶惰的同伴加緊工做，實現團隊的目標?	我會列舉出我提出的方案的好處，以及原有方案的劣處，別人的意見好仔細思考，真的有用要聽取改進。同伴懶惰時，要以身做則，指出咱們共同的目標，鼓勵他。
理論素養	你上過什麼數學，計算機或其餘理論課，請舉 出具體的例子，說明你學到的理論知識如何幫助你解決實際問題	高等數學、離散數學、線性代數、機率論、數字邏輯等，太多了，也想不起來具體幫助了我什麼，可是我知道必定有用。
自我管理	整年級你專業排名多少?你從剛入學(大學一年級) 到如今的排名有變化麼?如何解釋你的排名的變化?	二十幾吧，排名基本沒大的什麼變化，可是仍是有所浮動。與掌握的知識技能有關，還與考試的狀態有關？

2、回答問題

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

Q1：初級軟件工程師如何成長？什麼是好的軟件設計思想？什麼是好的軟件工程思想？

• 軟件工程師能夠如此成長
  • 我認爲，初級工程師之因此爲「初級」，是由於自己能力有限，那麼就須要打磨本身的專業，「較小的領域」更容易作出讓人印象深入的成績，做爲初級工程師，要在較小的領域精益求精。
  • 第二點是不懂就問，虛心求教。沒有人一開始就什麼都懂，都是一點一滴積累起來的知識。聽來的學問必定要和實踐結合，深入理解並運用纔算真正的掌握。
  • 第三，要能有效管理本身的工做，最好是有一套指標來衡量，越是有明確的指標，就越有能力推進研發的行爲。

• 好的軟件設計思想

  軟件設計是從軟件需求規格說明書出發，根據需求分析階段肯定的功能設計軟件系統的總體結構、劃分功能模塊、肯定每一個模塊的實現算法以及編寫具體的代碼，造成軟件的具體設計方案。

  好的軟件設計思想是可以把上面提到的任務很好地完成並鏈接在一塊兒，從一開始就必須想好怎麼實施，將問題或事物分解並模塊化使得解決問題變得容易。

• 好的軟件工程思想
  仍是有四個要點：迭代開發、以系統架構爲中心、持續的質量保證以及管理變動和資產。要作就要作一個有「生命力」的軟件，不斷修復bug，更新版本，注入新的活力軟件才能存在得更久。

Q2：結對編程會出現的問題

• 我認爲結對編程的利弊仍是因人而異了。結對的雙方如果編程水平差太多，或者兩人根本不熟悉也不瞭解對方的編程習慣，結對編程的做用很明顯就會弊大於利了。固然在工做中通常不會出現水平相差太多的狀況，畢竟能成爲同事也是不容易的事呢。若是說爲了長遠的利益，結對編程是必要的，那麼就有必要花些時間去磨合了，無論是以什麼樣的方式。

• 反之，結對編程的好處就會多多了。就如書上提到的那樣：

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

Q3：在穩定和發佈階段，無關大局的缺陷非得立刻解決嗎？修正方案中又有缺陷怎麼辦？

  到了穩定和發佈階段，軟件已經成型，bug一直都有，有的能夠解決，有的目前沒法解決，本身也經歷過了敏捷開發，明白其實無關大局的缺陷沒必要立刻解決，尤爲是快要發佈的時候，那時可能作不到修正缺陷後再發布，因此能夠等到適合的時機再行修改。軟件都會有迭代，通常來講，每次迭代，都會修復已發現的bug，或是新增其餘的功能，對用戶來講，最重要的是要有良好的體驗，在不影響這一目標的狀況下應當容許某些bug的暫時存在。前面也說了，bug老是會有，世上沒有完美的東西，也不會有完美的軟件，給你完美的感受只是當下，只是淺層面的，後面迭代的至少都會比以前的版本好。

3、再提問題

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

Q1：書本P16提到不少人認爲有Bug就是質量不合格，沒有Bug就是質量完美，其實這也未必。

  我認爲「Bug」也是因人而異的，對某些人來講是缺陷，對某些人來講這正是特色。就如書上舉的例子，褲腿上有洞的牛仔褲，像是年輕人就認爲這很fashion，沒什麼問題，而「老年人」就認爲有洞是質量很差，應該拿去退換。汽車有那麼多品牌，各有各的好，有些人注重性能，有些人在乎外觀，等等，在他們眼裏「好」是不一樣方面的，而銷售人員就須要針對不一樣需求的用戶推銷適合他們的產品，結果纔是皆大歡喜，不然最後銷量未必理想。

Q2：書本P79提到誰來作代碼複審？即最有經驗、熟悉這一部分代碼的人。

  最有經驗、熟悉這一部分代碼的人難道不是開發者自己嗎？複審者是在替開發者幹開發者本應乾的事情那麼是否須要安排專門的人來作代碼複審呢?

Q3：書本中第五章列舉了不少團隊模式：主治醫師模式、明星模式、社區模式、業餘劇團模式、祕密團隊、特工團隊、交響樂團模式等等。

  這麼多模式，怎麼清楚定位本身的團隊是什麼模式呢？並且我認爲每一個階段的模式可能不同。

Q4：書本P122提到敏捷對團隊的要求和簡單：自主管理（Self-managing）、自我組織（Self-organizing）、多功能型（Cross-functional）

  事實上咱們大學生還不能算一個成熟的團隊，敏捷開發對咱們來講很困難，每一個人毛病挺多，能力也不強，因此老師讓咱們敏捷衝刺，也只是在時間驅動下完成項目而已。或許老師只是讓咱們體驗一下敏捷開發的流程，可是咱們真的能有所感悟就行了。就如書上所說：

若是你的團隊很弱，那麼強行把敏捷（或者其餘高級方法）套在上面也沒有用，也許還會拔苗助長，每每須要經歷屢次失敗/總結/改進的過程才能讓Scrum走上正軌。

Q5：書本P281提到的「灰箱」是什麼？咱們該怎麼選擇白箱、黑箱、灰箱呢？

所謂白箱就是機制和結構徹底明瞭的系統，如同電視機對電視發明製造者來講就是「白箱」。

所謂灰箱，就是至關部分的結構機制已經明瞭，但並無徹底明瞭的系統，如電視機對一個並不高明的修理者來講就是「灰箱」。

所謂黑箱就是結構機制徹底不明瞭，僅僅知道輸入輸出信息之間某些簡單關係的系統，如電視機對一個根本不懂電器的用戶來講，他只知道打開鈕就亮、閉掉鈕就滅同樣。