阅读作业2王冬篇
No Silver Bullet - Essence and Accidents of Software Engineering:
? ??銀彈能殺死狼人。如果我沒(méi)記錯(cuò)的話,在漫畫中柯南對(duì)黑暗組織而言就是一顆銀彈。生活中是不是真的有銀彈我還是不太確定。假如有,銀彈就是
一點(diǎn)弱點(diǎn)也沒(méi)有么?如果有,能抓住銀彈弱點(diǎn)的又被稱為什么?
在《No Silver Bullet》中,強(qiáng)調(diào)了由于軟件的復(fù)雜性本質(zhì),而使真正的銀彈并不存在;所謂的沒(méi)有銀彈是指沒(méi)有任何一項(xiàng)技術(shù)或方法可使軟件工程的生產(chǎn)力在十年內(nèi)提高十倍。所以我覺(jué)得這篇文章不是在陳述沒(méi)有銀彈這個(gè)事實(shí),而是希望我們?cè)谕瓿绍浖こ痰臅r(shí)候不需要銀彈。我們應(yīng)該組織好開發(fā)團(tuán)隊(duì),選擇最合適的開發(fā)模式。其實(shí)人人都是銀彈就做到了No Silver Bullet。
真正好的項(xiàng)目,需要便捷的開發(fā)技術(shù),但沒(méi)有一種技術(shù)能徹底的舍棄了人的存在。我們不能忘記的重要事實(shí)是,軟件是為了方便人類而被創(chuàng)造的。
?
?Managing the development of large software systems: concepts and techniques
這是后來(lái)大家說(shuō)的 “瀑布模型”,它有什么特點(diǎn)?
根據(jù)原文,完整的瀑布開發(fā)模式應(yīng)該是這樣的:
?
瀑布模型有以下特點(diǎn):
為項(xiàng)目提供了按階段劃分的檢查點(diǎn);當(dāng)前一階段完成后,只需要去關(guān)注后續(xù)階段。這個(gè)特點(diǎn)決定了瀑布模型的適用范圍:不適用于經(jīng)常改動(dòng)需求的項(xiàng)目;可在迭代模型中應(yīng)用瀑布模型。迭代1解決最大的問(wèn)題。每次迭代產(chǎn)生一個(gè)可運(yùn)行的版本,同時(shí)增加更多的功能。每次迭代必須經(jīng)過(guò)質(zhì)量和集成測(cè)試。
但是瀑布模型還有以下特點(diǎn):
在項(xiàng)目各個(gè)階段之間極少有反饋;只有在項(xiàng)目生命周期的后期才能看到結(jié)果;通過(guò)過(guò)多的強(qiáng)制完成日期和里程碑來(lái)跟蹤各個(gè)項(xiàng)目階段。?
瀑布模型對(duì)很多類型的項(xiàng)目而言依然是有效的,如果正確使用,可以節(jié)省大量的時(shí)間和金錢。對(duì)于我們的項(xiàng)目而言,是否使用這一模型主要取決于是否能理解客戶的需求以及在項(xiàng)目的進(jìn)程中這些需求的變化程度,對(duì)于經(jīng)常變化的項(xiàng)目而言,瀑布模型毫無(wú)價(jià)值。
在瀑布模型中,軟件開發(fā)的各項(xiàng)活動(dòng)嚴(yán)格按照線性方式進(jìn)行,當(dāng)前活動(dòng)接受上一項(xiàng)活動(dòng)的工作結(jié)果,實(shí)施完成所需的工作內(nèi)容。當(dāng)前活動(dòng)的工作結(jié)果需要進(jìn)行驗(yàn)證,如果驗(yàn)證通過(guò),則該結(jié)果作為下一項(xiàng)活動(dòng)的輸入,繼續(xù)進(jìn)行下一項(xiàng)活動(dòng),否則返回修改。?
其實(shí)不管是瀑布模型還是什么別的模型,都是被有意簡(jiǎn)化,以幫助我們解決真實(shí)生活中遇到的問(wèn)題。
big ball of mud
你的項(xiàng)目有一個(gè)大泥球么? 有什么解決辦法??
大泥球,是指雜亂無(wú)章、錯(cuò)綜復(fù)雜、邋遢不堪、隨意拼貼的大堆代碼。
其實(shí)很多軟件都是靠著大泥球完成的。我覺(jué)得大泥球之所以有這么強(qiáng)的生命力,肯定有他的可取之處。比如雖然肉體上的工作量大,但是思想上的工作量小;比如他的邏輯簡(jiǎn)單,易于快速構(gòu)造。同時(shí)弊端也是顯而易見的。在現(xiàn)實(shí)生活中很多時(shí)候無(wú)論花費(fèi)多少時(shí)間試圖去找出完美的軟件結(jié)構(gòu),客戶總是引入一個(gè)變化破壞這個(gè)結(jié)構(gòu),不存在完美結(jié)構(gòu),只存在那些試圖平衡當(dāng)前的代價(jià)和收益的結(jié)構(gòu)。有時(shí)候,程序員把原因歸咎于客戶,責(zé)怪他們總是改變需求。但是這不是他們的錯(cuò)誤,他們只是在思考一種最合理、有效的方式為自己的工作服務(wù)。
但是,客戶連源代碼都看不到,這種怨念卻是沒(méi)道理的。當(dāng)我們接收時(shí)間管理助手的時(shí)候感覺(jué)就是一個(gè)大泥團(tuán)。沒(méi)有注釋,沒(méi)有文檔,很難看懂一段代碼對(duì)應(yīng)哪塊功能。但是還是得慢慢的看,理解。我們的解決辦法是每人負(fù)責(zé)一小塊,將大泥球分成小泥球,然后再解決這個(gè)小泥球,這項(xiàng)相對(duì)容易些。但這樣也會(huì)出現(xiàn)一些問(wèn)題。如果我的“小泥球”里的一些東西牽扯到別人的”小泥球“,那么我就很難做下去。所以加強(qiáng)組員的溝通對(duì)解決大泥球也很重要。?
CatB – Cathedral and the Bazaar
你的團(tuán)隊(duì)是用什么方式建造軟件?
Lost in CatB.
這些情況在你的團(tuán)隊(duì)中出現(xiàn)過(guò)么?
? 所謂的大教堂模式(The Cathedral model):源代碼在本模式是公開的,但在軟件的每個(gè)版本開發(fā)過(guò)程是由一個(gè)專屬的團(tuán)隊(duì)所控管的。
市集模式(The Bazaar model):源代碼在本模式也是公開的,不過(guò)卻是放在互聯(lián)網(wǎng)上供人檢視及開發(fā)。
根據(jù)我對(duì)閱讀材料的理解,我們團(tuán)隊(duì)的開發(fā)模式應(yīng)該是Cathedral模式。好像與Cathedral and the Bazaar?的傾向相左。
大教堂模式的優(yōu)點(diǎn)是團(tuán)隊(duì)內(nèi)比較凝聚,可以集中到一個(gè)點(diǎn)。而我們做的項(xiàng)目相對(duì)比較小,適合團(tuán)隊(duì)集中解決。
? 在《A Generation Lost in the Bazaar》中,作者卻報(bào)以不同的觀點(diǎn),警醒我們不要在市集模式中迷失。他認(rèn)為,Raymond在其書中稱頌的集市模式導(dǎo)致的悲哀的現(xiàn)實(shí):“一坨膿包似的權(quán)宜代碼,被一群盲目的根本不知IT架構(gòu)為何物的所謂IT“專業(yè)人士”永無(wú)休止地復(fù)制著,粘貼著。”
這確實(shí)一個(gè)問(wèn)題,但出現(xiàn)這個(gè)問(wèn)題的原因不是模式不夠完善,而是程序員自己的原則性不夠強(qiáng),如果每個(gè)程序員對(duì)自己所用的代碼都了然于胸,不可能出現(xiàn)這種情況。
Agile Method – by Martin Fowler
你的團(tuán)隊(duì)在開發(fā)中用了那些敏捷的思想和做法?
?
先總結(jié)一下原文章里的一些我覺(jué)得有意義的觀點(diǎn):
在所有敏捷開發(fā)方法中,XP(Extreme Programming)是最引人注目的,它適用于需求快速變動(dòng)背景下的中小規(guī)模的開發(fā)團(tuán)隊(duì)。極限編程弱化針對(duì)未來(lái)需求的設(shè)計(jì),非常注重當(dāng)前的簡(jiǎn)化。因此,極限編程適合規(guī)模小、進(jìn)度緊、需求變化大、質(zhì)量要求嚴(yán)的項(xiàng)目。它希望以最高的效率和質(zhì)量來(lái)解決用戶目前的問(wèn)題,以最大的靈活性和最小的代價(jià)來(lái)滿足用戶未來(lái)的需求,極限編程在平衡短期和長(zhǎng)期利益之間做了巧妙的選擇。極限編程的特點(diǎn):
1.極限編程方法從整體團(tuán)體的開發(fā)小型的系統(tǒng)等方面解決了這些問(wèn)題。
2.極限編程使用了發(fā)布計(jì)劃的方法。使得開發(fā)人員能對(duì)前一階段的開發(fā)成果進(jìn)行評(píng)估,更好地把握后面工期的任務(wù)安排
3.極限編程方法尤為強(qiáng)調(diào)面對(duì)面的溝通,通過(guò)現(xiàn)場(chǎng)客戶、站立會(huì)議、結(jié)對(duì)編程等方式來(lái)保證溝通的有效。
我們團(tuán)隊(duì)在開發(fā)時(shí)間管理助手的時(shí)候有采用極限編程方式,比如會(huì)采用類似Pairwork的方式集中解決一個(gè)問(wèn)題。還有在做團(tuán)隊(duì)項(xiàng)目的時(shí)候每天更新Daily?Scrum以加深組員之間的了解等都符合敏捷開發(fā)模式。
轉(zhuǎn)載于:https://www.cnblogs.com/WWW-Buaa/archive/2012/11/18/2776611.html
創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來(lái)咯,堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)總結(jié)
- 上一篇: C++ Primer 第10章 习题10
- 下一篇: [转]迭代、集合、字典表和列表