1. 程式人生 > >第3次作業:閱讀《構建之法》1-5章

第3次作業:閱讀《構建之法》1-5章

class a span 第三章 系統 根據 倍增 國內 維護 內存

這個作業的要求來自於:https://edu.cnblogs.com/campus/gzcc/GZCC-16SE2/homework/2178


第一章:概論

  看了第1章的內容,了解到軟件工程是把系統的、有序的、可量化的方法應 用到軟件的開發、運營和維護上的過程。這一章主要講解了軟件工程的基本內涵。我比較認同文中程序 (算法、數據結構)是基本功,軟件工程決定了軟件的質量這個觀點。在1.1節中提到用二叉樹的遍歷算法,二叉樹是數據結構,遍歷的實現是算法,但是單獨的這個程序在實際中的用處似乎並不大,而軟件工程就可以使這個程序合理的應用在特定的場景。

  軟件開發應用到軟件工程的思想,通過合理規劃軟件開發的流程,就能使軟件開發的成本大大減少,書中提到工程師的宗旨時:我構建,故我在

,我有點不太理解,軟件工程和機械工程、航空工程等工程學科一樣,其中也有工程理論、質量控制論的原理,是一門偏理論的學問,我查了一下資料,有人做了這樣的比喻,軟件工程主要是設計,就象蓋大樓之前畫那個設計圖;軟件技術主要是編程,就象蓋大樓的人,所以一名優秀的軟件工程師,除了不斷學習做開發前的設計之外,需不需要更多的提高自己軟件開發的能力,還是說到達某一階段止步就好?


第二章:個人技術和流程

  看了第2章的內容,了解到單元測試、回歸測試、效能分析、個人軟件開發流程(PSP)的一些基本概念和技術。

  在2.2節效能分析工中提到大家也要註意避免沒有做分析就過早地進行“效能提高”,如果我們不經分析就盲目優化,也許會事倍功半。

效能分析是根據影響效能的主要因素,運用一般系統分析的方法,在收集信息的基礎上,確定分析目標,建立綜合反映某事物達到規定目標的能力測度算法,最終給出衡量某事物效能的測度結果。那應該在什麽時候進行效能提高呢?我了解了一下關於效能的評估,對於一個程序(效能來說)的評估,主要從時間和空間來進行考慮的。時間是指程序運行的時間,稱為時間復雜度,空間方面則是指程序在計算機內存所占用的時間大小,稱為空間復雜度。

其中有一些在開發時提高效能的小技巧:

1、少用多層循環嵌套,據一同學透析他接盤的一老項目,發現了一個套了至少五六層循環,且每層循環中 包含了 數量不一的sql 查詢。 運行一次要好幾分鐘 ,好像是輸出表報的一個功能。如此糟糕的代碼,且無註釋,當事人寫完以後也難以記清邏輯。


2、循環中創建對象,可以在循環外 定義一個 對象 Class A,在循環中在進行初始化 new ClassA();
3、變量應該在 使用的時候在去定義 ,而不是全局。

這是在編程細節上進行的效能提高,那整個項目的的效能提高又應該從什麽時候開始呢?


第三章:軟件工程師的成長

  看了第3章的內容,了解到了一些衡量一個優秀的軟件工程師的標準以及成長的方向。

  在3.1節中提到初級軟件工程師應該從幾方面的成長,首先是積累軟件開發相關的知識,提升技術技能;其次需要積累問題領域的知識和經驗;再次是對通用的軟件設計思想和軟件工程思想的理解;從次是提升職業技能,包括自我管理的能力,表達和交流的能力,與 人合作的能力,按質按量完成任務的執行力等,最後些實際的工作成果。其中對實際成果的衡量給出了很詳細的評價標準,如:項目大小、花費時間、質量以及按時交付等因素。

  這裏提到隨著經驗的增長,一個工程師可以掌握更廣 泛、更深入的技術和問題領域的知識,那一名優秀的軟件工程師,需要了解多少其他領域的知識,以及需要掌握的領域又是哪些?比如說軟件工程師中有金融軟件工程師,是具備軟件研發基礎和金融業務知識的高級技術人才,既要懂軟件技術,又要掌握金融知識。


