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

1、我的總結

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

類型 具體技能和麪試問題 如今的回答 畢業時找工做
語言 最拿手的計算機語言之一(偏前端),代碼量是多少 js,代碼量大概2,3千左右
語言 最拿手的計算機語言之二(偏後端),代碼量是多少 java,代碼量大概1萬左右
軟件實現 有沒有在別人的代碼基礎上進行改進,你是怎麼讀懂別人的代碼的,
你採起什麼方法來保證你的新功能不會影響原來的功能,
你在開發中碰到最複雜的bug是什麼,你是如何解決的?
這個bug出現的緣由是什麼,你在未來應該怎麼去避免bug再出現
1.有,能夠說滿常常;
2.讀懂別人的代碼分兩種狀況,一種是寫代碼的本人在你旁邊(這是目前比較常見的狀況),最簡單的辦法是直接問寫代碼本人代碼寫了什麼。
另外一種是寫代碼本人你問不到,這就首先要根據代碼的註釋,其次根據函數命名能夠大概知道函數的功能,最後是運行一下,看運行結果也能知道代碼在寫什麼;
3.大的框架不變,只修改要改進模塊的代碼,函數的返回值若是有修改,調用函數的地方都要相應修改
4.遇到的bug有的是原有代碼就存在的bug,有的是改進的代碼與原有的代碼函數結果不一致。解決的辦法能夠直接寫幾句輸出代碼,看看問題出如今哪一個範圍的代碼,若是是Java寫的,能夠用Java的調試,就能夠一步步看代碼的運行結果。
測試軟件 你如何測試本身的代碼?
你如何測試別人的代碼?
你掌握了多少種測試工具和方法?
你寫過測試工具麼?
你如何對一個網站進行壓力測試和效能測試?
你如何測試一個軟件的人機界面(UX/UI)?
1.測試本身代碼就能夠先寫測試用例看看能不能獲得本身想要的結果,或者使用測試工具,好比java自帶的測試工具,JUnit單元測試和代碼覆蓋率,效能分析能夠用JProfier(可是其實這個軟件的測試結果,我分析起來仍是蠻費勁的)
2.測試別人的代碼,主要要先懂得別人的代碼,其餘的測試跟測試本身代碼是同樣的
3.目前掌握的測試工具備Java自帶的測試工具,測試方法有測試用例,代碼覆蓋率,能夠在須要測試的代碼,寫一些輸出代碼,能夠看代碼運行到哪
3.沒有寫過測試工具,由於也是學了軟工纔對測試有概念
4.我尚未寫過可實際運行的網站,因此也沒有進行過壓力測試和效能測試
5.沒有進行過真正的人機界面測試
效能分析 你寫過的最複雜的代碼是什麼?你是如何測試和改進它的效能的,用了什麼工具,如何分析? 1.我寫過最複雜的代碼就是學生選課系統,由於整個系統都是本身作的,時間就只有一週,考慮的問題有不少,好比,有多名選課數據的刷新,重複選課等。2.那時候還不懂得使用測試工具,寫完後能運行出想要的結果就結束了。如今的話,會使用測試用例進行測試,用JProfier進行效能分析。
需求分析 你作過多少個有實際用戶的項目,用戶人數多少,你的項目有什麼創新的地方? 目前有實際用戶的項目就是咱們如今團隊開發的i詞彙,如今目前的用戶數量爲43人。項目的創新在於把遊戲與學習相結合,既能玩遊戲又能學習,還能起到複習單詞的做用
行業洞察力 你最感興趣的領域是什麼?這個領域過去十年有哪些創新?
你分析過這個領域前10的產品麼?請分析一下他們的優劣,你要進入這個領域,應該如何創新
我最感興趣的領域是微信小程序。微信小程序是比較新的東西,也是近幾年才發展起來,與一開始的開發工具相比,如今的開放工具已經友好不少了。要是它的開發工具的有代碼調試或者報錯了能夠指向錯誤的代碼就行了
項目管理 你參加過項目管理嗎?請描述一下兩個當下流行的開發方法在你的項目中的具體應用狀況
如何決定項目中各個任務的優先次序,有什麼理論來支持你的作法?
若是你忽然發現項目不能按時完成,你做爲項目領導,有什麼辦法?
1.參加過項目管理。開發項目具體使用過的有主治醫師模式和敏捷開發。主治醫師模式在項目開發過程當中一旦主要開發人員沒有進展,整個項目基本跨了,而敏捷開發,是你們一塊兒開發,各有各的任務,週期也比較短,你們的積極性也比較高。
2.項目的任務的主次是根據團隊定義的MVP,屬於MVP版本的就是主要任務,不屬於MVP的任務屬於次要任務。由於敏捷開發就是先作出各可交付的版本。
3.若是忽然發現項目不能按時完成,第一先尋求別人的幫助,若是仍是很緊急,你那就調整項目的時間安排,經過增長工做時間來保證完成任務。若是以爲仍是不能按時完成,就讓開發不是MVP版本功能的開發人員從新分配還未完成的任務。
軟件設計 你作過架構設計,模塊化設計,接口設什麼?請說明一下你爲什麼是這樣設計,你比較過什麼不一樣的設計方式,你的設計取得什麼結果? 我作過接口設計,這樣設計首先讓代碼看得很清楚,其次減小代碼的冗餘。我還未使用過其餘設計方法,因此沒法進行比較
質量意識 你是怎麼作到代碼複審的,你加入團隊後,能幫助咱們提升代碼質量麼,請具體說怎麼提升? 從代碼是否符合需求和規格說明,設計是否考慮周全,代碼可讀性高麼,代碼容易維護麼,代碼的是否有錯誤處理、邊界處理、資源利用等,代碼的效能如何等方面進行代碼複審。提升代碼質量首先要有代碼規範,其次要減小代碼冗餘,對代碼進行模塊化設計和接口設計,作到一個功能寫一個函數,一個函數不要含有不少功能。
工具/社區 你在各類開發平臺都使用過什麼工具,本身寫過什麼工具來改進工做效率?給社區貢獻過什麼工具和代碼?Github有分享代碼麼?你寫的技術博客堅持了多久,讀者最多的是那一篇? 還未在開發平臺使用過工具。主要是用碼雲來分享代碼。寫技術博客兩年了,讀者最多的篇章是201521123005 《Java程序設計》 第九周學習總結
團隊協做 請描述你在項目中如何說服同伴採起你更好的方案,或是聽取別人的意見改進本身的方案?你如何說服懶惰的同伴加緊工做,實現團隊的目標? 我先講一下個人方案是什麼,而後講個人方案有什麼優勢,爲何我要採起這種方案,與同伴互相交流彼此的想法。別人的意見,首先要聽懂並理解,根據本身方案的特色與需求,看是否要採納別人的意見,多與別人多交流,若是沒有采納別人的意見也要說出緣由
理論素養 你上過什麼數學,計算機或是理論課,
請舉出具體的例子,說明你學到的理論知識如何幫助你解決實際問題。
1.大學學了高等數學、機率論、數學邏輯、離散數學等
2.哪最簡單的例子,數學邏輯學的,邏輯與或在寫MD5算法的時候就很好的運用,用最簡單的式子來表示算法過程,須要用與或表達式來化簡。
自我管理 整年級你專業排名多少?
你從剛入學(大一年級)到如今的排名有變化麼?
如何解釋你的排名的變化?
1.個人專業排名波動比較大,目前專業排名第7。
2.有變化。
3.大一大二學的更多的是基礎課,專業課比較少。大一大二參加的社團也比較多。大三專業課比較多,花在學習上的時間也比較多。

