程序員寫代碼沒有bug

1. 程序員為什麼要一直改bug 不能一次性寫好嗎

程序寫代碼就像造一座大樓，如果即便經過嚴格的設計論證，裝配高質量的部件，最後還有系統性地驗收，讓你去造這么一座大樓，你能保證不管是窗戶安沒安好，還是地基挖淺了挖深了，還是牆皮脫落，都一個問題沒有？
回想早年的小程序，執行某一個具體的任務，明確的輸入輸出，一般是不會有bug的。
但現在的軟體開發，早就已經不是一個人在戰鬥了，大部分的工程，開發規模5人左右居多，另外稍大的軟體工程動輒幾十人，更有甚者幾百人的團隊規模並行作業。你試想一下，要保證這么多人的產出都符合設計要求，勢必需要合適的開發流程，需要更多的項目管理的技巧和方法。這就對個人以及團隊的提出了非常高的要求了。
軟體工程的方法論中，要求軟體開發者盡可能多地在軟體測試階段發現bug，而不是交付之後。
但是樓主說的能不能讓軟體開發出來沒有bug，我覺得把下面這幾個事情做好，還是有可能的。
1、花盡可能多的時間，和客戶溝通軟體需求，了解每一項需求的用意。
2、確保軟體需求不能隨意變動，因為很多情況下一個需求的變化，程序會帶來很多問題，有可能連底層結構都需要跟著一起變動。頻繁的需求變動，加上開發周期和成本的約束，帶來的結果就是軟體質量的不可控。
3、確保軟體測試質量，完成全覆蓋測試，設計系統需要的全部用例並保證全部通過。
總結下，軟體項目在實際開發過程中風險點還是很多的，通過合理的控制，可以降低和減少bug。但是軟體本身是為人的需求而生，只要需求在變化，軟體是永遠都需要跟著去維護和更新的，所以只要有不可控的因素（需求分析，系統設計，系統詳細設計，編碼，單元測試，集成測試，系統測試，驗收等）任何一個環節任何一個人產生問題，反映到最後的軟體產品上就是一個bug。
另外Bug分很多類，一類是對用戶來說不能正常使用，能被用戶感知到的錯誤。一類是用戶能正常使用，但是有各種異常的錯誤。一類是使用沒有任何問題，但是不符合產品預期的問題。其他應該還有很多，這里我們一一討論。

對用戶來說不能正常使用，能被用戶感知到的錯誤。
其中一種情況是程序員和測試人員的問題，所有功能在上線前，工程師和QA人員應該測試，回歸完功能。能被用戶感知到使用流程有問題的話，一定是相關人員能力或者線上意識某一方面欠缺，也是最不能容忍的。
另外一種情況是黑天鵝事件，什麼網線被挖斷，機房被炸，伺服器爆炸什麼的。。。。。。 ，這個說實話，出了在軟體架構上做冗餘，目前沒有什麼特別好的辦法。

2. 用戶能正常使用，但是在用戶看不到的地方有各種異常的。
一個功能模塊幾乎不可能是獨立的，它必然牽扯到其他模塊。對於你所依賴的模塊，你沒辦法保證這些模塊是100%可用的。這個時候可能雖然有錯誤，但是只要不影響主要流程，我們依然可以正常使用。但這個時候對於外部依賴的異常處理，很考驗工程師的能力。
舉個例子，有可能你看到的點贊數比你實際收到的點贊數少。這個是由於點贊統計在什麼時候失敗了一次，某些用戶可能認為這個是bug，但是其他可能不會在意（當你有10001贊的時候，你在意少了1個么？）
3. 使用沒有任何問題，但是不符合產品預期
這個更多的是研發和產品經理對於需求理解的不一致。因為文字是有二義性的，況且人和人對相同文本的理解本來就可能出現偏差，這就導致了需求理解的不一致，最終導致了線上產品不符合預期。對於內部人員來說，這個也算BUG。
說了那麼多，最主要的核心在於實現功能的是人。人不像機器，不可能不犯錯；同樣的，不可能存在沒有bug的程序，像大家使用的windows，窮盡無數優秀的工程師，給予用戶優秀的桌面體驗的同時，也有你可能完全看不到的數千個bug。想要完全避免幾乎是不可能的。所有也不存在一次性就寫好的情況，鬼知道產品經理什麼時候改需求呢~

