• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            無我

            讓內(nèi)心永遠燃燒著偉大的光明的精神之火!
            靈活的思考,嚴謹?shù)膶崿F(xiàn)
            豪邁的氣魄、頑強的意志和周全的思考

            從編程到工程——系統(tǒng)地分析軟件工程

                   《大道至簡》的第六章“從編程到工程”,我認為是全書的精髓!作者以自己深厚的積累、豐富的經(jīng)驗,用精煉的文筆深刻闡明了“軟件工程”的內(nèi)涵和外延,講清楚了代碼、方法、過程、工程與組織的關系! 非常值得我們深入學習和研究!

                     本章所有內(nèi)容都是圍繞作者給出的一張圖——EHM模型圖,完全可以說,這張圖充分顯示了作者深厚的功底:
                     
                     既可以說這幅圖展示了軟件工程內(nèi)涵的各個層面,也可以說這其實就是軟件工程的發(fā)展史:從最早只追求程序?qū)崿F(xiàn)到后來有完善的組織和管理。

                     在本章的后面若干節(jié)內(nèi)容中,作者分開描述EHM各個組成部分。我想下面這一段“方法”可能比較對技術人員的口味:
            原文      推動這種邏輯向前發(fā)展的,是“方法”和“方法論”的出現(xiàn)。長期的編程實踐,自然的歸演與總結(jié),必須沉淀為某種( 軟件開發(fā)) 方法,于是“過程”出現(xiàn)了,于是“對象”出現(xiàn)了,于是相關的方法論也就出現(xiàn)了。 
                  這是實踐的成果。方法不是某個人或者某個組織創(chuàng)造的。瓜熟而蒂落,實踐積累達到一定的程度,微軟不提出某個方法,IBM 也會提出這個方法。即便他們都不提出,可能你自己已經(jīng)在使用這個方法了。 
                  方法并不神秘,因為它就是你今天正在做的、從事的和實現(xiàn)的。正如“模式”是一種方法,而模式就是你昨天書寫代碼的那個行為。只不過,GoF 歸納、抽取、提升了這些行為的內(nèi)在規(guī)律。 
                  你看不到你做事的行為,也就不能理解“模式”作為一種方法的價值。所以大師們眾口一詞:模式需要一定的編程經(jīng)驗才能理解。 
                  同理,理解過程也需要編程經(jīng)驗,理解對象也需要編程經(jīng)驗,理解MDA與SOA還是需要編程經(jīng)驗。 
                  ——這可能就發(fā)生在你去回顧你上一行代碼編寫的經(jīng)過,或者上一個項目失敗的經(jīng)歷的那一瞬息。經(jīng)驗來源于回顧、理解與分析,而不是你將要寫的下一行代碼。 
             
                  有人在寺院掃了一輩子的落葉而得道,也有人因為一句話而得道。 
                  GoF 因為無數(shù)次的代碼回顧而得道。 

                     而這一段“組織”可能讓項目經(jīng)理比較感興趣:
            原文       工程理論其實是包含組織學的。然而我在上面的那張圖中,將組織與工程分離開來,并在二者之間畫下了一道縱向的線。 
                           

                  如果說工程關心的是“需求”、“配置”和“文檔”等等這樣一些要素,那么這樣的工程還是停留在技術層面的:關注的還是工程的實現(xiàn)細節(jié),而非目標。從角色的角度來看,這是項目經(jīng)理和技術經(jīng)理所共同關注的那一部分。 
                  然而項目經(jīng)理還必須關注于人力資源、項目資金以及多個項目之間的協(xié)調(diào)等等。這些與工程本身并沒有直接關系,而是“組織”方面的內(nèi)容。 
            所以在工程環(huán)節(jié)中“文檔管理”和“配置管理”等等中的那個詞匯“管理”,是管理的具體技術和方法;而在“組織”這個環(huán)節(jié)中的這個“管理”,才是真正的管理學上的用詞。 
                  我在這張圖上,試圖從這個角度上來說明:作為項目經(jīng)理,你必須有一部分的工作是非技術性的。甚至,你可能絕大部分的工作是非技術性的。——因為與技術相關的管理技能( 需求、配置、過程管理等) 可以由開發(fā)經(jīng)理來做,或者公司對于這一方面有較統(tǒng)一且成熟的規(guī)范,因而無需投入過多的精力。 
                  你必須更關注于對這個( 或這些) 工程的組織與計劃。站在“組織者”這個角色上,你現(xiàn)在要考慮的內(nèi)容可能會是: 
            1. 為項目的各個階段建立計劃,并逐漸地細化計劃的內(nèi)容,以及確立項目過程中每一個環(huán)節(jié)、每一個計劃階段的優(yōu)先級和復雜度; 
            2. 確立項目或者產(chǎn)品階段目標,成果的準確描述、定位,以及整個項目的質(zhì)量目標及其評核辦法; 
            3. 對團隊中的不同角色展開培訓,以指導并協(xié)調(diào)角色間的工作,從而消除因為工作習慣的差異帶來的影響; 
            4. 為每一個人準備他所需要的資源,這不單單是把一套shareware 變成正式版或者把512M 內(nèi)存變成2G,還包括準確地評估他的工作量,以及決定是否為他增加一個( 能協(xié)同工作的) 副手; 
            5. 決定在哪些環(huán)節(jié)上反復審核和回顧,而在哪些環(huán)節(jié)上采用較為寬松的方式以加快進度; 
            6. 習慣于開會、組織更短而有效的會議以及建立激勵機制,當然也不要忘記讓每一個成員意識到這一項目的風險; 
            7. 不要樂觀。 
                  即使你做好這一切,可能項目的結(jié)果仍然不夠理想。但是你應該知道,好的項目經(jīng)理并不是不犯錯誤的人,而是以盡可能少的失敗來獲得成功的那個人。 
                  無論是你的團隊成員,還是你的老板,對重復的錯誤以及可預料的錯誤都是不會寬容的。——在一個團隊中,失去了組員的信任比失去老板的信任更為可怕。 
                  所以回顧每一個項目,或者項目中的每一個階段,以及與每一個團隊成員交流的細節(jié),是你的日常工作。
                  
                     當然,了解一下BOSS的定位和主要職責也是很有幫助的:
            原文      很多人以為BOSS 是給自己發(fā)錢的那個人,這其實是錯誤的。發(fā)錢的決策通常是由三個角色來做出的: 
            1. 部門/團隊經(jīng)理。你的直接上司,他是雇傭你的人,是他用薪金的多少來衡量你的價值,或者反之。 
            2. 紀效經(jīng)理。如果你的公司有這個角色的話,那么他總是盯著你的錯誤以決定從你的薪水里的扣除比例。 
            3. 財務經(jīng)理。有錢?沒錢?沒錢?有錢?…… 
                  BOSS 并不決定你的薪水。 
             
                  BOSS 在公司中解決的是“經(jīng)營”問題。這其實是在比“組織”更靠外側(cè)的一層。——在前面的圖例中并沒有給出,這也意味著“經(jīng)營者”與“工程”基本沒有關系。 
                  在一個更大規(guī)模的組織機構(gòu)里,你可以會更直接地觀察到“經(jīng)營者”與“組織者”之間的差異。例如公司的大小股東是“經(jīng)營者”,董事會通常是解決經(jīng)營問題的地方;而總經(jīng)理、執(zhí)行經(jīng)理以及各個部門經(jīng)理則是各級的“組織者”,經(jīng)理辦公會則是解決組織問題的地方。 
                  你應該清楚,真正的BOSS是經(jīng)營者。 
                  這有助于你明確你被雇來的原因,你的工作是面向哪一個層面的,以及你或者你的上司有沒有權(quán)限來決定是一個項目是否應該立項,或中止。 
                  BOSS(經(jīng)營者) 決定了一個方向,組織者保證決策與這個方向是同步的,而工程是在這樣的一個方向、決策的構(gòu)架下的一個具體行為。 
                  工程中沒有BOSS。

                     從編程到工程,本文系統(tǒng)地分析了軟件工程的方方面面。EHM給出的是完整的軟件工程架構(gòu),不是一個小程序,也不是單獨的過程。這是一套體系,在這套體系中,軟件工程的所有參與人基本都能找到自己的位置,包括那個只是偶爾出現(xiàn)來指手畫腳的BOSS。

                     作為軟件工程體系中的一個角色,找對自己的定位,明確自己的職責,對以后的工作無疑會有巨大的幫助。經(jīng)常讀讀本文吧~

            posted on 2013-07-16 17:01 Tim 閱讀(299) 評論(0)  編輯 收藏 引用 所屬分類: 品讀《大道至簡》

            <2013年7月>
            30123456
            78910111213
            14151617181920
            21222324252627
            28293031123
            45678910

            導航

            統(tǒng)計

            公告

            本博客原創(chuàng)文章,歡迎轉(zhuǎn)載和交流。不過請注明以下信息:
            作者:TimWu
            郵箱:timfly@yeah.net
            來源:m.shnenglu.com/Tim
            感謝您對我的支持!

            留言簿(9)

            隨筆分類(173)

            IT

            Life

            搜索

            積分與排名

            最新隨筆

            最新評論

            閱讀排行榜

            久久精品国产亚洲AV无码娇色| 97精品国产97久久久久久免费| 久久强奷乱码老熟女网站| 久久久91人妻无码精品蜜桃HD| 久久国产精品波多野结衣AV| 无码国内精品久久人妻麻豆按摩| 热99RE久久精品这里都是精品免费| 久久天天躁夜夜躁狠狠躁2022| 国内精品久久久久久久97牛牛 | 国产精品无码久久久久久| 国产精久久一区二区三区| 亚洲va久久久噜噜噜久久狠狠 | 久久不射电影网| 久久乐国产综合亚洲精品| 99久久精品费精品国产一区二区| 久久无码国产| 精品欧美一区二区三区久久久 | 亚洲精品tv久久久久久久久久| …久久精品99久久香蕉国产| 亚洲AV无码1区2区久久| 欧美一级久久久久久久大| 色综合久久天天综合| 久久久免费精品re6| 无码专区久久综合久中文字幕 | 久久久久久久久久久久久久| 久久国产精品波多野结衣AV| 色综合久久久久| 久久精品国产第一区二区三区 | 亚洲欧美一级久久精品| 久久久精品视频免费观看| 欧美激情精品久久久久| 一级做a爰片久久毛片16| 久久亚洲国产中v天仙www| 日本福利片国产午夜久久| 久久精品国产91久久麻豆自制| 99久久婷婷免费国产综合精品| 久久久无码精品亚洲日韩蜜臀浪潮 | 国内精品人妻无码久久久影院导航| 色播久久人人爽人人爽人人片aV | 久久久91精品国产一区二区三区| 久久99国产综合精品女同|