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

1、我的總結

  1. 在alpha 結束以後, 每位同窗寫一篇我的博客, 總結本身的alpha 過程;html

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

類別 具體技能和麪試問題 如今的回答(大三) 畢業後的回答
語言 最拿手的計算機語言之一,代碼量多少?(偏web前端,PC/Mobile App) 多是js吧,代碼量大概2千左右
語言 最拿手的計算機語言之二,代碼量多少?(偏後端,數據處理,網站後臺,機器學習,等) 應該是java,代碼量五、6千左右吧,並無就具體的算過
軟件實現 (閱讀代碼的能力,實現,單元測試)
你有沒有在別人代碼的基礎上改進,你是怎麼讀懂別人的代碼的,你採起了什麼辦法來保證你的新功能不會影響原來的功能?
你在開發中碰到最複雜的bug是什麼,你是如何解決的?
這個bug出現的緣由是什麼,你在未來應該怎麼去避免bug再出現?
1. 有在別人的代碼基礎上進行改進;
2. 若是代碼的編寫者是認識的或者是就在身邊的,會直接問她代碼的具體事項,像是代碼的變量的設置是怎麼樣的,是怎麼編寫的等等,若是代碼編寫者並非認識的話,那麼就會本身先將代碼通篇看下來,進行代碼粗略瞭解,記錄好相應的變量設置,再根據註釋進行詳細的理解。
3. 可能就是不會動代碼的主要框架,只是對其中某些模塊進行修改或者增長一些須要的模塊,主體是不變的;
4. 大概會本身先根據提示的錯誤,進行修改,若是修改後仍是不行,就會去網上搜索些資料,或者經過詢問同窗來解決問題。要是仍是不行的話,就去問老師來解決。
5. 有些bug出現的緣由有多是由於編寫時出現的錯誤,應該在編寫代碼時注意好本身編寫的代碼是否是有邏輯上的錯誤。
軟件測試 (測試方法、測試工具、測試實踐、代碼覆蓋率)
你如何測試你本身寫的代碼?
你如何測試別人的代碼?
你掌握了多少種測試工具和方法?
你寫過測試工具麼?
你如何對一個網站進行壓力測試和效能測試?
你如何測試一個軟件的人機界面(ux/ui)?
1. 通常在編寫過程當中,會經過print輸出來查看本身的代碼是否有問題。代碼編寫完後可能會經過一些測試工具對其進行測試或者經過JUnit單元測試和代碼覆蓋率來進行測試。
2. 測試別人的代碼的方式和測試本身的代碼的方式沒有什麼區別。
3. 例如JUnit單元測試和代碼覆蓋率,使用一些軟件自帶的測試工具,雲真機這些測試方法。
4. 沒有寫過測試工具。
5. emmm,自己並無作過實際可運行的網站,因此其實並無進行過相關的測試。
6. 通常可能就是找些用戶進行實際體驗和使用網上的雲真機軟件進行測試。
效能分析 效能分析,效能改進,
你寫過最複雜的代碼是什麼?
你是如何測量和改進它的效能的,用了什麼工具,如何分析的?
1. 我寫過最複雜的代碼應該是網上購物系統吧。
2. 那時候就只是使用一些軟件自帶的工具進行測試,也沒有想過要測試效能。
需求分析 (需求分析,典型用戶,場景,創新)
你作過多少個有實際用戶的項目,用戶最多有多少?
你的項目有什麼創新的地方?
1. 我作過的有實際用戶的項目,大概就只有如今在作EASY記微信小程序,用戶最多大概有30人。
2. emmm,好像沒有什麼地方是創新的,大體網上都有。
行業洞察力 你最感興趣的領域是什麼?
這個領域過去10年經歷了哪些創新?
你分析過這個領域前10名產品嗎?請分析一下他們的優點,你要進入這個領域,應該如何創新?
1. 我最感興趣的領域大概是java方面的開發。
2. 像是美團,阿里等都是使用java進行開發。
3. emmm,其實沒有分析過,大概他們的優點在於如今的行業前景比較好,比較被重視,是行業中的領頭人物,創新方面也有人才,和創新性高。應該會根據市場進行創新吧,使得他們更貼近用戶的需求。
項目管理 你參與過項目管理麼?
請描述一下兩個當下流行的開發方法在你的項目中的具體應用狀況;
請問你如何決定項目中各類任務的優先次序,有什麼理論來支持你的作法?若是你忽然發現項目不能按時完成,你做爲項目領導,有什麼辦法?
1. 參加多項目管理。
2. 咱們在項目開發的過程當中使用了敏捷開發的模式來進行,經過天天的站立會議和7天的衝刺階段,完成咱們的項目開發。
3. 我是根據任務對於咱們項目的重要程度來決定其優先次序,也會根據咱們的項目的核心功能是什麼來決定咱們要先作什麼任務。由於咱們作Alpha階段的目標結果就是完成MVP——即項目的主要任務。
4. 可能就會從新將不能按時完成的那部分任務進行分配,安排給還有能力和時間的人員來完成,而且須要延長工做時間,以確保能夠完成這項目。
軟件設計 你作過架構設計,模塊化設計,接口設計麼?
請說明一下你爲什麼是這樣設計,你比較過什麼不一樣的設計方式,你的設計取得了什麼結果?
1. 只是在java開發中作過接口設計、模塊化設計。
2. 我是將項目中一些共同的功能設置接口,這樣的話,總體的代碼會比較方便管理和並且代碼簡潔明瞭。emmm,沒有作過不一樣的設計方式,因此也就沒有比較過。
質量意識 (代碼複審/代碼規範/代碼質量)你是怎麼作代碼複審的,你加入咱們團隊後,能幫助咱們提升代碼質量麼,請具體說怎麼提升? 1. 我是根據項目開發時所制定好的代碼規範進行代碼複審,看是否代碼有符合規範,再看代碼的可讀性和是否將可能的狀況都包含在內了。
2. 大概會減小沒必要要的代碼,下降代碼的冗餘程度,規範好代碼的編寫規範。
工具/社區 Software Tools(performance tool,version control,work item,TFS)
你在各類開發平臺(web,linux,PC,mobile,machine,learning)都是用過什麼樣的工具,本身寫過什麼工具來改進工做效率?
給社區貢獻過什麼工具和代碼?Github有分享代碼麼?
你寫的技術博客堅持了多久,讀者最多的是哪一篇?
1. 有eclipse、eclipse jee、vc6.0、vs、NetBeans、微信web開發者平臺。沒有本身寫過什麼工具。
2. 通常都是些java方面的代碼和此次項目的代碼。通常是在碼雲上上傳代碼的。
3. 我寫的技術博客大概有兩年了,讀者最多的是《Java課程設計+購物車WEB頁面》。
團隊協做 Work with others(協同工做,提供反饋,說服別人)請描述你在項目中如何說服同伴採用你提出的更好的解決方案,或者你如何聽取了別人的意見,改進了本身的方案?
你如何說服懶惰的同伴加緊工做,實現團隊的目標?
1. 通常是會將個人方案會有什麼樣的結果和同伴的方案會有什麼的結果,都表述出來,用事實來講服他們,用事實告訴他們哪一種方案會更加優秀。
2. 會根據他們的提出的意見進行自我方案的審視,看否本身的方案真的出現了同伴提出的問題,而後結合他們所提出的的意見來改進本身的方案,以便可以達到最好的效果。
3. 可能會和她來一次私下的談話,將咱們任務緊迫程度告訴她,和她交談她的態度問題,而後會在她身後催着她完成任務。
理論素養 你上過什麼數學,計算機或其餘理論課,請舉出具體的例子,說明你學到的理論知識如何幫助你解決實際問題。 1. 高等數學、離散數學、線性代數、機率論、數字邏輯、操做系統等課程。
像是寫代碼時,有時候會用到一些數學知識,相似於計算水仙花數啊這樣子的。
自我管理 整年級你專業排名多少?
你從剛入學(大學一年級)到如今的排名有變化嗎?
你如何解釋你的排名的變化?
1. 大三上34名。
2. 從剛入學(大學一年級)到如今的排名有變化。
3. 主要多是學習上不是特別的主動,有惰性,致使成績起伏不定,並且很迷茫,不知道本身應該學點什麼。