2. 評「程序員怎麼樣才能保證自己的程序沒有BUG」

復核代碼的目的有：
* 檢查代碼是否規范，如命名規范，注釋
* 保證一段代碼至少有兩人共同熟悉，可以由任一人來更改。
* 審察未文檔化的細節設計，即由代碼直接表達的設計，由代碼人口述設計並對照代碼
我認為程序員永遠都不會有100%的自信。
即使程序已經發布，被用戶接受很長時間，只有好評沒有抱怨，依舊不能確認有沒有錯誤。
只能假定錯誤是永恆的，它們一直在那裡，只是不到條件爆發。
一個程序員能做的就是，排除所有膚淺的錯誤，加大隱藏錯誤出現的幾率並找到它們，
採用一些容錯性代碼減小可能的錯誤，減少程序發布後爆發的機率。
測試的目的是為了發現錯誤，
沒有100%覆蓋的測試。就是說，總是有一些狀態是測試不到的。
代碼人員認為不可避免地存在錯誤，需要測試，測試人員認為測試覆蓋度不可能100%，還是要代碼小心。
這是一個頭痛的問題，結果是沒有完美的程序。
單元測試是白箱測試，可以根據代碼實現將注意力放到最關鍵的部位。
但仍然不是100%覆蓋的。
單元測試一般針對的是邊界數據，不要求覆蓋度，而更要求有效性。
其目的更主要的是保證代碼更改不會破壞原有的正確性，是提供保障而不是查找故障。
保證沒有錯誤的唯一方法是不寫代碼，減少錯誤的最好方法是少寫代碼。
簡單的設計和實現是減少錯誤的最佳方法。簡單的代碼錯誤必定少。
畫蛇添足式的功能則是最大的錯誤發源地。

3. 你見過最厲害的程序員是怎麼樣的

以前曾經做過十餘年的編程，見識過不少程序員，其中有兩位是比較厲害的。

第一位，J同學，非科班出身，糧食專業畢業的，之後在一個食品廠工作，因為比較清閑，於是他突發奇想，想考某個211的計算機研究生，就去買了書來看，但是要實踐啊，他又沒有計算機，就有空總去公司的電腦室蹭機器用，電腦室的人，就讓他幫忙開發一個工資管理系統，不知道是不是想為難他，結果他研究生是沒考上了，但是經過一個月的摸索之後，居然把工資系統給做出來了。讓電腦室那些科班畢業的人臉上掛不住啊！

之後他就斗膽去了一個國內知名的企業應聘程序員，居然還給應聘上了，慢慢做到了華南區的技術總監，再後來他幾個同事出來創業，高新挖走他。

他這個人就是傳說中的怪俠，非常低調，樸素，不按時上班，不按時下班，工作效率非常高，愛抽煙，請教他什麼問題，他一時想不出來的話，就去外面抽根煙，煙抽完了，回來就會有答案，反正非常神奇。

第二位，B同學，科班出身，211大學計算機研究生，當時是他的導師跟我們單位有來往，推薦過來的，我面試的他，惜話如金，聽說他C語言非常厲害，但是當時我們做項目需要PB，他說他不會，我就說，那給你一個星期的時候，你回去學習一下，再來面試。一個星期後，再過來，給他一個小模塊，很快就做出來，非常棒，之後，項目的技術難題，大部分都是他解決的。平時，他也不怎麼跟我們來往，但是有事就做，也不打 游戲 ，按時上班，按時下班，非常討厭加班。

