<rp id="n1hp1"><i id="n1hp1"><mark id="n1hp1"></mark></i></rp>

      <video id="n1hp1"><ol id="n1hp1"></ol></video>
      <address id="n1hp1"><del id="n1hp1"><ruby id="n1hp1"></ruby></del></address><ruby id="n1hp1"><ins id="n1hp1"></ins></ruby>

        技術中心

        這里象征著我們的態度和能力

        如何寫出沒有BUG的代碼
        發布者:admin    信息來源:本站原創    發布時間:2018-08-21      瀏覽次數:6314
        分享到:

        新浪微博

        騰訊微博

        QQ空間

        豆瓣網

        QQ好友

        1947年9月9日,美國海軍準將 Grace Hopper 在哈佛學院計算機實驗室里使用 Mark II 和 Mark III 計算機進行研究工作。她的團隊跟蹤到 Mark II 上的一個錯誤,操作人員發現是由于一只飛蛾鉆到了 Mark II 的繼電器里導致的。團隊清除了這只飛蛾,一切恢復正常。當時的工作人員記錄了這樣一句日志:" First actual case of bug being found. "  這次著名的事件,猶如潘多拉打開了魔盒,從此,程序員的世界里,bug 滿天飛。

        世界上第一個 bug

        在我所擔任過的角色中,有一個崗位叫做 Development Manager,通常簡稱 DM. 記得在一次基于一款平臺的二次開發項目中,因為 bug 實在太多,我們幾乎拿出了一整個里程碑的周期來 debug,于是我這個DM有了新的解釋:Debug Man.

          沒有人喜歡 bug,bug 意味著錯誤、不確定性、加班、交付風險,等等…… 負面的詞語怎么堆砌都不冗余。隨便找個有過一、兩個項目經驗的開發者,問問他 debug 的回憶,那氣氛就跟上墳一樣。

          對于 bug,開發者的神經往往也很敏感。有個段子很有趣 —— 說的是“應該如何向程序員反饋一個 bug ” ——

          你不能直接跟他說:“這里不對啊,是不是你程序有 bug ???”,要這么說的話,會直接被懟回來:“你丫的自己不會用吧!”。

          你可以換個說法:“咦,這里好像不對,是我操作錯了嗎?”,這時程序員心里就一咯噔:“Shit.. 不會是我代碼有 bug 吧?”

          從業多年,發現有個現象還蠻有趣的:有時候,當某個 bug 被發現時,犯下這個錯誤的始作俑者會開玩笑地為自己解脫:“誰沒寫過 bug 啊,Windows 還有 bug 呢?!?這句托詞我也用過,感覺挺好用的,就好比:梅西都能罰丟點球,我空門沒進,也是可以理解的嘛。

          但其實吧…… 這邏輯經不起推敲的。

          Windows 操作系統,一款長達30多年,裝機量估計都超過了地球人口數量的巨型工程,復雜度基本只能靠猜。以微軟公布的資料來看:

          Windows 95 代碼量約 1500 萬行
          Windows XP 代碼量約 4500 萬行
          Windows Vista 代碼量約 5000 萬行
          Windows 7 代碼量 5000+ 萬行

          以 Windows 7 為例,超5000萬的代碼量,23個小組,共1000多人的開發團隊。如此規模下產生的bug,和一個在辦公室里上了1天班,寫了200行代碼,就鬧出一堆bug,搞得項目亂七八糟的,能同日而語嗎?最后再輕描淡寫地來句 “微軟也有 bug ”,不害臊?

          所以我后來不用這句了,如此開脫,水平太low。其替代方案容我稍后再講。


        為了對抗 bug,人們發明了各種各樣的工具和手段,上至方法論,下至生產工具。越來越先進的 IDE, 復雜的代碼審查制度,從單元測試到集成聯調,再配上 beta 版,試用,公測,等等。凡此種種,其目標無一不是消滅 bug ??蛇@些琳瑯滿目的解決方案的存在,反倒證明了一個悲?。?strong style="margin:0px;padding:0px;">人類,實在是太容易犯錯了。

          如果說凡事都有正反兩面的意義,那么 bug 的正能量就是硬生生造就了大量就業機會,進而維護了社會穩定。

          那么,為什么我們總是無法避免 bug 的產生?我們能不能杜絕 bug ?

          答案當然是不可能了。因為那樣一來,程序員的日子豈不是太舒服了?不符合苦逼的定位。而且,我們所處的這個世界,但凡越是高呼要消滅的東西,越是會普遍地存在。就像蒼蠅、蚊蟲、污染、犯罪、戰爭,不一而足。

          按照常識,經驗越豐富的老手寫出來的代碼,一次通過的幾率更高,比如他們思考得會更周全,對異常的判斷和處理更老練,邊界條件把握得更精確,等等。所以我們可能會幻想:是不是只要我們足夠仔細,并努力磨練技藝,通過讓一部分碼農先老練起來,然后實現共同老練,最終就可以達到全世界開發者聯合起來消滅bug的大解放了?

          很遺憾,這只是一個治標不治本的思路,因為bug是有階級的。老手們的bug相對少,只是低級錯誤少,他們也會遇到bug,而他們的bug,往往都是一眼蒙逼的難度系數N.x的難題,不發生在代碼層面,大多在業務層面,甚至需求設計層面,或者直接是一些不可抗拒因素(做過政府項目嗎?)??傊?,萌新有萌新們的秀逗,大叔有大叔們的短路,老桿也會有自己的滑鐵盧。

          bug 這個概念的起源,就預示著它的不可避免性。世界上第一個 bug 是一只飛蛾,這劇本,誰能料到?某種意義上說,bug 就是不可預見的錯誤,能被預估并且提前做好準備的,那叫 exception, try catch 是他們的朋友。

          對于為什么會產生 bug 的原因,著名的荷蘭計算機科學家 Edsger W. Dijkstra 有過一句經典名言:


          If debugging is the process of removing software bugs, 

              then programming must be the process of putting them in.


          這就是上文提到的那句托詞 “ Windows 也有 bug. ” 的替代方案。:)

          設想一下,當你從無到有的寫下一句句代碼時,中間的任意一個時刻,你的程序都是運行不起來的,至少也是達不到目標效果的。從效用上完全等效于充滿 bug 的一堆代碼。你可能會辯解,程序還沒寫完呢,只是功能還沒實現,并沒有 bug 。事實上,換位思考一下,缺失某個功能和包含一個有故障的功能,對于用戶而言,都是無用的。一個處于開發階段尚沒寫完的代碼和開發結束但寫得有缺陷的代碼,是一回事。

          由此可以引申出了一個著名的命題: 


          Thats not a bug, its a feature request. 


          有時候,我們很難分清楚一個問題到底屬于 bug 還是 feature request . 文中作者拋出了一個案例:用 Visual Studio 構建一個 Windows GUI 程序時沒有采用系統默認字體。這個算不算一個 bug 呢?

          不好說。畢竟,隨著軟件應用越來越普及、越來越追求所謂人性化的趨勢,傳統意義上的只要程序能運行就不算 bug 的觀點,也在慢慢發生改變。對于一個強迫癌用戶來說,UI 上有缺陷,那基本上整個軟件就不能用了。事實上,在當今各類 app 競爭白熱化、同質化的時代,用戶體驗上的問題,往往是致命的。以前大家沒得選,所以沒那么挑剔,只要程序能干活就行了。如今的計算機用戶已經被寵壞了,在這樣的時代下,bug 早已悄悄地泛化了。


        所以,到底如何才能寫出沒有 bug 的代碼呢?

         

          答案: 不寫代碼。

         

          一個悲觀又絕望卻正確的唯一解。

          試著在這絕望里挖掘一點希望吧。這個答案隱含了一個方法論: 盡可能少寫代碼。因為 Dijkstra 大師已經說得很清楚了,編程就是制造 bug 的過程。那么,代碼寫的越少,犯錯的幾率就越小,這個道理顯而易見。維護一段300行的代碼,我們很容易有信心;接手一段3000行的代碼,什么反應就看各人素質了。

          現代的開發方式也都包含有這個思路,從 IDE 的智能提示,代碼補全功能,到每門語言都會有的各種“21天從入門到精通”的開發框架,以及很多實戰層面的約定俗成,都是在幫助開發者減少不必要的編碼??蚣芑?、規范化思維能降低出錯的可能性。

          事實上,就連編程語言本身的歷史發展都是按照這個思路在進行。從底層的匯編語言,到C/C++,再到Java/C#/Python……等各種高級語言,語言演化的目的之一就是為了把程序員從臟活、累活的工作中解放出來。

          “不要重復造輪子”的精神,一方面是在指導我們提高效率,不要重復勞動成本,另一方面也是減少重復犯錯的幾率。

          當代 Web 開發中的各種包管理概念正深刻地踐行著這條精神,以至于在2016年3月爆發了著名的 NPM & left-pad 事件: 一段區區11行的字符串填充函數模塊,被全世界依賴,結果作者 Azer 下架模塊包的那一天,全球前端大崩潰。受波及的產品和團隊中,甚至包含著名的 React !

          這個事件讓人們開始反思:我們是不是忘了該如何編程了? 一個功能簡單到人人都會寫的函數,卻都不約而同地選擇引入,而不是自己實現。最終,過猶不及。 

          寫代碼,真的很難。

         NO CODE , NO BUG .


        可是,如果真的只能不寫代碼了,那么本身就已經沒有女朋友的程序員們,現在連代碼也沒有了,這還讓不讓人活了?

          不能這樣把程序員們給逼死了,要講人權。

          有時候,當答案實在不可接受的時候,我們就該思考是不是問題問錯了。

          所以,換個角度,為什么要追求無 bug 呢?也許我們根本就沒必要害怕 bug.

          有 bug 的地方就有麻煩,有麻煩就有解決麻煩的需要,客戶就是給那些能解決麻煩事的人支付報酬的。只處理簡單的問題,是沒有價值的,市場只認可那些面對困難能提供解決方案的人。簡單來講,想賺錢,就別怕麻煩。

          對于客戶來說,不管是 bug 或是 feature request,都是一個需要解決的問題。一個優秀的PM,可以把客戶反饋的 bug,包裝成 feature request,返回一套解決方案。然后,優秀的商務代表出馬,簽訂補充協議。恭喜,你們的項目經費增加了一點點。

          

          英格蘭有句諺語:

          Where theres muck, theres brass.

         

          如此看來,“ 如何寫出沒有BUG的代碼?” 這問題,恐怕確實問錯了。






        4000-880-989
        (24小時熱線)
        聯系客服
        微信公眾號

        官方公眾號

        小程序

        ?2008-2022 CORPORATION ALL Rights Reserved. 昆明奧遠科技有限公司版權所有 滇ICP備09003328號-1 滇公網安備 53011102000818號
        昆明那家網絡公司好,新媒體運營,網站優化,網絡推廣,網站建設,網頁設計,網站設計,網站推廣,云南網站公司,昆明新媒體公司,云南網紅主播,昆明SEO公司,昆明網站建設,昆明網絡推廣,昆明網站優化,昆明網站推廣,紅河網站建設,大理網絡公司,曲靖網絡公司,麗江網站設計,昭通網絡公司,保山大數據服務,智慧高速建設,智慧校園服務,云南IDC服務商,網絡安全測評,等保測評,網站關鍵詞排名優化服務,服務客戶盡超2000余家,一切盡在奧遠科技,服務電話:13888956730
        日本按摩高潮A级中文片不卡

            <rp id="n1hp1"><i id="n1hp1"><mark id="n1hp1"></mark></i></rp>

            <video id="n1hp1"><ol id="n1hp1"></ol></video>
            <address id="n1hp1"><del id="n1hp1"><ruby id="n1hp1"></ruby></del></address><ruby id="n1hp1"><ins id="n1hp1"></ins></ruby>