2、回答問題

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

問題一:

d. 進一步說,「覆蓋率」有下面幾個層次:linux

  • 1.函數的覆蓋,這個模塊的每個函數都覆蓋了麼?
  • 2.語句的覆蓋,這個模塊的每個語句都覆蓋了麼?
  • 3.分支的覆蓋,這個模塊的每個條件分支都覆蓋了麼?
  • 4.條件的覆蓋,這個模塊的每個布爾表達式的TURE|FALSE都覆蓋了麼?

在讀2.1.2 好的單元測試的標準時,在P27中讀到了上文,做者說代碼覆蓋率須要考慮到每一個模塊是否覆蓋到了每一個函數,是否覆蓋到了每一個語句,是否覆蓋到了每一個條件分支,是否覆蓋到了每一個布爾表達式的TURE|FALSE。可是在實際的軟件工程中,在進行單元測試時,咱們真的要保證有100%的代碼覆蓋率嗎?是否只要保證了單元測試覆蓋了全部的代碼路徑以後,像是語句覆蓋之類的就能夠不用所有代碼覆蓋了呢?就像若是出現了《100%代碼覆蓋率的悲劇》中提到的狀況那樣,某段代碼功能看起來很簡單,沒有條件,沒有循環,沒有轉換,沒有任何複雜的東西,只是一段簡單的老膠水代碼。那麼這時候咱們也須要對它們進行代碼覆蓋,進行測試嗎?這類的代碼咱們是否也要對它們保證徹底覆蓋呢?程序員

  • 答:對於咱們在開發過程當中來講,單元測試是一種保證代碼質量的手段,可是即便如此咱們也沒必要過於教條主義,不必定非要達到100%的覆蓋率,想要達到最好的單元測試的效果,得到代碼質量高,這主要的關鍵就是咱們須要在軟件的質量、開發進度、開發成本之間達到一個平衡,若是僅僅一味要將單元測試的覆蓋率達到100%,有時候並不能開發出好的軟件,反而浪費了時間和精力。