遇到技術問題，下班後打電話給他，他不接的。有一次，我們第二天系統要上線，大家都在忙著測試，加班，他到點就走了，領導追到電梯門口，問他，XX哥，你走了，他說了一個字，是，就進電梯了。後來也是被高薪挖走，聽說到現在40歲也還沒結婚。

我們公司有一位非常厲害的程序員，基本上一個人當做一個排兵力使用。也就是說一個人寫代碼的效率基本上抵得上10+人的能力，一年隨隨便便寫個幾十萬高質量的代碼。這種人對編程語言的理解已經到了登峰造極的地步，且能夠靈活自如地使用。

在自己編碼能力強的同時，對架構的理解能力也是超強，一個大的系統能夠很快地進行模塊拆分，快速的定義不同模塊間的交互介面，可以快速的安排任務下去。

另外代碼的質量基本上沒地說，導致跟著他的測試人員幾乎發現不了Bug，這哥們在寫代碼的同時基本上順手就把單元測試寫好了，代碼質量高的簡直出奇。

當然了，至於學習什麼新的開源框架或者新的技術架構，基本上就是2-3天的功夫，就可以全面掌握。

目前為止，公司一直當做寶一樣供著。

我見過最厲害的程序員，是在2001年入職的一間香港電路板公司的電腦部經理，他也是最值得我尊重的程序員，那他最厲害的地方在哪裡呢？

編程語言只懂Foxpro DOS版本，但所有的ERP流程，英文、管理方法說得滴水不漏，有一次和財務的同事聊天，才知道他的月薪達8萬多。

很多程序員最怕大老闆提問題，但在他的眼裡，大老闆提問題就是一個商機，多多少少都要老闆加工資加設備。 高情商的表現就是無論下屬或老闆通通管理得服服帖帖，包括我自己，甚至老闆還沒有說話就己經知道老闆的心思了。

老闆分配的編程任務應期三天完成，絕對不過4天。軟體開發效率的提高，自然要依賴下屬心甘情願的加班付出才行，做到這一點，真的是難能可貴。

最厲害也是我最佩的一點就是，40多歲了頭發還沒有一點白的跡象，每天高效率的工作，下班後就拋開工作的煩惱，盡情桑拿按摩享受。

我認為最厲害的程序員不是編程技術，而是如何利用編程技術，不知道你認不認同？

應該是讀研時的學長，精通java和Python，畢業後進去微軟研究院工作。

當時和他在一個項目組，他獨立完成了教學平台語言分析模塊，NLP 模塊。我們團隊任何問題都能很快給出解決方法，前端後端都擅長。

當時我剛接觸linux，他就已經把Linux作為工作學習唯一的選擇。經常用terminal 操作，敲起代碼太帥了

誠邀，本人在杭州華為研究所工作，之前在一家創業公司工作過，公司里一個工作10年的大神，撐著整個創業公司，老闆總能拿到某些項目源代碼，不同語言的，c c++ .net java總之很多，給他，一禮拜就可以全懂了，所有語言基本都是1禮拜搞定(玩代碼的都知道精通一門語言後學其他的特別容易，不外乎面向對象的，面向過程的，然後就是各種API )上手做項目，之前很多不懂的問題問他都可以從本質上分析得很明白，主要是基本上看幾眼就可以知道哪裡錯了。或者大概方向，我後來去華為，都是他建議的，現在還在那公司的他聽說是技術總監了，應該不怎麼敲代碼了。

核心的代碼總是有那一兩個程序員來實現的。比方說現在微信的一開始的核心代碼。

比方說Linux的核心代碼， 都是由林納斯·托瓦茲編寫的， 並且為了能夠讓開源社區的人一起進行開發， 又編寫了Git版本控制。當你不滿意某個軟體或者系統的時候， 能夠自己實現並製作出更好的也許就是厲害的程序員吧。一直到現在很多的系統分支都是來源於Linux的內核。

