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

1、我的總結

在alpha 結束以後， 每位同窗寫一篇我的博客， 總結本身的alpha 過程；

請用自我評價表：http://www.cnblogs.com/xinz/p/3852177.html 有比較纔會有進步。

類別	具體技能和麪試問題	如今的回答(大三下)
語言	最拿手的計算機語言之一,代碼量多少? (偏web前端，PC/Mobile App)	html，代碼量爲3000
語言	最拿手的計算機語言之二，代碼量多少? (偏後端，數據處理，網站後臺，機器學習	C，代碼量爲4000
軟件實現	(閱讀代碼的能力，實現，單元測試) 一、你有沒有在別人代碼的基礎上改進，你是怎麼讀懂別人的代碼的？ 二、你採起了什麼辦法來保證你的新功能不會影響原來的功能? 三、你在開發中碰到最複雜的bug是什麼，你是如何解決的? 四、這個bug出現的緣由是什麼，你在未來應該怎麼去避免bug再出現?	一、印象中沒有，由於很不喜歡看別人的代碼，有的是會片斷的學習 二、逐字逐句的推敲研究 三、代碼上要注意分塊隔開，變量上的名稱有意義不覆蓋，在增長了一個新功能的同時要去檢查一下原來的功能受到影響，避免後面堆雜 四、從後端傳入的js語言的數據要進行提取並放到框架中，還要保證相同日期的日期顯示只顯示一條，經過慢慢調試，網上找相似的案例分析解決 五、出現的緣由是對js語言的不瞭解，對列表數據填充的知識瞭解不夠深刻，未來須要多接觸這些語言並結合使用，熟能生巧
軟件測試	(測試方法、測試工具、測試實踐、代碼覆蓋率) 一、你如何測試你本身寫的代碼? 二、你如何測試別人的代碼? 三、你掌握了多少種測試工具和方法? 四、你寫過測試工具麼? 五、你如何對一個網站進行壓力測試和效能測試? 六、你如何測試一個軟件的人機界面(UX/UI)？	一、編寫測試代碼進行測試 二、直接運行進行大數據測試 三、微信小程序平臺的測試工具，測試方法只會測試代碼測試 四、沒有啊 五、多人同時訪問進行壓力測試，效能測試主要看運行的速度和服務器的響應速度 六、主要是經過一個美觀和使用操做的狀況進行測試的
效能分析	效能分析，效能改進 一、你寫過的最複雜的代碼是什麼? 二、你是如何測量和改進它的效能的，用了什麼工具，如何分析的?	一、算法課的結課代碼，是一個尋找凸包的程序 二、大數據衝擊，當時纔不懂什麼測試工具呢
需求分析	(需求分析，典型用戶，場景，創新) 一、你作過多少個有實際用戶的項目,用戶最多有多少? 二、你的項目有什麼創新的地方?	（哭泣）沒有作過實際的項目
行業洞察	一、你最感興趣的領域是什麼? 二、這個領域過去10年經歷了哪些創新? 三、你分析過這個領域前10名產品麼?請分析一下他們的優劣 四、你要進入這個領域，應該如何創新?	一、最感興趣的是AR 二、這個領域算是比較新的行業，產品從早教到導航都有涉及 三、沒有分析過，可是AR產品在導航方面作的比較通常，比較多的是紅包和早教產品 四、創新的話能夠考慮在什麼方面很好的利用AR這個技術而且投入使用的可能性最大
項目管理	一、你參與過項目管理麼?請描述一下兩個當下流行的開發方法在你的項目中的具體應用狀況 二、請問你如何決定項目中各類任務的優先次序，有什麼理論來支持你的作法 三、若是你忽然發現項目不能按時完成，你做爲項目領導，有什麼辦法?	沒有參加過項目管理
軟件設計	一、你作過架構設計，模塊化設計,接口設計麼? 二、請說明一下你爲什麼是這樣設計 三、你比較過什麼不一樣的設計方式，你的設計取得了什麼結果?	一、模塊化設計 二、模塊化設計不只是方便本身對代碼的審覈和查閱，而且對於糾錯也比較容易 三、若是不使用模塊化設計，你的代碼看起來將會毫無邏輯性可言，雜亂無章，本身都看不下去
質量意識	(代碼複審/代碼規範/代碼質量) 一、你是怎麼作代碼複審的 二、你加入咱們團隊後，能幫咱們提升代碼質量麼，請具體說怎麼提升?	一、主要是經過本身複審和同伴複審 二、能夠，經過審覈代碼的規範性和可行性來提升代碼的質量
工具/社區	Software Tools (performance tool, verslon control, work item, TFS) 一、你在各類開發平臺(web, linux, PC, mobile, machine learning) 都使用過什麼樣的工具 二、本身寫過什麼工具來改進工做效率? 三、給社區貢獻過什麼工具和代碼? 四、 Github有分享代碼麼? 五、你寫的技術博客堅持了多久，讀者最多的是哪一篇?	一、不曉得編譯環境算不算得上呀 二、沒有本身寫過工具 三、沒有給社區貢獻過什麼工具和代碼 四、沒有使用github 五、學習java時寫過一學期，再次接觸就是此次的軟工了，讀者最多的一篇不是由於質量好，而是由於提交的早
團隊協做	Work with others (協同工做，提供反饋， 說服別人) 一、請描述你在項目中如何說服同伴採用你提出的更好的解決方案，或者你如何聽取，了別人的意見，改進了本身的方案? 二、你如何說服懶惰的同伴加緊工做，實現團隊的目標?	一、有想法的時候就會提出來，若是你們都以爲好就會認同這個idea，不認同的話我會聽別人的意見，肯定本身的想法確實存在不夠好的地方 二、在團隊中咱們是約定好時間一塊兒辦事的，實在沒辦法一塊兒參與的就會自行安排時間，而且在這個團隊中我發現個人同伴都是比我要勤快的
理論素養	你上過什麼數學，計算機或其餘理論課，請舉出具體的例子，說明你學到的理論知識如何幫助你解決實際問題。	數學這門課好像沒發如今實際中有什麼用處，計算機的課程主要是教你一種編程的思想，這種思想在實際中是能夠通用的，很培養人的耐心啊
自我管理	一、整年級你專業排名多少? 二、你從剛入學(大學年級)到如今的排名有變化麼? 三、如何解釋你的排名的變化?	一、2030左右吧 二、沒什麼變化啊，都差很少

2、回答問題

咱們在課程開始之初，曾經要求你們針對軟件工程提出問題：我的閱讀做業2，那麼在通過alpha階段，你們是否對軟件工程有了必定的

瞭解？請結合本身提出的問題進行回答

Q1：

單元測試必須由最熟悉代碼的人（程序的做者）來寫。
測試的運行、經過、失敗不依賴於別的測試，能夠人爲構造數據，以保持單元測試的獨立性。
--引用自《構建之法-第二版》

• 看到第二章我的技術和流程這一塊時，裏面講到單元測試對於一個程序可以有完美的開端是必不可少的，特別是閱讀到上面所寫的這邊時，我就產生了疑惑，在個人切身經驗中，我一開始寫代碼的時候，並未能對本身的代碼構思產生質疑，而做者提到最好能在設計的時候就寫好單元測試，是指說當我完成一部分功能時就應該進行單元測試嗎？好比說我以前java的課設就是寫的四則運算，就事先考慮了我這個程序要有的功能有什麼而後進行編寫，到最後才進行測試，那我只能在代碼都完成的時候進行調試了。而後我以爲單元測試是應該由程序的做者來寫，可是測試的時候能夠由他人進行，由於我在本身寫的時候會陷入本身的固有思惟而有不少誤區都沒有考慮到。而後是我以爲單元測試是否是能夠在開發的過程當中適當的隨情來減小，若是是一些特別篤定不會有問題產生的地方可不能夠省去這個步驟，而不會在這個過程帶來繁瑣的負擔。

答：在alpha階段的開發中，其實咱們並無精力去進行什麼單元的測試，咱們直接在微信開發平臺裏面編寫直接調試，而且沒有進行什麼代碼的構思，固然這也是由於在此次的開發中沒有用到而已，在以後的項目中我以爲代碼測試仍是特別有必要的，而且是在你完成一部分功能就進行測試爲好，由於那樣子纔不會對你以後的進程有牽絆。總體的代碼須要在一開始就有一個大概的構思，而後進行模塊的劃分，不要邊寫邊研究，會很亂

Q2：

主治醫師模式：首席程序員負責處理主要模塊的設計和編碼，其餘成員從各個角度支持他的工做（後備程序員、系統管理員、工具開發、編程語言專家、業務專家）。
業餘劇團模式：團隊在每個項目中，不一樣的人會挑選不一樣的角色，在下一個劇目中，這些人也許會換一個徹底不一樣的角色類型，我的在團隊中遵從一箇中央指揮的指導和安排。
交響樂隊模式：傢伙多，門類齊全，演奏都靠譜，同時看指揮。
--引用自《構建之法-軟件團隊的模式》

• 上面講到了不少種軟件團隊的合做模式，我從中總結了一個團隊合做中特別必要的人員就是總指揮，無論是在主治醫師模式仍是交響樂隊模式，甚至是在官僚模式中都是須要這麼一個大佬來掌握全軍的進程並隨時監督和檢查。雖然選擇什麼樣的團隊模式都是因人而異還要考慮項目的各個需求，可是我想的是若是能結合上面幾種模式，未免不是一種適應性較高的團隊模式，這種模式須要一個全能的而且有指導性的大佬，由他來進行團隊成員的能力分析和爲整個項目作一個總體的規劃，而後由其餘成員進行配合工做來完成。就好比咱們的結對編程也是能夠的，老是開始於一個比較有想法的大佬提出，固然在這個過程當中成員對此有任何意見都是能夠協商的，最後由你們各司其職來完成這個項目。

答：其實每一個團隊都有他們獨特的團隊模式，全部幾乎沒有哪種特別固定的什麼主治醫師模式仍是交響樂隊模式能夠一以歸納的，而且這個和團隊成員之間的協做力、調度力、執行力都有很大的關係

Q3:

敏捷開發的原則：
一、儘早並持續的交付有價值的軟件以知足顧客需求；
...
五、以有進取心的人爲項目核心，充分支持信任他們；
...
十二、時時總結如何提升團隊效率，並付諸行動。
--引用自《構建之法-敏捷流程》

• 敏捷流程是一系列價值觀和方法論的集合，從理論上來看，這個方法論是完美的，可是我比較疑惑的是上面的幾點。原則上敏捷的開發說是以有進取心的人爲核心，而且要充分的信任他們。有進取心是必然的，若核心都沒辦法嚴格苛求那整個團隊必然會受其拖怠影響，可是充分的信任他們我不是很贊同，就算是大佬也會有錯判之時。還有一點是，原則上提到要時時總結如何提升團隊的效率，提出這個的目的是爲了跟進團隊的質量，在總結以往的正確或是錯誤經驗來進行調整，可是我以爲如何在段時間內最有效的總結出經驗纔是最可觀的，每日的例會總結可能會帶來負面的影響，有人由於交差而不符合客觀事實的提出問題，不只浪費時間還有可能使總路線方針偏離。

答：咱們團隊在敏捷開發的原則上能夠說是完美的詮釋了「以有進取心的人爲核心，而且充分的信任他們」這一原則，由於在一個團隊中你會發現PM的帶動做用是特別強大的，充分的信任是必須作到的，而且不是說一昧的苟同觀點，而是對一系列任務的安排都必須嚴格的按她說的進行，若是有什麼問題上須要商量的能夠提出來你們一塊兒解決

Q4:

功能的定位和優先級
殺手功能：OCR文字識別技術，能夠在屏幕上取詞解釋，擁有獨家權威詞典；
外圍功能：良好的界面設計，在各個平臺上都能運行；
必要需求：單詞的短語釋義的準確性；
輔助需求：能夠作各類皮膚；
功能分析的四個象限可讓咱們決定怎麼處理不一樣類型的功能，重要的是，傾斜到能夠產生差別化和獨特用戶價值的地方。
--引用自《構建之法-需求分析》

• 這裏說到對用戶的需求分析後重點將軟件服務傾斜到能夠產生差別化和獨特用戶價值的地方，這裏的差別化是具備別具一格的功能特點和用戶體驗，這裏就是所謂的殺手功能，但是在這以前我認爲應該還須要考慮的是需求人羣，是學生仍是大齡人仍是適用於面向全體人羣的軟件應用。倘若這項服務是爲了知足用戶額外的娛樂，那麼應該將重點同時放置於這裏所說的輔助需求和殺手功能，就好比絕地求生和荒野行動這兩款手遊，不同的用戶體驗（畫質感）和佔用的空間大小或者流暢度都會直接影響了市場。

答：考慮殺手功能的前提之上自己就是創建在你肯定了用戶人羣了，肯定一個項目的同時就已經很天然的肯定了這個項目所面向的人羣。

Q5:

分而治之
一個團隊項目要在一段時間內完成諸多任務，知足用戶的需求，實現團隊的目標，同時還但願項目能維持良好的技術架構，從哪裏入手?
--引用自《構建之法-WBS》

• 在構建WBS樹時，選擇從結果出發構建WBS樹，而不是從團隊的活動出發是什麼用意？WBS樹的構建是爲了將項目分解成小型塊以方便開發團隊進行分工仍是主要是給產品的接收方或利益相關者看的？我在360百科中查詢到說工做包(work package)是WBS的最底層元素，通常的工做包是最小的"可交付成果"，所以一個用於項目管理的WBS必須被分解到工做包層次纔可以使其成爲一個有效的管理工具，這也就是葉子節點了，可是若是葉子節點特別小隻須要短期就能夠完成，那能夠將上一層結點做爲葉子節點嗎？

答：用意是爲了避免讓咱們團隊在項目開發的過程當中偏離軌道，從結果出發去構建WBS樹能更好的創建一個好的出發點。工做包的最小的葉子節點，即便是再細小的任務也應當作爲葉子節點。

3、再提問題

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

Q1：

敏捷流程第三步：衝刺
--引用自《構建之法P107》

• 在alpha階段進行七天衝刺時，咱們在開始的第一天將第七天的任務都安排好了，可是咱們發現不少任務的量實現安排過多，致使咱們沒有辦法對看板進行一個很合理的安排，到後面的燃盡圖也是奇奇怪怪的，甚至有的任務由於時間緊迫被刪除，想問當遇到這種狀況怎麼辦，如何在一開始就對咱們整個大的流程有一個比較細緻合理的安排

Q2：

兩人合做：
兩個工程師在一塊兒，作的最多的事情就是「看代碼」
--引用自《構建之法P59》

• 我以爲兩我的之間的合做更多的時間是花在瞭如何安排任務，我想問的是如何安排任務才能盡善盡美，又能考慮各自的擅長之處又不會有任務量的差異

Q3：

-在實際的開發過程當中，我發現課本上不少知識理論和團隊理念彷佛都沒有用到咱們實際的開發中去，博客是一直進行，也一直在教咱們運用書本，但是好像變成了一種交付式的任務，想問一下這個是否是咱們的課題選的不夠很好的將實踐與理論相結合？仍是說是咱們的時間不夠充足去體會這個過程

Q4：

軟件測試：
-引用自《構建之法P270》

• 測試須要從用戶角度出發，那能夠不用寫規格說明書和測試文檔了嗎

Q5：

MSF
保持敏捷，預期和適應變化

• 在alpha階段中咱們就出現了當質量和功能相互衝突的時候，想把質量完善了，可是侷限於這個問題整個團隊的進度就會被拉開，這時候能夠放棄一些質量來進行功能的繼續嗎