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

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

不能 ont 我不 tsp ref 後端 有一個 bsp 產生

這個作業來自於: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章中,作者向我們介紹了蜂窩模式,明星模式,社區模式,業余劇團模式,秘密團隊,特工團隊,交響樂團模式等軟件團隊模式,每一個模式都各有所長,各有所短,而每個模式所進行的條件也不一樣,比如你所在團隊沒有明星也要硬推一個明星出來。我不禁有一個疑問,如何尋找到適合自己的團隊模式,而那種模式更有利於個人提高?


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

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