<dfn id="w48us"></dfn><ul id="w48us"></ul>
  • <ul id="w48us"></ul>
  • <del id="w48us"></del>
    <ul id="w48us"></ul>
  • 軟件工程實踐者的思想[1]

    時間:2020-10-28 14:16:55 職業規劃 我要投稿

    軟件工程實踐者的思想[1]

    得其精而忘其粗,在其內而忘其外;見其所見,不見其所不見,視其所視,而遺其所不視"--《列子說符》

    1.語言只是工具

    我曾經是非常執著的開發人員。我有連續幾天幾夜做Coding的經歷,也曾經為了一個技術問題耗上三、四個星期而導致項目一再延遲,還曾經為了一個實現細節與項目相關的人員逐一爭論。

    我也曾經像大多數開發人員一樣熱衷于爭論語言之間孰優孰劣。我在論壇上寫過一個簡介,其中個人特長是"擅長TPascal、Delphi、TASM系列語言,痛恨C/C++".我至今保留這段文字,因為那的確是真實的經歷。

    如今我已經不再專注于語言,正如我在第一章中寫到的一樣:成天討論這門語言好,或者那門語言不好的人,是可悲的。

    然而就在我寫這段文字之前的一年,我還是無止盡地深入語言細節,深入操作系統細節,以及深入……開發的細節。

    就在2004年3月間,我接受一個朋友的邀請,去北京做一個專題培訓。我用了近兩周的時間,做了50頁的幻燈,全面講述Delphi和Delphi.NET.然而在臨行前的一晚,我輾轉反側,思考著一個問題:我究竟做了些什么?或者說,我究竟想告訴學員些什么?

    凌晨5點,我在幻燈的末頁后插入了一張幻燈,標題是"語言只是工具",而幻燈的內容是一張圖。這是與培訓完全無關的一張幻燈。然而,這是自1997年我接觸到管理,以及從1998年我接觸到工程以來,第一次正視"軟件工程"這四個字。我第一次看清楚代碼、方法、過程、工程與組織的關系!

    對于一個程序員,或者以程序員自命的人來說,看清楚這一切的第一步,竟是一句"語言只是工具"!

    猿之于為人,"學會制作和使用工具"是最重要的標志。因而我不知道"語言只是工具"這句話,究竟是對語言的膜拜,還是漠視。然而從那一刻開始,我才真正地知道工程。

    2.程序

    在我的那個圖中,在最內層的環里,是"程序=算法+結構".這是編程的本源定義,也是原始的狀態。與代碼相關的任何工作,最終仍舊會落足于這樣的`一條規則。

    編程的精義于此。從有開發行為開始,它就存在。挖山不止的愚公在數千年前就在用類似的行為做編程實踐,而幾十萬年前的智人,也在循環與分支所構成的邏輯中打轉。

    3.方法

    推動這種邏輯向前發展的是"方法"和"方法論".長期編程實踐,自然的推演與總結,必須沉淀為某種(軟件開發)方法,于是"過程"出現了,"對象"出現了,相關的方法論也就出現了。

    這是實踐的成果。方法不是某個人或者某個組織創造的。瓜熟而蒂落,實踐積累達到一定的程度,就算微軟不提出某個方法,IBM也會提出這個方法。即便他們都不提出,可能你自己已經在使用這個方法了。

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

    同理,理解過程也需要編程經驗,理解對象也需要編程經驗,理解MDA與SOA還是需要編程經驗。

    這可能就發生在你回顧上一行精彩的代碼,或者上一個失敗的項目的一瞬息。經驗來源于回顧、理解與分析,而不是你將要寫的下一行代碼。

    有人在寺院掃了一輩子的落葉而得道,也有人因為一句話而得道。

    GoF因為無數次的代碼回顧而得道。

    4.過程

    過程隨生工程出現。過程解決的是工程中角色間的關系問題。

    過程說的是很多人(團隊)如何組織在一起進行開發。它首先把工程中的各個環節分解出來。這樣,有了環節,就有了角色;有了角色,就有了溝通。因此過程中的問題,就是角色、溝通和環節的問題。

    哪些環節更重要取決于具體的編程行為,也就是具體的項目。

    例如產品開發的周期可以一再拖延,因為對產品來說,更重要的是其品質和技術壁壘。因此你可以看到暴雪公司的游戲總是一再跳票,而它從來都是將大量玩家測試和開發人員的個性特征放在第一位。相類同的,DOOM與QUAKE系列的靈魂就是在游戲引擎的開發和設計上。

    如果用這樣的模式去做項目,可能軟件公司沒死掉,工程需求方也被拖死。試問你有看見客戶因為你對技術的遠景描述而憧憬嗎?不,你只會看到他們因為項目的一再延遲而懊惱,而沮喪,或……暴怒。

    憧憬這種事情,只會發生在那些鐵桿玩家身上。

    分不清玩家與客戶的區別,對項目經理來說,是可怕的。這將意味著他不能清楚地知道哪個環節更加重要。

    角色的確定,以及角色間的溝通問題,在項目過程中同樣重要。工程組織是否合理,相互協作是否緊密,是這個項目成功的保障。

    "合作無間"通常是流于書面報告中的措辭。真正的"無間",應當是溝通的結果。然而UML,則可能是你與客戶,以及項目經理與開發人員被"離間"的第一因素。

     

    【軟件工程實踐者的思想[1]】相關文章:

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

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

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

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

    大家的日語1第1課11-06

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

    1對1面試的經驗技巧分析08-05

    軟件工程應用淺析10-05

    軟件工程碩士的開題報告10-24

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

    主站蜘蛛池模板: 日韩精品无码一区二区三区不卡| 国产精品无码一区二区在线 | 日韩午夜高清福利片在线观看欧美亚洲精品suv | 精品一区二区三区中文字幕| 亚洲精品综合久久| 国产欧美一区二区精品性色99 | 久久国产精品久久精品国产| 久久精品国产亚洲av麻豆色欲| 欧美日韩国产成人高清视频,欧美日韩在线精品一 | 国产精品亚洲二区在线观看| 无码精品久久久久久人妻中字| 久久精品一区二区| 人妻少妇看A偷人无码精品| 国产精品高清在线观看| 欧美精品一本久久男人的天堂| 97久久精品国产精品青草| 亚洲AV永久青草无码精品| 亚洲国产午夜中文字幕精品黄网站 | 午夜精品久久影院蜜桃| 精品国产一区二区22| 国産精品久久久久久久| 国产精品网址在线观看你懂的| 亚洲精品欧美综合在线| 青青青国产精品国产精品久久久久| 成人国产精品高清在线观看| 国产精品区免费视频| 国产成人精品AA毛片| 国产精品丝袜一区二区三区| 国产亚洲精品无码成人| 精品欧洲av无码一区二区| 精品国产福利一区二区| 国产探花在线精品一区二区| 国产精品伦一区二区三级视频| 国产精品白丝AV网站| freesexvideos精品老师毛多| 国产福利精品一区二区| 国产精品福利在线观看| 欧美性videofree精品| 国产精品 羞羞答答在线| 国产精品无码不卡一区二区三区| 久久99精品免费一区二区|