第四章:兩人合作

  看了第4章的內容,了解到代碼的規範和兩人合作的不同階段和技巧。

  如果個別人使用了不同的風格,以後大家在閱讀,修改代碼時就會有很多不便之處。同時團隊中制定的這麽簡單的規範都不能實施的話,會讓大家感覺不好,對以後其他工作也有影響。在本章4.5.2節中提到,在開發層次,結對編程能提供更好的設計質量和代碼質量,兩人合作解決問題的能力更強。在結對編程中,因為有隨時的復審和交流,程序各方面的質量取決於一對程序員中各方面水平較高的那一位。我覺得這個觀點稍微有點片面了,因為每個人擅長的東西不一樣,有些人擅長布局和UI設計,有人擅長算法,而一個程序的質量不是說界面好看就水平高了,也不是說只有功能而沒有好看的視圖給到用戶體驗也不好,只能說只有在團隊中發揮自己最大的作用,充分利用團隊裏每個人的優勢,才能使程序達到最大。找了一下百度,無論是對開發團隊還是對於個人,結對編程都會是非常不錯的註意。

  下面是一些結對編程的優點:

  1. 程序員互相幫助,互相教對方,可以得到能力上的互補。
  2. 可以讓編程環境有效地貫徹Design。
  3. 增強代碼和產品質量,並有效的減少BUG。
  4. 降低學習成本。一邊編程,一邊共享知識和經驗,有效地在實踐中進行學習。
  5. 在編程中,相互討論,可能更快更有效地解決問題。

第五章:團隊和流程

  看了第5章的內容,了解到軟件的團隊模式和軟件的開發流程,一個良好的團隊模式和開發流程能夠使軟件開發事半功倍。

  團隊成員有各自的分工,互相依賴合作,共同完成任務,軟件團隊有各種形式,適用於不同的人員和需求,基於直覺形成的團隊模式未必是最合適的。本章5.2節中提到的團隊模式有主治醫師模式,明星模式,社區模式,業余劇團模式,秘密團隊,特工團隊,交響樂團模式等等,有這麽多的團隊模式,那哪一種模式才適合某個團隊呢,是自然形成的與以上或未提及的團隊模式相似的模式好,還是在進行組織團隊時就定好一個團隊模式方向去發展好,但是每個團隊都有各自的特殊性,不一定會按照原方向發展。書中還提到很多軟件公司的團隊最後都演變成功能團隊,簡而言之,就是具備不同能力的同事們平等協作, 共同完成一個功能。那就是說大部分的團隊都會往功能團隊模式發展嗎。

  一支程序開發團隊之所以成立,是為了承擔並完成某項由任何個人都無法獨立完成的任務。因為只有團隊合作,才能將復雜的事情變得簡單,將簡單的事情變得容易,使做事的效率倍增,可以說,團隊合作正推動企業向簡單化、專業化、標準化的方向發展。在軟件這個特殊的行業,更需要如此,國內的軟件企業長不大,出不了好的產品,第一大原因就是管理,第二大原因可能就是沒有一個出色的團隊。組建團隊的目的是希望通過最小的代價獲得最佳的開發效果。不管怎樣只要是團隊中的每個人能做好自己的事情,並能不斷的和別人交流,那麽這個團隊就是成功的。


總結

  閱讀《構建之法》第1-5章的知識內容後,獲益匪淺,慢慢的對軟件工程有了一些模糊的理解,了解到了軟件工程的目標是提高軟件的質量與生產率,最終實現軟件的工業化生產。質量與生產率之間有著內在的聯系,高生產率必須以質量合格為前提。通過工程化的思想,能夠使軟件開發更高效。還了解到了在軟件開發中團隊合作的重要性,還有對軟件的開發流程有了重新的認識,一個優秀的產品,需要一個完整的開發流程,先理清用戶需求再進行程序的開發和維護,而不是直接就開始寫代碼後期又一點一點地改。在團隊合作中需要每個成員的協調,使團隊發揮最大作用,才能大大提高開發產品的質量。

第3次作業:閱讀《構建之法》1-5章