程序員老是出bug

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

軟體可能在使用過程中沒有任何問題，但不符合產品的預期下圖源自「How projects really work？」，很形象的突出了客戶需要的產品和最終得到的產品不一致。

所以軟體想要變得成熟，Bug收集和處理機制是非常有必要的，比如：會影響客戶使用的優先順序高的Bug要優先修復。Bug是軟體的影子，也是程序員的噩夢實際上不能存在沒有bug的軟體，Bug和軟體如影隨形。就像我們使用的Windows，窮盡無數優秀的軟體工程師來設計給用戶優秀的桌面體驗，但也有各種層出不窮的bug。

程序員對Bug有多愛就有多恨，Bug無處不在，即使再牛逼的程序員也逃脫不了Bug的魔掌。想要完全避免Bug幾乎是不可能的，所以也不在一次性就寫好的程序。以上個人淺見，歡迎批評指正。認同我的看法，請點個贊再走，感謝！喜歡我的，請關注我，再次感謝！

⑵ 程序bug出現的原因是什麼

原因是多方面的，比如程序邏輯不嚴謹、程序變數類型設置不當、程序演算法不完善等。

⑶ php程序員寫的代碼為什麼總有bug

弱類型以及即編即譯等等靈活的特性，註定PHP必須要有犧牲一定的穩定性的前提來達到。換句話說，通常JAVA中一些BUG可以通過編譯機制可以盡早的扼殺早搖籃之中，即使是運行期的錯誤，也可以通過編譯機制找到。同時，強類型語言的嚴謹的代碼編寫風格，也不容易出現由弱類型語言中那些讓人又愛又恨的類型自動轉換發生的意想不到的行為。

最終，我可以認為PHP為了快速開發，做出了他應有的犧牲。把更多的代碼控制權力交給程序員，而不是交給機器，這也意味著代碼的有效性考驗著作為程序員本身的編程能力。更可能是程序員本身對編程思想的理解程度。不過，PHP大多數都是用來開發web站點，而且還有很龐大的社區，以及許多優秀的框架，這些都可以幫助PHP程序員在開發中減少不必要的麻煩。

BUG不可避免，BUG與否決定在你！

個人經驗，少年，你如果要開發應用的話，這個年代不用框架，就等於自己為自己增加N倍的難度。在下推薦幾款框架給你吧：
LARAVAL （強力推薦），YII，codeigniter.......

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

作為一名程序員，我也總是在調試，Bug總是防不甚防的出現，這個過程真是有趣又痛苦，最後我覺得習慣就好，一次性寫出完美代碼是每個程序員不可實現的夢想。

沒有哪個程序員可以寫出完美的代碼，即使高能又偉大的公司也做不到這一點，想想看你的手機軟體是不是經常提醒你該更新了，連微軟都在三天兩頭的讓你打補丁，不是嗎？

⑸ 軟體存在bug是程序員把代碼打錯了造成的嗎

從你的描述來看，軟體存在bug，不是程序員把代碼打錯了，而是代碼設置不合理，比如需求不合理，軟體的操作上，設計上原本就存在邏輯漏洞，多個單體能夠正常工作的模塊結合到一起產生問題，異常場景沒有考慮到等等，很多原因都可能產生bug。

⑹ 程序員遇到解決不了的bug怎麼辦