問題二:

在結對編程中,由於有隨時的複審和交流,程序各方面的質量取決於一對程序員中各方面水平較高的那一位。web

在讀4.5.2 爲何要結對編程時,在P85頁讀到了上文的內容,做者說兩人結對編程時,程序的質量將取決於水平較高的一位,也就是說在編程過程當中是由水平較高的程序員做爲主導。可是這樣的話,在進行編程的過程當中,是否會出現水平較高的程序員長時間的掌控着鍵盤,而水平較低的程序員是否也會以爲由水平高的寫代碼可以更好地完成項目或者課設,而後本身基本上沒有作什麼核心任務這種狀況呢?那麼到項目結束時,就會出現不會的人仍是不會,會的人更加會了的狀況。像這樣的狀況在咱們的課設中也是能夠看到的。若是咱們想要避免出現這樣的狀況,那麼在編程初期咱們應該怎麼樣分配工做纔可以保證即有質有量地完成編程任務,不會出現代碼來不及寫的狀況,又可以讓兩我的都可以都參與到主要代碼的編程中?怎麼樣的工做量纔可以讓結對編程的兩我的都可以有所收穫呢?面試

  • 答:進行結對編程時,想要恰如其分地發揮出兩我的優點,將任務很好地完成,那麼就須要咱們把控好與結對對象之間合做的度。並且首先咱們在選擇結對對象時,就應該瞭解好咱們要選擇的對象,看是否她真的適合做爲咱們的合做搭檔。其次,在開始進行項目編程時,就應該根據兩人之間的能力進行了解,根據兩人的實際狀況來分配每一個人的勞動量,這樣就能夠避免有人會由於多作而以爲吃虧或者是不爽,也避免了代碼寫不完,出現任務無法完成的狀況。並且咱們在進行一個項目時,並不是必定要教條式的自始至終進行結對,尤爲是在項目初期選擇一些模塊進行結對便可,結對主要仍是讓水平低的能跟着水平高的養成良好的習慣,造成統一的規範,並非但願水平低的同窗能夠一會兒達到特別高的水平。

問題三:

獲得了需求以後,軟件團隊就要考慮實現這些需求。一個公司可能有多種軟件產品和服務,它們各有不一樣的戰略意義。一個軟件或服務也由不少功能組成,它們有機地結合起來,才能解決用戶的問題,產生效益。算法

