軟件工程實(shí)踐者的思想[1]

得其精而忘其粗，在其內而忘其外；見(jiàn)其所見(jiàn)，不見(jiàn)其所不見(jiàn)，視其所視，而遺其所不視"--《列子說(shuō)符》

1.語(yǔ)言只是工具

我曾經(jīng)是非常執著(zhù)的開(kāi)發(fā)人員。我有連續幾天幾夜做Coding的經(jīng)歷，也曾經(jīng)為了一個(gè)技術(shù)問(wèn)題耗上三、四個(gè)星期而導致項目一再延遲，還曾經(jīng)為了一個(gè)實(shí)現細節與項目相關(guān)的人員逐一爭論。

我也曾經(jīng)像大多數開(kāi)發(fā)人員一樣熱衷于爭論語(yǔ)言之間孰優(yōu)孰劣。我在論壇上寫(xiě)過(guò)一個(gè)簡(jiǎn)介，其中個(gè)人特長(cháng)是"擅長(cháng)TPascal、Delphi、TASM系列語(yǔ)言，痛恨C/C++".我至今保留這段文字，因為那的確是真實(shí)的經(jīng)歷。

如今我已經(jīng)不再專(zhuān)注于語(yǔ)言，正如我在第一章中寫(xiě)到的一樣：成天討論這門(mén)語(yǔ)言好，或者那門(mén)語(yǔ)言不好的人，是可悲的。

然而就在我寫(xiě)這段文字之前的一年，我還是無(wú)止盡地深入語(yǔ)言細節，深入操作系統細節，以及深入……開(kāi)發(fā)的細節。

就在2004年3月間，我接受一個(gè)朋友的邀請，去北京做一個(gè)專(zhuān)題培訓。我用了近兩周的時(shí)間，做了50頁(yè)的幻燈，全面講述Delphi和Delphi.NET.然而在臨行前的一晚，我輾轉反側，思考著(zhù)一個(gè)問(wèn)題：我究竟做了些什么？或者說(shuō)，我究竟想告訴學(xué)員些什么？

凌晨5點(diǎn)，我在幻燈的末頁(yè)后插入了一張幻燈，標題是"語(yǔ)言只是工具",而幻燈的內容是一張圖。這是與培訓完全無(wú)關(guān)的一張幻燈。然而，這是自1997年我接觸到管理，以及從1998年我接觸到工程以來(lái)，第一次正視"軟件工程"這四個(gè)字。我第一次看清楚代碼、方法、過(guò)程、工程與組織的關(guān)系！

對于一個(gè)程序員，或者以程序員自命的人來(lái)說(shuō)，看清楚這一切的第一步，竟是一句"語(yǔ)言只是工具"!

猿之于為人，"學(xué)會(huì )制作和使用工具"是最重要的標志。因而我不知道"語(yǔ)言只是工具"這句話(huà)，究竟是對語(yǔ)言的膜拜，還是漠視。然而從那一刻開(kāi)始，我才真正地知道工程。

2.程序