但大部分程序員都有一個問題就是不太願意測試自己的代碼。他們草草的調式完成以後就認為工作結束，測試那是測試人員的工作。
1. 影響了程序員自己的聲譽
2. 影響了產品的質量
3. 影響了客戶的信任度
4. 這個時候再 DEBUG 難度增大了許多。
大的不說，就說多自己聲譽的影響吧。如果你的程序總會有這樣那樣的 BUG ，你得到收益會減少，即使你寫了很多代碼。
程序員必須克服一些自身的致命缺點才能夠從根本上解決這個問題。那麼這個問題是什麼?前面我們已經提到，程序員對自己的代碼都非常寬容，認為那是正確的沒有問題。實際上這種想法比較正常，程序是通過程序員思考和設計之後才寫出來，程序員不會將自己認為不正確的東西寫到代碼里，而到這個時候都一直假設程序是正確的;但人非聖賢，怎麼可能不犯錯誤來。實際上程序員在對待其他程序員時候的態度就很好，帶著一種挑剔和學習的態度;但一旦對待自己的代碼就很難這么做;這就是最致命的。程序員也必須對自己的代碼帶著挑剔和學習的態度;這個基礎是假設自己的代碼是錯誤的，然後需要做的是怎麼樣證明自己的代碼是正確的。程序員自身可以在程序生成的每個階段做這些工作：仔細的設計(這個時候畫點時間是值得的，必須保證我們對自己的程序有清晰的輪廓後才能開始動手寫)、編寫代碼時、單元測試(單元測試的重要性就不在贅婿了)、功能測試。
仔細的設計：這個的仔細是說在程序員編寫代碼之前，其必須對代碼的整個結構以及邏輯結構有明確的清晰的了解，只有這個時候才可以去寫代碼。這里沒有談到文檔，但我說到了一定要清晰的思路，但清晰的思路不是每個人都可以在腦袋中直接形成的，很多人都是普通人，沒有辦法在腦袋瓜中把所有問題都想清楚，那麼就記下來，特別對於復雜的邏輯。
編寫代碼：對於沒有把握的代碼，例如：新設計的演算法，最好保證其正確性。可以單獨將這部分測試，這可以讓代碼模塊化的同時又保證了代碼的正確性。一句話：少量的代碼保證質量還是比較簡單的。
單元測試：單元測試的重要性不在贅敘了，現在也有許多工具可以幫助程序員並減少工作量。
功能測試：程序員保證自己代碼質量的最後一關;為了做這樣的工作我們可能必須寫一些代碼來測試，甚至是測試工作。使用大量的 CASE 來測試，以及錯誤的 CASE 。這里和測試人員的測試不同之處在於：仍然讓程序員的注意力放在其自己的代碼范圍內，減小了排錯的難度。
如果你通過了以上的步驟都找不出你程序中有任何問題的話，那麼我想你的程序應該足夠健壯了。其實還有一點必須說明的就是：代碼 REVIEW 。
前面說道了程序員對待別人代碼的態度是挑剔和學習的態度，所以讓其他程序員來 REVIEW 你的代碼也是檢查程序有沒有邏輯錯誤的很好的辦法。團隊中應該交叉 REVIEW 代碼，這是實踐的經驗。
作為一個好的程序員必須有以上的習慣，以及對待自己代碼象孩子一樣，我們要愛惜我們的代碼，同時也要讓代碼走正確的路。

⑺ 程序員如何讓自己的程序少出BUG(轉)