2、回答問題

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

Q一、經過好的單元測試就能說明程序是好的嗎?

通過alpha階段,實際測試後發現,經過好的測試單元雖然不能說明這個程序都沒有問題,可是它能夠找出程序不少bug。項目自己就是一個不斷的找bug,修復bug的過程。能夠這樣說沒有徹底沒有bug的項目。如今咱們也知道有些bug不是bug,而是項目自己就是如此設計的。因此好的測試單元仍是很重要的,不要太糾結於它是否能夠斷定一個程序的好壞。程序的好壞應該進行效能分析,才更有信服。java

Q二、有關敏捷流程的問題--若是在第一步沒有計劃好,是否致使整個項目的失敗?

敏捷衝刺的好處就是它快,在Alpha階段開發出MVP版本就能夠,而後在進行不斷的迭代。因此第一步沒有計劃好會影響Alpha階段的具體事項,可是Alpha階段結束後它有一個總結,能夠總結在第一階段沒有計劃好,或者能夠改進的地方,而後再進入Beta衝刺極段,這樣其實對整個項目的影響不會嚴重到失敗,可能會影響項目的進度。面試

Q三、對於軟件測試方法的理解--對於現實生活中的項目,這十三種測試都須要一個個測試嗎?

關於測試真的要應項目而異,由於不一樣的項目有不一樣測試要求。拿咱們團隊Alpha階段的MVP版原本說,由於這個項目在Alpha階段還未連上數據庫,那還要進行服務器、數據庫的測試嗎?顯然就不必了,即便你測試了得出的結果也是無用的。好比測試數據庫的性能,你都沒有進行數據庫操做,如何測試?測試方法的存在提供了測試的方向,可讓剛學習測試的學員,知道能夠測試什麼,用什麼測試,測試的結果如何分析。算法