在讀8.5 功能的定位和優先級時,在P171頁讀到了上文的內容,做者說開發一款軟件須要在需求分析時將所收集到的用戶的需求按照不一樣的着重點來開發不一樣的功能。可是咱們要如何來肯定每項功能的優先級呢,如何肯定那種功能是這款軟件的殺手功能呢?是根據市場上其餘軟件的使用狀況來決定,仍是根據對目標人羣的調查來決定?並且根據書上P174—P175中的三幅圖來看,咱們是否是不只僅要將殺手功能決定好定位,並作好它,還須要在這基礎上添加一些市面上同款軟件沒有的功能呢?就像咱們在去餐廳就餐時,若是有一家餐廳衛生又好吃,還不時有些小活動,咱們通常都愛去那吃,那麼在開發軟件上也應該要作到這樣的吧,這樣纔可以產生效益。數據庫

  • 答:若是咱們是開發的話,那麼在初期時,咱們就暫時不要把精力放在殺手功能的肯定和開發這個上面,咱們所須要的是安安心心、老老實實地把產品經理定義好的功能實現出來,作到軟件沒有bug,擁有良好的性能這就很成功了。若是咱們要開發咱們軟件的殺手功能至少應該在咱們軟件開發初期結束以後,根據市場的實際狀況來進行開發,不只僅要根據市面上同類型的軟件進行開發,還應該根據咱們的目標人羣的需求進行開發。可是咱們並非要在本身的軟件中添加上多少的功能才能夠,要知道咱們在軟件的核心功能的開發上是沒有止境的,並非說咱們作到什麼程度就算作好了,而是咱們要不斷根據實際來發展咱們的核心功能,而且一個好的軟件並非靠功能堆出來的,並非咱們把軟件的功能作的有多少多,就能夠把咱們的軟件作的有多出色。

問題四:

好的用戶體驗固然是全部人都想要的,若是它和產品的質量有衝突,怎麼辦?犧牲質量去追求用戶體驗麼,用戶能接受嗎?編程

在讀12.1.6 用戶體驗和質量時,在P269頁讀到了上文的內容。確實,在開發軟件時或者是更新軟件時,不免會遇到上述的狀況。若是用戶的需求,用戶的體驗和咱們的優化的功能或者軟件起衝突了,那麼咱們是該顧着用戶的需求呢,仍是繼續推出優化軟件?做者在這段話後面引用了一個案例來講明瞭做者本身的答案,可是彷佛太片面了,並非全部的狀況均可以是顧用戶的需求,舍功能的優化的。而且當二者利弊都差很少時,咱們該怎麼選擇呢?是否能有個準則來讓咱們衡量呢?

  • 答:通常來講用戶體驗屬於錦上添花,俗話說:「皮之不存,毛將焉附」,若是咱們不可以將咱們的軟件推陳出新,進行優化,那麼咱們的軟件早就被市場淘汰了,哪裏要會有什麼用戶體驗,並且一千個讀者,就會有一千個哈姆雷特,不一樣的用戶對於咱們的軟件的體驗想法也是會不一樣的。不少問題都沒有標準答案,須要咱們根據具體的狀況去斷定,看是否大部分用戶都對此次的優化不滿意,是否不改進這一點會影響咱們軟件的市場份額和軟件使用率呢,若是關係重大,那麼咱們就應該考慮用戶的意見。

問題五:

能夠看出,在算法和數據庫領域,創新的想法一開始每每不被接受,而那些創建在前人基礎上的「線性擴展」則每每有着更好的命運。

在讀16.1.2 迷思之二:你們都喜歡創新時,在P349-P350頁讀到了上文的內容,結合前文的內容,不難看出做者認爲更新升級每每比起創新更容易讓人們接受。確實,就像是若是你還不容易學會了某種經常使用的編程語言,例如C語言,java等,結果一段時間後,開始使用某種新的編程語言進行編程了,又只能從頭學起了,這樣的話,確實只是更新會比創新更讓人接受。可是,若是僅僅只是更新換代,不進行技術的創新的話,那麼科技的發展就只能停留不前了。咱們如今的社會不也是一步步從原來的創新中創建起來的嗎?若是咱們否認了創新,那麼咱們是否是也否認了如今呢?那麼咱們該如何打破人們對於創新的偏見呢?

  • 答:其實創新和升級歷來就不是矛盾和對立的。有時候,一些事物升級到了必定的地步,當它不可以再繼續升級時,那麼就會出現一次關於這個事物的創新。就像是計算機的內存同樣,當它升級到了極點,再也匹配不上cpu的運行速度時,那麼必然會出現一次新的改革,一次關於它的創新。因此其實他們二者之間並非矛盾與對立的。