軟體測試心得
，而且還經常寫一些工作上的事，現在感覺自己老了似的，開始轉型了，會選擇寫一些總結而不是瑣碎，也許這是我以後當領導的徵兆吧。
程序員是善於思考的一個職業，做過這行的都知道，寫一個程序的過程都要經過構思、設計、寫代碼、測試到最後運行這幾個步驟。慢慢地，這個習慣也被搬到了生活中，現在我才覺得，我平時做事這么的冷靜善思考原來是工作影響的原因。
象我一樣，大多程序員都有一個毛病，或者說一個習慣，自己編寫過的代碼都不願意測試，他們憑著自己的習慣，理論上完成了代碼的編寫就認為自己的工作結束了，剩下的工作應該交給測試人員了。但實際上來講，如果代碼存在BUG，造成軟體在運行期出錯，那麼測試人員和客戶肯定會發現這些BUG的，再等到測試人員或者客戶把BUG反饋回來的時候代價就已經很大了，不僅僅是時間的浪費，更重要的還有1、影響了客戶對產品以及公司的信任度，2、影響了程序員自己的聲譽，3、影響了代碼的可讀性以及質量，4、增加 了DEBUG的難度，5、對程序員的心理造成一定的影響。
首先，程序員應該克服自己身上的一些缺點，這是很重要的一點，因為每個程序員都有自己的編程習慣，而且每個程序員對自己剛剛完成的程序都會信心百倍的說「絕對沒問題」，實際上這種想法很正常，因為每段代碼都是通過程序員認真謹慎的思考和設計之後才寫出來的，在設計時已經排除了很多問題，所以程序員不會將自己認為不正確的判斷寫到程序里，但這僅僅是理論上的想法，但人哪有不反錯的時候。其實程序員在讀其他人寫的程序的時候，就會很謹慎，仔細找到程序上的錯誤，但對自己的代碼就很難這樣做，如果把這種謹慎應用到自己的代碼上來，BUG會減少到最少。軟體工程所說的各階段工作想必大家都清楚，前期的設計以及需求分析才是一個軟體工程的重點，這里也是花費時間最多的地方，當對要寫的程序有了一個清晰的輪廓之後再動手編寫代碼。
第二，剛剛提到的前期設計，是指在編寫代碼之前所作的工作，這要求程序員對系統的整個結構以及邏輯有很清楚的理解，這也要求對系統的需求做到位。我沒有寫過文檔，所以這里不談文檔了。思路清晰很重要，但每個人並不能將系統的整個設計思路都記在腦袋裡，那最好就寫下來，特別是一些復雜的邏輯結構關系還有復雜的演算法。
第三，代碼的編寫，要盡量減少拼寫的錯誤，嚴禁使用關鍵字作為變數來使用，要盡量做到代碼模塊化，並且保證其正確性和可重復使用性。因為是模塊組成的，寫過之後可以將每個模塊部分單獨測試，因為代碼量少了質量自然提高了。對順序執行要求很高的函數盡量不採用調用子函數的方法，讓程序按順序走吧。
第四：代碼檢查以及系統功能測試，這是保證代碼質量的最後一步了，我們可以寫一些代碼模塊或者小工具來進行測試工作，跟蹤變數值的變化，使用一些小技巧在這個階段都是必要的，這里和測試人員的測試不同之處在於：仍然讓程序員的注意力放在其自己的代碼范圍內，減小了排錯的難度。
按照如上步驟來走的話，那麼我想你的系統應該足夠健壯了。
把對待別人代碼的態度放到自己的代碼上來，也就是反復的Review自己的代碼檢查邏輯錯誤也是相當好的辦法。別把自己辛苦寫的代碼看的很值錢，在團隊中盡量與別人分享、Review代碼這是實際工作的經驗。
作為一個優秀的程序員要具備這些習慣，看自己的代碼就象對待自己的一樣，愛惜、呵護是必須的，同時也要象園丁一樣及時修剪多於的樹枝來讓自己的代碼走正確的道路。

⑻ 資深程序員可以避免敲代碼時出現bug嗎

程序員遇到bug是在正常不過的事情了，就算非常資深的程序員也無可避免bug的存在，一般來說，除非你寫一輩子 Hello World。
不過世界上的確存在一些鳳毛麟角天才的程序員，他們差不多能做到這一點。接到任務之後，思考，冥想，在筆記本上畫出數據結構或某個演算法片段，腹稿打的差不多了就開 始編程，用 Vim、Emacs 或 IDE 工具，大部分時候能夠一氣呵成，然後構建代碼，構造測試數據，運行程序，在反復調試中修復幾個編程過程中沒有考慮到的問題，就可以提交到代碼庫了。
他們的 代碼交給測試和其他開發者，少有人能挑出 bug，因為他們對代碼有敏銳的感覺，能夠在別人忽略的地方發現代碼的壞味道，並給出巧妙而優雅的解決方案。
他們是天生的代碼創造者，這樣的人往往效率高 而且少有錯誤，以至於會被一些平庸的團隊忽略，因為技術領導總是會下意識的去關注那些最容易出事的環節，但這些人才是團隊真正的脊樑，不是那些四處救火者。

⑼ 身為程序員，當程序出現bug時，是一種怎樣的體驗

當程序出現bug的時候，程序員會有兩種感覺，一種是終於可以提現自己的價值了，當自己把bug修復好的時候，就會有一種成就感，但是如果很難修復的話，就會很頭疼，所有很多程序員很早就有一部分發際線就會變高。