最後如何成為最厲害的程序員， 還是要學習基礎核心的知識， 操作系統， 數據結構， 演算法， 編譯原理， 計算機網路， 在這個基礎上學習編程都是為了更好地實現自己的心中所想。為什麼這樣寫， 這樣寫會產生什麼效果。 為什麼Golang最近這么熱， 為什麼鴻蒙會被看好， 它又和其他的有什麼區別， 就可以自我判斷， 而不是見風就是雨。

最後希望自己也成為那個最厲害的程序員。

很久以前，我用win98的時候有次我系統崩潰了，因為我是電腦白痴，我朋友給我介紹了一個高手來幫我修電腦。

他看了一下電腦，問我有沒有98的盤，我說沒有。

他想了一下，叫我把固定電話拿給他，我想修電腦要電話干什麼，但人家是高手，我也不好說什麼，就把電話拔下來給他了。

他把電話線空著的一頭接在電腦的一個插孔內，然後進入dos，就開始在電話上不停的按著鍵，他按鍵的速度異常快，但是只按0，1兩個鍵，我搞不懂這有什麼用，但也不敢問，看了半個多小時，他還是不停的按這兩個鍵,我徐徐的有些困，我問他這東西要搞多久，他說要幾個小時，我給他倒了杯茶，就一個人去隔壁睡覺了。

醒來的時候，一看已經過了4個多小時，我起身到隔壁，看見他正在98裡面調試，過了一會兒，他說，你試試，我坐上椅子用了一下，真的好了，我當時也不懂電腦，謝過人家就走了。 後來我慢慢對電腦有了了解，終於了解，原來當時那位高手是用機器語言編了一個98系統，我後來問我朋友那位高手的下落，我朋友說前幾年去了美國之後，杳無音訊....

五年前有幸在一家軟體公司做產品經理。小的軟體公司。坐標西安。招人還挺不好招的。雖然給的薪水還不錯。但是真心不好招人。這種小軟體公司沒有名氣。真正牛逼的人都不來。

百試幾百人，包括做產品和前端的也算在裡面。光程序員這塊。有百分之六十的投簡歷的都是從某培訓機構出來的。所以的項目經歷。和待過的公司都是一模一樣，有明顯的人為的痕跡。

但是後來實在沒有人手。招了一兩個，差。差。差。真是差到極點

後來又經人推薦，招了一個，說是做安卓開發的。結果連個軟體的心跳包都調不好。軟體的升級這塊都搞不定。最後還是我這個外行，逼著他。一點一點卡，才把軟體升級這塊稍微搞上路了。

說出來真是讓大家笑話，華為的外包中軟國際。有個孩子實在忍受不了裡面的虐待，在裡面工作了一年半。然後跳到我們公司。這個孩子，才是稍微讓人可以用一下。就是起碼。你給他的工作。他能完成。其他的人都是在摸魚。因為這個公司的老闆以前也不是做手機軟體這塊。沒有資源，不認識人。

他是做電腦PC軟體，到後面做BS系統多一點。其實這種沒有技術含量，找的別人的框架。去修改。

普通人見不到最牛逼的程序員，最牛逼的程序員，一定是在最牛逼的軟體或者互聯網公司的深宮後院裡面。還沒出世的。就像當初的張小龍，史玉柱，裘伯君一樣。

你現在能看的牛逼的，感覺牛逼的。都是因為你不懂這個。你才覺得牛逼。包括前幾年比較活躍的黑客們，製造一些病毒。這都不是牛逼。包括熊貓燒香的李俊，普通人覺得他可牛逼了。但是真正的他出來後，去金山 360這種公司，提鞋別人都不要。

因為搞破壞不是牛逼。也不是自己水平有多牛逼。

我來講一個我見過最厲害的程序員。

