軟件工程的歷史變遷
本文是從 What Happened to Software Engineering? 這篇文章翻譯而來。
在過去的幾年里，在世界范圍內(nèi)，軟件開發(fā)方法發(fā)生了一些變化。還不是很久以前，最主要的軟件開發(fā)生命周期(SDLC)方法論是瀑布模型方法(Waterfall Method)，它使用非常明確的階段把開發(fā)過程分割成諸如設(shè)計(jì)、測(cè)試等工程步驟。軟件開發(fā)行業(yè)，目前還是一種新興的行業(yè)，人們正在努力尋找一種可以重復(fù)的、可預(yù)知的軟件開發(fā)過程方法。
對(duì)于軟件開發(fā)過程，***的參考模型看起來應(yīng)該是物理學(xué)工程，就像土木建造工程。諸如詳細(xì)需求說明書、設(shè)計(jì)說明書以及技術(shù)說明書的等材料應(yīng)該早在任何程序代碼編寫前就開始動(dòng)工編寫和完成，就跟修橋、蓋大樓、修路、修大壩等物理建筑修建過程一樣。
為了更好的向這種物理學(xué)工程靠攏，諸如“軟件工程師”和“軟件架構(gòu)師”等工作職位也開始在軟件開發(fā)中被接受。
這種風(fēng)格的工程管理在建筑工程中使用的非常成功。然而在軟件工程中卻出現(xiàn)了大量的失敗，還有更多的項(xiàng)目最終嚴(yán)重超出預(yù)算或工期延誤。導(dǎo)致這種現(xiàn)象的因素很多，但最主要的一個(gè)因素應(yīng)該是軟件和硬件上變化的速度和業(yè)務(wù)需求上變化的速度。軟件行業(yè)里的這種變化—做個(gè)比喻—就像是每18個(gè)月一款新型的汽車的出產(chǎn)都需要你對(duì)道路進(jìn)行全面的重新設(shè)計(jì)。
當(dāng)一個(gè)土木工程師去修建一座跨河大橋來連接河兩邊的道路時(shí)，工程師會(huì)非常清楚的知道道路跨河的精確地理坐標(biāo)位置。行駛的車輛在數(shù)年里也不會(huì)發(fā)生重大的改變。橋梁工程師只需要按照之前已經(jīng)被上千次的驗(yàn)證過的建筑工藝把河兩邊的路連接到一起。
對(duì)于軟件系統(tǒng)，因?yàn)榧夹g(shù)或業(yè)務(wù)發(fā)生了變化，在建設(shè)過程中(在所有需求和設(shè)計(jì)文檔完全完成后)需求需要做重大修改的情況并不罕見。如果把這種情況放到修橋的事情上，相當(dāng)于當(dāng)橋的地基打好后，再把橋的搭建位置往河的下游移6公里。
為了面對(duì)出現(xiàn)的這些問題，軟件工程師開發(fā)出了很多新的技術(shù)和實(shí)踐方法來重新定義軟件建設(shè)開發(fā)過程步驟，以此來提高軟件的質(zhì)量、代碼重用率和生產(chǎn)率。有一些新的的實(shí)踐方法對(duì)代碼規(guī)范、命名規(guī)則進(jìn)行了定義(和強(qiáng)制要求)，鼓勵(lì)使用那些經(jīng)過驗(yàn)證過的軟件設(shè)計(jì)模式，鼓勵(lì)使用諸如單元測(cè)試框架等工具和驅(qū)動(dòng)測(cè)試開發(fā)(TDD)等技術(shù)方法，鼓勵(lì)采納行為驅(qū)動(dòng)開發(fā)(BDD)、持續(xù)集成、結(jié)對(duì)編程等實(shí)踐方法。這些技術(shù)有效的減少了問題的出現(xiàn)，改進(jìn)了建設(shè)開發(fā)過程，成為了公認(rèn)的軟件工程做好的實(shí)踐方法。
當(dāng)對(duì)開發(fā)過程階段的實(shí)踐方法有了改進(jìn)發(fā)展后，針對(duì)項(xiàng)目過程中其它階段—諸如需求定義、系統(tǒng)設(shè)計(jì)、質(zhì)量管控、測(cè)試等—的研究改進(jìn)也相繼出現(xiàn)。它們包括Scrum，極限編程，Kanban(Lean制造工藝的一種修訂)…
這種針對(duì)開發(fā)上的變遷現(xiàn)在被人們歸結(jié)為敏捷方法論(Agile Methodologies)。事實(shí)上，大部分用來改進(jìn)軟件開發(fā)的實(shí)踐方法，例如TDD，持續(xù)集成等，都是沿著改進(jìn)開發(fā)過程的思路發(fā)展起來的，它們后來都被統(tǒng)稱為敏捷方法。
如今，敏捷方法論正迅速的從邊緣角色發(fā)展向主流技術(shù)，甚至滲透到了很多大公司的軟件開發(fā)團(tuán)隊(duì)里。敏捷革命給軟件行業(yè)帶來了巨大的變化，很多在使用老的瀑布模型軟件開發(fā)方法時(shí)程序員會(huì)面對(duì)的問題，現(xiàn)在都被凸顯出來。
各種的會(huì)議，開發(fā)論壇，課程都起來討論如何更好的使用敏捷方法，人們都關(guān)注于像“如何***的管理backlog，重構(gòu)，spring計(jì)劃，以及其他過程問題“的論題——這些都是極其重要的、需要被那些打算采用敏捷方法的開發(fā)團(tuán)隊(duì)認(rèn)真理解、正確使用的概念。
所有敏捷運(yùn)動(dòng)留下來的產(chǎn)物都是用于創(chuàng)造高質(zhì)量軟件的工藝實(shí)踐方法。大多數(shù)敏捷方法論主要針對(duì)的是過程管理問題，不涉及到其中的開發(fā)技術(shù)(Kent Benk 和 極限編程是例外)。這是敏捷方法論假設(shè)的一個(gè)前提：你已經(jīng)很好的掌握了編程技術(shù)!
不幸的是，在我做顧問和敏捷指導(dǎo)的職業(yè)生涯中，我經(jīng)常發(fā)現(xiàn)他們技術(shù)工藝水平遠(yuǎn)遠(yuǎn)達(dá)不到敏捷方法論的要求。這導(dǎo)致了在敏捷方法上出現(xiàn)了很多錯(cuò)誤的認(rèn)識(shí)，抓不住敏捷方法的特征重點(diǎn)?；蛘?，對(duì)他們來說，敏捷方法的意義只之在于把來自于瀑布模型開發(fā)方法下出現(xiàn)的“軟件工程“這個(gè)詞給搞臭了。
我們是學(xué)習(xí)了前人的基礎(chǔ)上才發(fā)展成一個(gè)產(chǎn)業(yè)的。即使在過程上的革新也是要參考我們已經(jīng)知道的東西，吸收那些好的，摒棄那些不好的。像測(cè)試/行為驅(qū)動(dòng)開發(fā)、持續(xù)集成、結(jié)對(duì)編程這樣的優(yōu)秀軟件工程實(shí)踐方法，如果我們視如不見，那我們其實(shí)是忘了我們最終的目的：開發(fā)出高質(zhì)量的軟件。
其它類型的過程管理方法跟敏捷方法一樣，它們對(duì)實(shí)現(xiàn)我們最終的目標(biāo)有著同樣重要的意義，所以，不要倒洗澡水時(shí)把孩子也潑了出去。我現(xiàn)在有很多的頭銜，包括演講家，敏捷教練，作家。而本質(zhì)上，我是一個(gè)軟件工程師。而我為此自豪
原文：http://www.aqee.net/what-happened-to-software-engineering/
【編輯推薦】
