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