<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    posts - 189,comments - 115,trackbacks - 0

    與“老大”一起談軟件行業(轉貼)

    本文出自 “李云” 博客,請務必保留此出處http://yunli.blog.51cto.com/831344/168345

        “老大”是我很要好的一個朋友,也是一個對于我的職業發展產生過很大影響的一個朋友。上個周末去了千島湖,順便給“老大”帶了一些枇杷,在送枇杷過去時和他好好地聊了聊。


         我們倆在軟件行業做了都有近十年的時間,分別在全球知名的兩個通訊公司工作。在這之前,我倆是UTStarcom的同事,工作在同一個項目組。“老大”現在是公司的一名Manager(“老大”更喜歡Leadership這個詞),而我是公司的一名Architect。

         我倆的談話總是以“最近怎么樣”開始的,而我這次與他談到了對于現在所在公司的前景的擔憂。一方面公司在WiMAX上面并沒有達到期望的結果,另一方面,覺得通訊公司在軟件的開發方面并沒有很深的積累,不少開發方法還是“作坊式”的。當然,這里說到的深是相對的,是相對于那種以軟件開發為本的公司,如Microsoft,等。對于“通訊公司在軟件的開發方面并沒有很深的積累”這一點,“老大”與我有相同的看法。比如,現在的通訊公司大量采用的都是C,除了據我所知Nortel在采用C++和OO開發接入網這一塊很有經驗。OOP毫無疑問是一個能使應用問題得到更好解決的一種開發方法,當然,要真正的駕馭OO,對于開發人員的要求的確是更加的高。在Cockburn的《OO項目求生法則》中對關于OO開發的風險有很好的闡述,但我想歸根到底還是人的問題。

         我們談到了項目的管理。“老大”提到他現在所做的項目當中有一部分的代碼質量非常的差,只有通過重寫才能解決問題,但“老大”的老大的老大似乎并不知道應當讓大家這樣去做,而是一味的強調“測試!測試!再測試!”。對于這一點,我談了我的看法“說到底是相關人員其實并不了解軟件”。雖然,這些人也在軟件行業有八年仍至于十年以上了,但他(她)并沒有真正的掌握軟件行業的特點,主要存在以下幾方面的問題:
        1)很多Manager在做Management以前都是技術出身,由于做技術期間沒有在軟件技術上有很深的積累,在做management時,當別人提出一種的確行之有效的方法時,就沒有能力去判斷是否從長遠來看有利于自己的團隊和產品,只相信那些能產生一定的數據的方法(比如,代碼覆蓋率)。在與“老大”談時,我們打了一個比方:比如,我們建了一座樓,如果這座樓的根基是好的,那么我們可以通過Refactor來“每次裝修一個房間”,從而達到最后的“量變產生質變”的效果,在這種情況下,我們可以采用加強測試(如UT - Unit Test)來配合我們的Refactor;反之,如果這座樓的根基有問題,那“每次裝修一個房間”能解決問題嗎?此時,我想Restructure是更好的一個選擇。當然,由于這些人并不明白這些道理,于是使勁的去做UT,那結果一定是:苦了工程師(沒錢沒生活)又害了產品(失去了重生的機會和用戶)。針對這種情況,Manager是應當鼓勵restructure呢?還是小的Refactor?Manager真的需要知道嗎?還是可以通過向相關的人問一問,怎樣做更好。問誰?專家?不。一線工程師會告訴你答案。當然,我們談話中也持同一觀點:如果一個功能模塊很爛,但并不經常出問題,或說是不占用大量的資源,在這種情況下即使是根基有問題,我們也不應當馬上去Restructure它。“老大”將根基不好的軟件比喻成“軟件黑哃”,很有新意!
        2)不相信團隊。不相信團隊能通過采用新的方法從而改變現狀。我想很多的Manager在嘴上說“我相信我的團隊”,而內心里其實是不相信團隊。為什么呢?其中,有一部分原因是他(她)自己從來就沒有通過技術的變化而成功的改變現狀的成功經歷,因此,對于他(她)來說同意采用新方法就是一次“大冒險”。
        3)不愿意承擔責任和風險。這些人往往Offer都不錯,他(她)沒有必要讓自己去take risk,從而影響自己的“前(錢)途”。這其實是1)和2)所帶來的行為結果。
        4)只關心自己。有些Manager只關心自己,并不關心自己的團隊以及自己所負責的產品。至于,團隊是否有太多的Overtime,或是士氣低下等等,一概視而不見,更不用說產品的未來了。

         后來,我們也談到了開發方法,如Agile,SCRUM等等。我的觀點是:開發方法的出發點是好的,而且,很多方法的確是行之有效的,但關鍵在于我們在運用這些開發方法時,有時會“走火入魔”。在很多情況下,如果我們不能很好的把握運用這些方法的時機和分寸,那只能出現以下結果。
        1)采用了方法論后,發現團隊更忙了,但是產出卻是更低了,質量也沒有得到改善。進而
        2)宣告這種方法無效。

        其實,軟件行業一直以來就有很多行之有效的方法(但不是終級方法,別忘了No silver bullet!),只是,我們不能很好的去實踐和把握運用它們的時機和分寸。比如,現在很多軟件開發方法都鼓勵UT,但是UT這一概念是在30年前提出的。我們的從業人員對于UT真的有足夠的認識和切身的體會嗎?除了UT,自動化測試也是很好的一種方法,但我們的測試人員真的覺得它重要嗎?
     
         在很多的軟件書籍中都提到了人的重要性,但軟件行業真的是這么認為的嗎?從現在狀況來看,我相信這一觀念還沒有深入到從業人員的骨髓中。甚至,不少人還用管理生產的方式來管理軟件產品。在《從優秀到卓越》這一書中,作者指出其研究結果顯示:先人后事!即先找到合適的人然后再想要做什么。雖然,這書不是針對軟件行業的,但我想無論什么行業,其有些共性是相同的。我想“先人后事”在所有行業都通用。
    posted on 2011-12-17 14:09 MEYE 閱讀(268) 評論(0)  編輯  收藏

    只有注冊用戶登錄后才能發表評論。


    網站導航:
     
    主站蜘蛛池模板: 成人免费一区二区三区| 日韩电影免费在线观看网站 | 国产aⅴ无码专区亚洲av| 九九免费久久这里有精品23| 又大又粗又爽a级毛片免费看| 精品在线免费视频| mm1313亚洲精品无码又大又粗| 香港特级三A毛片免费观看| gogo全球高清大胆亚洲| 一级做性色a爰片久久毛片免费| 中国亚洲女人69内射少妇| 青青青国产手机频在线免费观看| 亚洲春色在线观看| 成人免费看吃奶视频网站| 亚洲av日韩专区在线观看| 亚洲精品国产福利一二区| 免费看黄的成人APP| 亚洲精品偷拍无码不卡av| 成人男女网18免费视频| 免费观看四虎精品成人| 亚洲国产a∨无码中文777| 在线永久免费的视频草莓| 亚洲国产精品成人AV在线| 2048亚洲精品国产| 免费A级毛片无码视频| 亚洲欧美日韩综合久久久| 亚洲精品和日本精品| 在线免费中文字幕| 亚洲国产精品嫩草影院| 亚洲精品色午夜无码专区日韩| 亚洲一区免费视频| 国产91成人精品亚洲精品| 亚洲AV区无码字幕中文色| 四色在线精品免费观看| a级毛片在线免费| 77777亚洲午夜久久多喷| 在线日韩日本国产亚洲| 99久久综合国产精品免费| 一个人免费观看视频在线中文 | 四虎永久在线精品免费网址 | 一级毛片成人免费看免费不卡|