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