天天看點

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

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

第一章:概論

這一章主要介紹計算機科學的領域,軟體工程與計算機科學的關系,軟體的特性,軟體工程的定義與組成部分

  在這一章中,提出了一個理論,軟體=程式+軟體工程。這讓我認識到,軟體開發不是單單閉門造車的,除了單單做好程式本身功能之外,他的軟體開發活動(建構管理,源代碼管理,軟體設計,軟體測試,項目管理),他的商業模式,甚至UI設計,使用者的互動體驗,都決定了這個軟體是不是一個好軟體。書中提到了一個詞:職業道德規範,即所謂的行規。那麼我不禁有個問題,一個IT行業從業者的職業道德規範是什麼,那麼細分到IT中的測試,架構師,前端,後端,産品經理等,他的道德規範又有什麼不同。  http://www.cnblogs.com/zhuweisky/p/4811408.html,匠心。這個部落客給了我一個不錯的答複。但是在現行的國内軟體行業環境中,996成為常态,大多數心态浮躁,大多數的軟體都是換湯不換藥,套個模又是一個新遊戲。那所謂的匠心怎樣保持。希望能得到答複。

  以前我一直對于bug的了解有所誤解,我認為隻要是使用者感覺不順心就叫bug,1.2.4中,說到一個令我茅舍頓開的觀點。軟體的行為和使用者的期望值不一樣,就叫BUG。是否是bug,取決于使用者,開發者的不同角度。書中提到一個觀點,軟體工程的重要任務,就是要在時間成本等多種條件限制條件下決定一個軟體在什麼時候能“足夠好”,可以釋出。我不禁提出一個疑問,那這個“度”是什麼,什麼時候才能叫做足夠好?它具體是怎樣判斷的,可否舉一個例子。而一個軟體什麼時候,需要重構?用A語言去重構B語言寫的程式是否證明A語言在目前環境下好于B語言?我查閱了很多資料,都沒有一個讓我明确的答案。

  還有一個書中沒有提過但我一直想知道的問題,應該是由戶主導軟體還是軟體主導使用者,因為大多數使用者都不知道自己想要的是什麼。

第二章:個人技術和流程

這一章主要介紹單元測試,回歸測試,效能分析,個人軟體開發流程

在這一章中,2.3引入了PSP這個全新的概念,這在以前的學習中是沒有了解過的,以前打代碼就圖個爽,忽略了很多方面。在表2-3大學生vs工程師中,大學生和工程師設計軟體的目的不同,那麼兩種人各階段開發所花費的時間不同也理所當然。而本書最讓我感覺和其他書不同的就是在文末中加入對PSP的批判,而不是像其他書中這樣大力推崇某種方法,“報喜不報憂”。但我有一個問題,表中的資料是2011年的,在日新月異的IT行業已經過去了7年。現在大多數軟體都要去争取“風口”留給軟體開發者的時間往往不是很多,可能你花費太多時間在分析需求階段,已經被其他公司搶先了,這是網際網路+老師在課上所說的話。那麼現在對于一個軟體開發時間配置設定是否應該不同。而選取的工程師平均學位為碩士,我很好奇對于大學,專科的工程師,那麼他們的時間配置設定又不一樣?

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

  評論軟體工程師水準的主要方式,技能的反面,TSP對個人的要求,軟體工程師的思維誤區

  本章3.1又引入了一個新的名詞:tsp,他對成員有7個方面的要求,(交流,說到做到,接受團隊賦予的角色并按角色要求工作,全力投入團隊的活動,按照團隊流程的要求工作,準備,理性地工作),人是社會性動物,在當今社會中,工作中和人交流是必要的。它給了個人對于團隊的貢獻一些可量化可觀察的要求,讓我可以更清晰的評判自己是否是一個合格的開發者。但對于第三點(接受團隊賦予的角色)我還是存在疑問,根據調查,在當今國内的行情中,很多公司都是一個人身負多職的,他是ui還的是前端甚至肩負測試,QA,而充斥于市場半吊子的産品經理,總會提出無厘頭的要求(比如不久前平安保險那個通過識别使用者手機殼的顔色來更換界面顔色的要求),那麼對于提出無理,不可行的要求我也要去做嗎?如果我真的履行好這麼多角色,我有能力和精力嗎?

第四章:兩人合作

代碼規範,極限程式設計,結對程式設計,兩人合作的不同階段,影響他人的技巧

  在4.1~4.4章中,主要給我們介紹了代碼和程式設計的書寫規範和複審機制。對于需要團隊合作的項目,一個良好統一的代碼規範可以降低溝通的成本。同時網際網路行業流動性大,一個成員新加入團隊,必先要閱讀代碼,統一的代碼風格和規範能減少浪費的時間成本。而我有一個問題,為什麼不全行業使用統一的代碼不是一勞永逸了嗎,不同公司有不同的代碼規範是為什麼?而很多公司,都有屬于傳說的“祖傳”代碼,它沒有注釋,邏輯混亂,但就是沒有bug,也不能随便修改,這種“祖傳代碼”産生的原因是什麼?

4.5章中,給我們介紹了結對開發的姿勢。在實際開發中,結對開發能提高雙發的工作效率,也能互相提高代碼水準。但我也有許多不解,首先國内網際網路流動性很大,如果兩個人剛配合好默契,一個就跳槽了,前期的投入不是都浪費了嗎?然後結對開發對于雙方不單單是代碼能力的要求,更多要求素質,情商,溝通能力的綜合考量,如果兩個脾氣很沖的人在一起會不會發生其他沖突?最後,每個人的精力都是有限的,有的人在早上特别精神,有的人晚上特别精神,可能你在努力工作的時候别人無精打彩,心理自然會有不平衡,要如何調節這種問題?我查閱相關資料,發現結對程式設計都對雙發的道德和技術要求都很高。是否意味着這不适合于初級的開發人員。

第五章:團隊和流程

典型的軟體團隊模式和開發流程都有哪些?各有什麼優缺點,TSP,MVP,MBP,RUP

  5.2章中,作者向我們介紹了蜂窩模式,明星模式,社群模式,業餘劇團模式,秘密團隊,特工團隊,交響樂團模式等軟體團隊模式,每一個模式都各有所長,各有所短,而每個模式所進行的條件也不一樣,比如你所在團隊沒有明星也要硬推一個明星出來。我不禁有一個疑問,如何尋找到适合自己的團隊模式,而那種模式更有利于個人提高?

不成熟的提問,聽聞作者和輪子哥很熟,可以評價一下他嗎