3、再提問題

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

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

    ###問題一:

    單元測試必須由最熟悉代碼的人(程序的做者)來寫。

    在第2章的P26中講述到,單元測試必須由最熟悉代碼的人(程序的做者)來寫。emmm,大部分來講,我仍是贊同這個觀點的,畢竟代碼的做者是最瞭解代碼的目的、特色和實現的侷限性,由代碼的做者來寫單元測試是再好不過了。可是,是否是有時候每每會由於這代碼是本身寫的,本身的想法就已經侷限在這裏面了,就沒有意識到某些問題呢?這時候是否是就須要有其餘人來提供他們的幫助或者是關於這個代碼的測試意見呢?是否是這個也是必要的呢?仍是隻要有代碼做者的想法就夠了呢?

    ###問題二:

    帶領其餘成員確保項目保持功能/時間/資源的合理平衡,跟蹤項目進展,確保團隊發佈令客戶滿意的軟件。

    在第9章中講述了關於項目經理的相關知識,像是在P198中講述了一些關於PM在一個項目中的具體任務。可是在我看到第6小點時,我有了這個問題——PM須要帶領其餘成員確保項目保持功能/時間/資源的合理平衡,可是PM應該從什麼角度上確保PM決定的是對的呢?怎麼樣纔是真正合理的平衡?是否須要想我查找到的《產品開發項目的離散時間/成本/質量平衡問題研究》這篇文章中提到的那樣——「根據產品開發項目的特色,經過人力資源價格計算產品開發項目成本,採用質量功能展開技術對項目質量進行量化計算。」來進行計算項目的平衡嗎?仍是根據PM本身的感受走就行了?

    ###問題三:

    軟件的開發過程有三個主要的特性:「好」、「快」、「便宜」。

    在第14章中的P311中提到了軟件的開發過程有三個主要的特性:「好」、「快」、「便宜」。可是我看了這句話後,有個疑惑是否軟件在開發過程當中,如何確保在開發進程快又成本便宜的狀況下,軟件的功能又好?軟件的質量與「快」、「便宜」相關,那麼咱們該怎麼來平衡三者的關係,如何取得一個平衡點呢?並且若是像是書上P313中所說的那樣,咱們採用CMMI模型管理項目的理論的話,那麼是否咱們的軟件就必定能夠達到最佳值?

    ###問題四:

    軟件團隊如何作人員的績效管理?

    在第17章中的P403中提到了關於團隊任務結束以後進行績效管理的問題,就像書中問的那樣軟件團隊如何作人員的績效管理?有時候團隊人員作的事情是相互依賴的,有些事情並非一我的獨立作完的,那麼咱們就不可以從功能的用戶喜好程度或功能的好壞來評價。並且若是是根據工做量來進行績效管理的話,咱們該怎麼樣來肯定每人的工做量呢?若是是根據每人完成的任務數來肯定,可是那樣又會出現每人完成的任務困難度不同,按任務數來肯定又不太公平。那麼咱們應該怎麼來給每人肯定他們的績效呢?

    ###問題五:

    在Beta階段中,須要咱們換掉一個成員,再加入一個成員。那麼這種機制真的對於咱們來講有幫助嗎?本來已經磨合好的團隊,又由於換人機制,致使團隊又得從新磨合,並且還得分出時間來幫助新進組的成員儘快熟悉項目,可是不是從頭跟到尾的話,是否是會對這個項目的理解會比較困難,出現不可以理解咱們的意圖的狀況?並且咱們又怎麼肯定將哪位成員換掉呢?是否是就是將貢獻最少、能力最差的成員換出去呢?這樣是否是對那位成員不太好呢?

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

相關文章
相關標籤/搜索