程序員為什么要一直改bug，不能一次性寫好嗎？代碼中出現(xiàn)bug是正常的。我們可以最大限度地避免錯(cuò)誤，正如偏差必然存在，可以無(wú)限接近正確性一樣，但是錯(cuò)誤可以通過(guò)良好的工作方法、編碼規(guī)范和工作習(xí)慣來(lái)避免和

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

代碼中出現(xiàn)bug是正常的。我們可以最大限度地避免錯(cuò)誤，正如偏差必然存在，可以無(wú)限接近正確性一樣，但是錯(cuò)誤可以通過(guò)良好的工作方法、編碼規(guī)范和工作習(xí)慣來(lái)避免和消除。無(wú)論是整個(gè)項(xiàng)目的開發(fā)還是部分代碼的擴(kuò)展，程序員開始的編碼工作都必須從實(shí)際需求出發(fā)：

首先要弄清需求的來(lái)龍去脈，然后確認(rèn)對(duì)需求的清晰理解。確認(rèn)需求是否被理解的最佳實(shí)踐是編寫需求描述、概要設(shè)計(jì)，然后與干系人/負(fù)責(zé)人確認(rèn)，而不是口頭說(shuō)他們理解，甚至不理解重復(fù)確認(rèn)。

第二步是驗(yàn)證概要設(shè)計(jì)中的技術(shù)要點(diǎn)，細(xì)化設(shè)計(jì)，在細(xì)化設(shè)計(jì)過(guò)程中設(shè)計(jì)項(xiàng)目名稱、類名、代碼調(diào)用框架、方法名稱、成員變量和關(guān)鍵變量名稱，然后與利益相關(guān)者和負(fù)責(zé)人確認(rèn)。

第三步，良好的編碼習(xí)慣、編碼規(guī)范非常重要，也直接體現(xiàn)了程序員的基本素質(zhì)，思路清晰，良好的編程習(xí)慣是高質(zhì)量代碼的重要保證。

最后一步是代碼測(cè)試。程序員交付的代碼必須保證單元測(cè)試能夠通過(guò)閉環(huán)測(cè)試，然后開發(fā)人員進(jìn)行交叉測(cè)試。然后交給QA測(cè)試部進(jìn)行測(cè)試，因?yàn)榇嬖谝恍肮庀潞凇钡膯?wèn)題，程序員很難發(fā)現(xiàn)；對(duì)于大的代碼調(diào)整，還需要進(jìn)行回歸測(cè)試，測(cè)試所有的功能和各種環(huán)境，回歸測(cè)試的工作量通常很大。

優(yōu)秀的軟件產(chǎn)品是在項(xiàng)目實(shí)戰(zhàn)中設(shè)計(jì)、開發(fā)和使用的。它們不斷改進(jìn)、測(cè)試、交付和迭代使用。它們不可能一蹴而就。工作方法、代碼規(guī)范、編碼習(xí)慣和測(cè)試控制是保證代碼質(zhì)量的關(guān)鍵。編寫需求、設(shè)計(jì)和測(cè)試文檔不是教條主義，更不是浪費(fèi)時(shí)間，與智力無(wú)關(guān)。然而，許多程序員并沒(méi)有對(duì)它給予足夠的重視，他們從內(nèi)心到行動(dòng)都在抵制它。然后讓現(xiàn)實(shí)一次又一次地打耳光，慢慢地成長(zhǎng)，我們應(yīng)該開始重視它，深刻認(rèn)識(shí)到“只做一次正確的事”是最省時(shí)的。然后，我們可以用自己的血淚史或規(guī)章制度來(lái)教導(dǎo)和約束新程序員。

微服務(wù)調(diào)用為啥用RPC框架，http不更簡(jiǎn)單嗎？

簡(jiǎn)單一點(diǎn)，HTTP是協(xié)議，RPC是概念！RPC可以基于HTTP協(xié)議（feign）、TCP協(xié)議（netty）、RMI協(xié)議（soap）和web服務(wù)（XML-RPC）框架實(shí)現(xiàn)。在傳輸過(guò)程中，由于序列化方法的不同，也出現(xiàn)了一些框架和協(xié)議，如Dubbo中的Dubbo協(xié)議、grpc protobuf序列化協(xié)議等。實(shí)際上，它們都是基于遠(yuǎn)程調(diào)用的概念。什么是遠(yuǎn)程呼叫？

關(guān)鍵是RPC是遠(yuǎn)程調(diào)用。遠(yuǎn)程調(diào)用是客戶端通過(guò)上述協(xié)議向服務(wù)器發(fā)送接口、參數(shù)、參數(shù)類型、方法、返回值、返回值類型等（稱為方法簽名），通知服務(wù)器要調(diào)用的接口方法。這個(gè)過(guò)程就是RPC的實(shí)現(xiàn)過(guò)程！HTTP和RPC是兩碼事

！在性能方面，HTTP本身是基于TCP協(xié)議的，屬于應(yīng)用層協(xié)議，所以HTTP協(xié)議本身在實(shí)現(xiàn)過(guò)程中會(huì)占用大量的資源（內(nèi)存、帶寬等）。在性能方面，它肯定不如直接通過(guò)TCP實(shí)現(xiàn)的RPC協(xié)議快。不管HTTP有多優(yōu)化，它絕對(duì)沒(méi)有TCP那么快！另一方面，TCP依賴于字節(jié)碼。目前常用的是將客戶端調(diào)用的接口信息以序列化的方式發(fā)送到服務(wù)器端。序列化框架包括許多內(nèi)容（Hession、protobuf、kryo等）。Kryo具有最高的序列化性能，protobuf具有序列化后最小的字節(jié)碼）。序列化后的字節(jié)碼越小，占用的帶寬越小，序列化時(shí)間越長(zhǎng)，線程IO延遲越短，線程IO延遲越小。因此，在具體的應(yīng)用層，有很多技術(shù)可以討論。您可以根據(jù)自己的硬件能力選擇相應(yīng)的技術(shù)

！歡迎熱愛科技的人們來(lái)探索！