這個程序員是我第一份工作碰到的大牛，我的第一份工作在中興通訊成都研究所，當時是做操作系統研發的。

我們當時經常會做一些培訓和技術分享，那時候我才入職3個月，我發現公司里有個人每次技術分享時候，就很多人去聽，並且會議室爆滿，連站的地方都沒有，然後我有次也去聽了一下， 第一每次目睹大牛的風采，因此操作系統是最底層的研發工作，會涉及到內核這塊知識，而linux內核知識特別抽象，看書根本很難看懂，但是這個大牛能把很難的東西講的很容易理解，並且在會上面對大家的提問總是能對答如流，實在是厲害。

而後我通過公司里的老員工才了解到，這位大牛是自學成才的，他的文化程度才初中，破格錄取到中興通訊，當時是操作系統部門的技術專家，他都能自己編寫操作系統，對各硬體都非常了解，也出了很多書。可見興趣是最好的老師，讓他能夠在程序員中發光。

必須是ACM大神，樓天成，樓教主。不了解他的可以網路之。是個天才一般的存在。
幾年前清華大學找同學玩，他那時是清華軟體學院的學生，突然說要帶我去見他的偶像，還說是最後的機會了，我們跑去計算機學院，當時博士正在答辯，通過在場的同學找到了他，他很靦腆的千呼萬喚始出來。他們兩在那裡交流了半個多小時，最後互留了EMail，我跟他聊了些我專業的內容，他還蠻好說話。 後面還通過這位同學認識另一位ACM屆大神，上海交大的戴文淵。我對編程略有了解，主要還是崇拜天才。

4. 如何向 程序員 描述 bug 笑話

1.程序員寫出自認為沒有Bug的代碼。

2.軟體測試，發現了20個Bug。

3.程序員修改了10個Bug，並告訴測試組另外10個不是Bug。

4.測試組發現其中5個改動根本無法工作，同時又發現了15個新Bug。

5.重復3次步驟3和步驟4。

6.鑒於市場方面的壓力，為了配合當初制定的過分樂觀的發布時間表，產品終於上市了。

7.用戶發現了137個新Bug。

8.已經領了項目獎金的程序員不知跑到哪裡去了。

9.新組建的項目組修正了差不多全部137個Bug，但又發現了456個新Bug。

10.最初那個程序員從斐濟給飽受拖欠工資之苦的測試組寄來了一張明信片。整個測試組集體辭職。

11.公司被競爭對手惡意收購。收購時，軟體的最終版本包含783個Bug。

12.新CEO走馬上任。公司雇了一名新程序員重寫該軟體。

13.程序員寫出自認為沒有Bug的代碼。

5. 程序員寫程序時，有哪些減少bug的好方法

深有體會，肺腑之言：

1. 晚上10點之後千萬不要寫代碼，每次我這個時候寫代碼總會左眼睜著右眼閉上，右眼睜著左眼閉上，我表示10點之後寫代碼那是開玩笑。雖然有時後不是很困，然後自我感覺很良好，但是，但是，第二天自測，或者QA測試的時候那就呵呵。。。寫代碼5分鍾，查bug倆小時。

2. 寫代碼前可以自言自語，或者寫在紙上。把要做的東西說一遍，理清楚了再寫。
   

3. 寫代碼千萬不能著急。領導催，pm催，那也是急不來的。必須按照平時的速度，一步一步的來，心浮氣躁，心神不寧的狀態不能寫代碼。

4. 寫注釋，寫注釋，寫注釋。重要的事情說三遍。代碼就像天書（這點相信看過別人代碼的人深有體會），而自己的代碼呢，當時覺得清新易懂，過個兩三天就不那麼回事了。寫上注釋有利於後續開發的時候容易減少bug和定位bug

5. bug有很多種，語法上的，邏輯上的等等。對於語法錯誤，很好解決。使用集成的開發環境，一般都會有語法檢查，高亮提示等功能避免產生。然後