3、再提問題

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

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

Q一、針對大學生的項目開發PM的角色是否適用?

本書第194頁,做者提到後端

PM作開發和測試以外的全部事情微信小程序

可是通過Alpha階段,我發現PM在團隊項目開發的過程當中仍是須要作開發的事情。由於團隊成員沒辦法作到每一個人都有能力完成開發的事情,衝刺階段時間也趕,沒辦法空出一我的去只作PM的事情。團隊成員較少的狀況下,只能一人承擔多個角色。就拿此次衝刺階段,咱們團隊沒辦法安排出一個專門作測試的人員,隊員你們前期都是作開發的事情(包括PM),後期才轉去作測試的。因此致使了PM要作的事情不少。若是有的團隊的成員不給力,會不會最終項目都是PM一我的完成。這樣不就會出現主治醫師模式的弊病嗎?
做者在書196頁回答了問題:服務器

若是PM也來開發,是否是項目進展更快?

做者的回答是

在軟件行業發展初期,軟件都是爲了維持機器自己的運行服務,或是作科學計算,這時候也許看不出PM的做用。隨着產業的發展,軟件應用的深度和廣度、軟件的複雜度、軟件團隊的複雜度都有極大地提升了,這時候咱們須要一些人,起到溝通、交換、影響、潤滑、討價還價的做用--就像商業社會的金錢同樣--PM就是這樣的角色。

我認爲做者沒有回答到點上,這個問題問的是PM還可承擔開發的事情,來加快項目的進展,而不是問PM的重要性。我以爲在大學生開發項目,PM至關於一個小組長兼開發人員。由於PM須要對技術熟悉,你也沒辦法讓一個不會寫代碼來承擔PM的角色。

Q二、如何提升估計能力?

本書第181頁,做者提到

這時候,咱們能夠考慮參考前人的經驗,打聽一下當地人跨越大峽谷要幾天。

我第一次看到這章內容的時候以爲說得挺有道理的,就像咱們作課設的時候,問一下上一屆的學長學姐,也能夠大概對項目有必定的把握。可是咱們團隊此次作的是微信小程序,由於這個技術比較新,有關這方面能夠參考的資料,或者人比較少。
做者還說到

即便和你具體狀況有種種區別,仍是能夠做爲參考,例如你想徒步走遍全國,貌似前無古人,可是不妨看看一個騎自行車走遍全國的例子。

這種狀況就比如咱們數據庫的搭建。咱們首先網上找了有關數據庫鏈接的資料,能夠說不多有人親切的寫具體如何鏈接,至關於前人蔘考經驗幾乎爲0。那就參考相似的好比用java鏈接數據庫,這個咱們作過,以爲還挺簡單的,數據庫選的是MYSQL也接觸過。根據這些經驗,咱們團隊計劃鏈接數據庫最多兩天就能夠了吧。結果與計劃大不相同。形成這樣的結果,是咱們高估本身的能力。因此光是參考前人的經驗是不夠的。
做者又說到