在我的那個(gè)圖中，在最內層的環(huán)里，是"程序=算法+結構".這是編程的本源定義，也是原始的狀態(tài)。與代碼相關(guān)的任何工作，最終仍舊會(huì )落足于這樣的`一條規則。

編程的精義于此。從有開(kāi)發(fā)行為開(kāi)始，它就存在。挖山不止的愚公在數千年前就在用類(lèi)似的行為做編程實(shí)踐，而幾十萬(wàn)年前的智人，也在循環(huán)與分支所構成的邏輯中打轉。

3.方法

推動(dòng)這種邏輯向前發(fā)展的是"方法"和"方法論".長(cháng)期編程實(shí)踐，自然的推演與總結，必須沉淀為某種（軟件開(kāi)發(fā)）方法，于是"過(guò)程"出現了，"對象"出現了，相關(guān)的方法論也就出現了。

這是實(shí)踐的成果。方法不是某個(gè)人或者某個(gè)組織創(chuàng )造的。瓜熟而蒂落，實(shí)踐積累達到一定的程度，就算微軟不提出某個(gè)方法，IBM也會(huì )提出這個(gè)方法。即便他們都不提出，可能你自己已經(jīng)在使用這個(gè)方法了。

方法并不神秘，因為它就是你今天正在做的、從事的和實(shí)現的。正如"模式"是一種方法，而模式就是你昨天書(shū)寫(xiě)代碼的那個(gè)行為。只不過(guò)，GoF歸納、抽取、提升了這些行為的內在規律。你看不到你做事的行為，也就不能理解"模式"作為一種方法的價(jià)值。所以大師們眾口一詞：模式需要一定的編程經(jīng)驗才能理解。

同理，理解過(guò)程也需要編程經(jīng)驗，理解對象也需要編程經(jīng)驗，理解MDA與SOA還是需要編程經(jīng)驗。

這可能就發(fā)生在你回顧上一行精彩的代碼，或者上一個(gè)失敗的項目的一瞬息。經(jīng)驗來(lái)源于回顧、理解與分析，而不是你將要寫(xiě)的下一行代碼。

有人在寺院掃了一輩子的落葉而得道，也有人因為一句話(huà)而得道。

GoF因為無(wú)數次的代碼回顧而得道。

4.過(guò)程

過(guò)程隨生工程出現。過(guò)程解決的是工程中角色間的關(guān)系問(wèn)題。

過(guò)程說(shuō)的是很多人（團隊）如何組織在一起進(jìn)行開(kāi)發(fā)。它首先把工程中的各個(gè)環(huán)節分解出來(lái)。這樣，有了環(huán)節，就有了角色；有了角色，就有了溝通。因此過(guò)程中的問(wèn)題，就是角色、溝通和環(huán)節的問(wèn)題。

哪些環(huán)節更重要取決于具體的編程行為，也就是具體的項目。

例如產(chǎn)品開(kāi)發(fā)的周期可以一再拖延，因為對產(chǎn)品來(lái)說(shuō)，更重要的是其品質(zhì)和技術(shù)壁壘。因此你可以看到暴雪公司的游戲總是一再跳票，而它從來(lái)都是將大量玩家測試和開(kāi)發(fā)人員的個(gè)性特征放在第一位。相類(lèi)同的，DOOM與QUAKE系列的靈魂就是在游戲引擎的開(kāi)發(fā)和設計上。

如果用這樣的模式去做項目，可能軟件公司沒(méi)死掉，工程需求方也被拖死。試問(wèn)你有看見(jiàn)客戶(hù)因為你對技術(shù)的遠景描述而憧憬嗎？不，你只會(huì )看到他們因為項目的一再延遲而懊惱，而沮喪，或……暴怒。

憧憬這種事情，只會(huì )發(fā)生在那些鐵桿玩家身上。

分不清玩家與客戶(hù)的區別，對項目經(jīng)理來(lái)說(shuō)，是可怕的。這將意味著(zhù)他不能清楚地知道哪個(gè)環(huán)節更加重要。

角色的確定，以及角色間的溝通問(wèn)題，在項目過(guò)程中同樣重要。工程組織是否合理，相互協(xié)作是否緊密，是這個(gè)項目成功的保障。

"合作無(wú)間"通常是流于書(shū)面報告中的措辭。真正的"無(wú)間",應當是溝通的結果。然而UML,則可能是你與客戶(hù)，以及項目經(jīng)理與開(kāi)發(fā)人員被"離間"的第一因素。

【軟件工程實(shí)踐者的思想[1]】相關(guān)文章：

《軟件工程思想》讀后感11-21

軟件工程論文的提綱12-02

試論軟件工程的應用10-05

軟件工程思想在應用型高校畢業(yè)設計中應用研究11-02

大家的日語(yǔ)1第1課11-06

軟件工程碩士的論文09-25

1對1面試的經(jīng)驗技巧分析08-05

軟件工程應用淺析10-05

軟件工程碩士的開(kāi)題報告10-24

accp軟件工程師的介紹10-31