軟件工程實(shí)踐者的思想[1]
得其精而忘其粗，在其內(nèi)而忘其外；見其所見，不見其所不見，視其所視，而遺其所不視"--《列子說符》
1.語言只是工具
我曾經(jīng)是非常執(zhí)著的開發(fā)人員。我有連續(xù)幾天幾夜做Coding的經(jīng)歷，也曾經(jīng)為了一個(gè)技術(shù)問題耗上三、四個(gè)星期而導(dǎo)致項(xiàng)目一再延遲，還曾經(jīng)為了一個(gè)實(shí)現(xiàn)細(xì)節(jié)與項(xiàng)目相關(guān)的人員逐一爭論。
我也曾經(jīng)像大多數(shù)開發(fā)人員一樣熱衷于爭論語言之間孰優(yōu)孰劣。我在論壇上寫過一個(gè)簡介，其中個(gè)人特長是"擅長TPascal、Delphi、TASM系列語言，痛恨C/C++".我至今保留這段文字，因?yàn)槟堑拇_是真實(shí)的經(jīng)歷。
如今我已經(jīng)不再專注于語言，正如我在第一章中寫到的一樣：成天討論這門語言好，或者那門語言不好的人，是可悲的。
然而就在我寫這段文字之前的一年，我還是無止盡地深入語言細(xì)節(jié)，深入操作系統(tǒng)細(xì)節(jié)，以及深入……開發(fā)的細(xì)節(jié)。
就在2004年3月間，我接受一個(gè)朋友的邀請，去北京做一個(gè)專題培訓(xùn)。我用了近兩周的時(shí)間，做了50頁的幻燈，全面講述Delphi和Delphi.NET.然而在臨行前的一晚，我輾轉(zhuǎn)反側(cè)，思考著一個(gè)問題：我究竟做了些什么？或者說，我究竟想告訴學(xué)員些什么？
凌晨5點(diǎn)，我在幻燈的末頁后插入了一張幻燈，標(biāo)題是"語言只是工具",而幻燈的內(nèi)容是一張圖。這是與培訓(xùn)完全無關(guān)的一張幻燈。然而，這是自1997年我接觸到管理，以及從1998年我接觸到工程以來，第一次正視"軟件工程"這四個(gè)字。我第一次看清楚代碼、方法、過程、工程與組織的關(guān)系！
對于一個(gè)程序員，或者以程序員自命的人來說，看清楚這一切的第一步，竟是一句"語言只是工具"!
猿之于為人，"學(xué)會制作和使用工具"是最重要的標(biāo)志。因而我不知道"語言只是工具"這句話，究竟是對語言的膜拜，還是漠視。然而從那一刻開始，我才真正地知道工程。
2.程序
在我的那個(gè)圖中，在最內(nèi)層的環(huán)里，是"程序=算法+結(jié)構(gòu)".這是編程的本源定義，也是原始的狀態(tài)。與代碼相關(guān)的任何工作，最終仍舊會落足于這樣的`一條規(guī)則。
編程的精義于此。從有開發(fā)行為開始，它就存在。挖山不止的愚公在數(shù)千年前就在用類似的行為做編程實(shí)踐，而幾十萬年前的智人，也在循環(huán)與分支所構(gòu)成的邏輯中打轉(zhuǎn)。
3.方法
推動這種邏輯向前發(fā)展的是"方法"和"方法論".長期編程實(shí)踐，自然的推演與總結(jié)，必須沉淀為某種（軟件開發(fā)）方法，于是"過程"出現(xiàn)了，"對象"出現(xiàn)了，相關(guān)的方法論也就出現(xiàn)了。
這是實(shí)踐的成果。方法不是某個(gè)人或者某個(gè)組織創(chuàng)造的。瓜熟而蒂落，實(shí)踐積累達(dá)到一定的程度，就算微軟不提出某個(gè)方法，IBM也會提出這個(gè)方法。即便他們都不提出，可能你自己已經(jīng)在使用這個(gè)方法了。
方法并不神秘，因?yàn)樗褪悄憬裉煺谧龅�、從事的和�?shí)現(xiàn)的。正如"模式"是一種方法，而模式就是你昨天書寫代碼的那個(gè)行為。只不過，GoF歸納、抽取、提升了這些行為的內(nèi)在規(guī)律。你看不到你做事的行為，也就不能理解"模式"作為一種方法的價(jià)值。所以大師們眾口一詞：模式需要一定的編程經(jīng)驗(yàn)才能理解。
同理，理解過程也需要編程經(jīng)驗(yàn)，理解對象也需要編程經(jīng)驗(yàn)，理解MDA與SOA還是需要編程經(jīng)驗(yàn)。
這可能就發(fā)生在你回顧上一行精彩的代碼，或者上一個(gè)失敗的項(xiàng)目的一瞬息。經(jīng)驗(yàn)來源于回顧、理解與分析，而不是你將要寫的下一行代碼。
有人在寺院掃了一輩子的落葉而得道，也有人因?yàn)橐痪湓挾玫馈?/p>
GoF因?yàn)闊o數(shù)次的代碼回顧而得道。
4.過程
過程隨生工程出現(xiàn)。過程解決的是工程中角色間的關(guān)系問題。
過程說的是很多人（團(tuán)隊(duì)）如何組織在一起進(jìn)行開發(fā)。它首先把工程中的各個(gè)環(huán)節(jié)分解出來。這樣，有了環(huán)節(jié)，就有了角色；有了角色，就有了溝通。因此過程中的問題，就是角色、溝通和環(huán)節(jié)的問題。
哪些環(huán)節(jié)更重要取決于具體的編程行為，也就是具體的項(xiàng)目。
例如產(chǎn)品開發(fā)的周期可以一再拖延，因?yàn)閷Ξa(chǎn)品來說，更重要的是其品質(zhì)和技術(shù)壁壘。因此你可以看到暴雪公司的游戲總是一再跳票，而它從來都是將大量玩家測試和開發(fā)人員的個(gè)性特征放在第一位。相類同的，DOOM與QUAKE系列的靈魂就是在游戲引擎的開發(fā)和設(shè)計(jì)上。
如果用這樣的模式去做項(xiàng)目，可能軟件公司沒死掉，工程需求方也被拖死。試問你有看見客戶因?yàn)槟銓夹g(shù)的遠(yuǎn)景描述而憧憬嗎？不，你只會看到他們因?yàn)轫?xiàng)目的一再延遲而懊惱，而沮喪，或……暴怒。
憧憬這種事情，只會發(fā)生在那些鐵桿玩家身上。
分不清玩家與客戶的區(qū)別，對項(xiàng)目經(jīng)理來說，是可怕的。這將意味著他不能清楚地知道哪個(gè)環(huán)節(jié)更加重要。
角色的確定，以及角色間的溝通問題，在項(xiàng)目過程中同樣重要。工程組織是否合理，相互協(xié)作是否緊密，是這個(gè)項(xiàng)目成功的保障。
"合作無間"通常是流于書面報(bào)告中的措辭。真正的"無間",應(yīng)當(dāng)是溝通的結(jié)果。然而UML,則可能是你與客戶，以及項(xiàng)目經(jīng)理與開發(fā)人員被"離間"的第一因素。
【軟件工程實(shí)踐者的思想[1]】相關(guān)文章：
《軟件工程思想》讀后感11-21
軟件工程論文的提綱12-02
試論軟件工程的應(yīng)用10-05
軟件工程思想在應(yīng)用型高校畢業(yè)設(shè)計(jì)中應(yīng)用研究11-02
大家的日語1第1課11-06
軟件工程碩士的論文09-25
軟件工程應(yīng)用淺析10-05
軟件工程碩士的開題報(bào)告10-24
accp軟件工程師的介紹10-31