另外一個辦法是快速原型法--用一兩個先鋒去探路。

首先對大學生很不友好,大學生作項目的時候選擇課題時候,並無那麼長的時間讓你去試哪一個項目的成功率更高。你們選的時候通常是先考慮項目內容而不是技術。而後選了課題後,真正要開發的時候才發現,哎呀這個技術好難啊,作不下去了。對於這種對技術瞭解不到位,沒有很好的前人蔘考經驗,如何去估計任務時間呢?

Q三、及時發佈一個可以解決用戶問題(應該說部分問題)的軟件,用戶願意使用嗎?

本書第180頁,做者提到

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

若是爲了及時發佈,發佈了一個知足部分用戶的軟件(好比書中提到的沒有複製粘貼功能的iPhone),用戶用了之後還會滿意嗎?我想起曹老師跟咱們說的一個例子。他說他有個朋友開公司的,他說開發軟件就是要先開發出開胃菜,先穩住客戶,而後再端出滿漢全席。但是,用戶用了你的開胃菜,還會期待你的滿漢全席嗎?用戶用了之後,還會想再用你的軟件嗎?

Q四、工程師有可能高效地開發一個顧客不喜歡的軟件,那麼這位工程師仍是優秀的工程師嗎?

本書第36頁,做者提到

PSP的目的是記錄工程師如何實現需求的效率,而不是記錄顧客對產品的滿意度。工程師有可能很高效地開發一個顧客不喜歡的軟件(例如用戶界面不好,功能未能解決用戶實際問題,等等),那麼這位工程師仍是優秀的工程師嗎?

我不知道這是做者對讀者的問題,仍是他以爲工程師有可能高效地開發一個顧客不喜歡的軟件,那麼這位工程師不是優秀的工程師。可是,從角色分工來講,一個軟件開發不僅僅只有開發人員還有需求調研人員,測試人員,PM等,而開發人員就是專心寫代碼的人,他是不負責除開發之外的事情。工程師開發出一個用戶不喜歡的軟件,也不能說是工程師的錯,不該該把需求分析錯誤的問題扔給沒有進行需求調研,只是根據需求規格說明書安靜的寫代碼的工程師。從企業來講,能高效的開發軟件的工程就是他們所須要的,就是優秀的工程師那麼一個工程師高效率的開發一個軟件,不就說明他是一個有優秀的工程師嗎?

Q五、關於IT行業的創新之創新就是冒險家?

在書的第16章,做者說了有關創新的八大迷思,在書347頁,做者提到

誰不喜歡創新呢?然而細細想來,創新就是作和之前不同的事情,那並非全部人都喜歡」不同「

歸根結低,都是要看創新出來的」不同「是否符合自身利益。這不意味着你的創新有可遇到失敗。就像移動公司走的TD-ScDMA的技術,理論上這個技術是很優秀的,可是移動公司推行開始技術就不成熟,又有不少新的技術出現,如4G、WLAN。這不就意味着,創新是有風險的。

可是在書347頁,做者提到

其實根據研究,創新人士的關鍵點不是喜歡冒險,也不是躲避風險,而是從錯誤中恢復繼續努力,就像文言文說的」屢戰屢敗「。

若是對於一個可能性幾乎爲0的創新,還要繼續堅持下去嗎?咱們如今知道創新成功的例子都是創新成功後,你們才知道的,可是還有不少創新後就失敗的真實案例。你們都一味的追求創新,是不是正確的?既然創新你們都想要,那麼爲何教育又是應試教育?這是否意味着,創新是冒險?

【附加題】

請將問題提交至豆瓣:https://book.douban.com/subject/27069503/
並在博客中給出連接在豆瓣頁面的最下方 「讀書筆記」 那裏發言, 《構建之法》的做者會親自答覆問題

連接:https://book.douban.com/annotation/54370216/

相關文章
相關標籤/搜索