為什麼基礎很好的程序員代碼依舊寫的很爛？

01-02

日常工作中發現一些基礎很好的程序員，熟知各種設計模式、演算法等高大上的技術，可是寫的代碼依舊很爛、漏洞百出，並且一直在用最basic的方式編程。
例如忽視很多語言的新特性和新的框架，忽視好用的工具，很喜歡寫原生的SQL，並且使用很老的框架和很老的方式編程。
這是什麼原因造成的呢？這樣的情況在你的身邊是否很普遍呢？

怎麼寫出一手漂亮的代碼，跟代碼本身運行的怎麼樣，是兩個互相獨立的問題。這就如同一台電腦是否強勁和外觀是否夠騷一樣，你學會了一個不會自動得到另一個的知識。

教授寫代碼，大括弧不換行。。

但人家是國家計算機中心的大大。…根本不在意style

導語：有心寫碼，無力高效。bug其多，痛哉痛哉！有時候我們的寫碼的環境是和譚嗣同的心情一樣一樣的，為什麼呢？因為譚嗣同的絕筆是這樣寫的：「有心殺賊,無力回天。死得其所,快哉快哉!」。

場景一

在功能需求的會議上，產品經理問技術：「這個功能大概需要幾天能實現啊？」，技術：「一周吧」，產品經理：「給你三天時間，代碼先跑起來再說」。我靠，有木有，有木有，別想太多，先讓代碼跑起來，大家都是這樣乾的，先實現功能，代碼以後再改，在優化。這簡直就是心安理得的神借口。多少有心寫好代碼的人都死在了這樣的借口之中。準備時間不足，前期沒有好好的思考整個需求框架，沒有縝密的邏輯思考，沒事，先跑起來再說，這只是我們代碼質量差的原因之一。

場景二

在每周的例會中，產品經理和老闆問：怎麼樣，上周任務都完成了吧，這周給你5天時間，必須把剩餘功能全部實現，趕緊的。技術那疲憊的樣子，在睡眼惺忪的狀態下，愛答不理的說：好。

過了三天，經理又來問：做的怎麼樣啊，快完了吧？實在不行，再加加班吧！這時，技術心裡肯定在想：加你MB，累死老子了。
看看，大多數程序員根本沒時間考慮代碼的執行效率什麼的，在僅有的短時間內，能省則省，能快則快，什麼高質量的代碼啊，這也只有在加班的夢中想像。

場景三

在新人介紹會中，行政帶著新來技術人員，給大家一一做介紹，產品經理過來說：一會過來一下，我把上個離職人員的代碼給你，順便給你分配一下任務，你先把代碼熟悉一下，之後馬上投入開發中。
新來技術在拿到代碼後，看了一會說：靠，什麼爛代碼啊，寫的真爛。
哈哈，中槍了沒有，中槍的有木有，多人的迭代和代碼交接，各種風格亂入，一眼望去代碼就像被豬啃過的草原。看到頭疼的代碼，都懶得修改了。代碼質量高？也搞不過多個神人的迭代和寫碼。

看到以上三個場景，有木有中槍，是不是深有同感？有時候是不是想有心殺賊，卻無力回天啊？當然我上面說的都是大部分普通程序員的辛酸經歷，並不代表所有的程序員，高手，大牛或者大公司並不會這樣。但是總結上面的三個場景，可以用一句話說：時間不夠，代碼來湊；人走人來，代碼混亂。

代碼質量差，bug多？我們都是被逼的，有時候多想產品經理或者老闆給我們足夠的時間去整理邏輯和代碼，優化出一道靚麗的風景線。多麼想每個人都能把代碼帶上注釋，看起來舒心啊，因為你沒做到，你就沒資格要求別人做到。還記得那個關於寫注釋的經典話嗎？程序員最討厭的兩件事:1.寫注釋2.別人不寫注釋。就是這樣的道理。

代碼質量差，bug多？我們都是被逼的，讓我們大聲吶喊出來吧，別憋著，再憋壞了。產品經理啊，老闆啊，知道你們也不容易，時間緊也是迫不得已，希望你們也能多體諒一下我們程序員。我們都不容易，我們更是被逼的。

著名的移動互聯網專家，自媒體人，運營的公眾號「非著名程序員」，每天一篇原創技術分享和移動互聯網知識分享，微信公眾號：smart_android ，頭條號和百度百家賬號都是「非著名程序員」。

SQL進階

原生SQL-&>ORM-&>原生SQL

1、不會；

2、不樂意；

3、不值得；

4、來不及；

5、不漂亮不代表有問題，也許人家從更高的層面解決了；

talk is cheap show me the code

一些orm框架支持的查詢模式單一，在非主鍵查詢時十分彆扭。

其他的不表，忽視新特性可能是習慣問題。而「新框架「、好用的工具不等於熟悉的工具，你覺得好用不等於別人覺得好用，而且用別人的東西意味著掉到坑裡面的潛在可能，也意味著如果哪一天要換框架成本會較高。我平時工作也用Qt，我同事全面擁抱Qt，我就非常的不同意，於是我就在整天琢磨怎麼寫可以哪天用std替代成本低。

喜歡寫原生SQL那要看他解決什麼問題了，為什麼一定要ORM？ORM很多時候並不能節約時間。我以前一個構架師可以直接在SQL裡面寫業務邏輯，性能飛快，很多人做不到吧？

查詢寫原生的SQL問題不大-&>ORM查詢上實現不了跨平台，ORM不看源碼，還不知會不會有注入。簡單的增刪改還是拼sql就有問題。

知道，和知道為什麼用，是兩回事——不能因為是新的就來用。

新的東西會有兼容性的問題，比如新jquery就不支持低版本ie。

新特性和新的框架是否是好的，應該先在家實驗，最後才能用的工作上，不然個人覺得不太好。

幹嘛要用新框架，只有初學者才為了顯擺喜歡新技術新框架，不去考慮穩定性

對代碼的美學追求，是在有超過基本工資之外的回報的時候才會去把玩的東西。要麼是開源給別人看，要麼是給妹子交作業，有回報當然幹得賣力。其他有些東西隨手寫寫，反正又不用復用，就這樣吧，改好了也沒人給我錢和鮮花或避孕套。

不過我說的不美和你們說的難看可能不是一回事。就算隨手寫，也不會比你們想的難看多少。

寫出好的代碼不僅需要良好的基礎，還要有良好的品味！

我有一個很熟的朋友，他現在忙的不可開交。他手上有一大堆沒有完成的合同，而且一個跟他一起開發的助手也離他而去。於是，在三個大客戶的催命鬼時的督促下，他已經連續好幾個星期沒休息了。

其中有個客戶跟他討論他給這個客戶做的iPad應用程序，客戶告訴他「我們花錢雇了另外一個程序員來審查你的代碼，他說你的代碼寫的很爛。」

當他告訴我這個故事時，我只是微微一笑，想起了我以前是怎麼唾棄別人的代碼的。當我剛開始編程時，我看到過一段程序，我認為那是毋庸置疑的寫的很爛的，我刪掉了那段代碼，用自己認為更好的方面重新寫了一遍。當我變成的成熟後，我回頭再看，發現我所刪掉的那段代碼其實是用了一個很好的設計模式，而我重寫的確是醜陋無比。

我就這樣被上了一課。

之後的日子裡，我經常會遇到我認為是丑的不能再丑的代碼。儘管如此，我也不通篇否定它們了，我只會在其中找一些特別的無法容忍的部分重新編寫。可10次中有9次，當我快要完成時，我發現了一個問題使我不得不對自己說「哦，怪不得他們要寫成這樣了」，然後把代碼恢復成原樣，或也使用同樣「丑的不能再丑」方式完成它。

現在我變的更成熟了，我可以充滿自信的告訴你，我再也不會看著別人編的代碼說「哦，這代碼很爛」了。我知道，在沒有了解整個程序的解決方案之前，你不可能就那麼輕易的判斷代碼的好和壞。真的，有時候它看起來很傻，或完成的不好，或沒有文檔標註（我的意思是自我注釋），然而，你根本就不可能知道程序員在寫這段代碼時腦袋裡是怎麼思考的。更多的情況是，他們要選擇這樣做是有一定的理由的，除非去深入的研究它們，你不可能再有其他簡單快速的方法來理解程序的上下文環境。

所以，每當聽到有人看著別人的代碼說很爛時，我只會微微一笑，讓我想起我當年的天真和盲目自信。的確，我以前堅信自己是個出色的開發人員，堅信知道每種演算法的最優設計。我很想念當時的自大，但是我很高興現在學到的這些理念，我知道，我唯一能鄙視的代碼只能是我自己的代碼，鄙視的原因就是我不能使它變的更好。

來自：外刊IT評論

鏈接：你的代碼寫的很爛

原文：Sara J Chipps, software blog

聽過很多道理，卻依然過不好這一生

代碼寫的好，只需做好一件事，學會分析拆解問題，假設這個問題是需要多人合作，為了減少帶來的風險，每個人的部分之間需要通過橋樑（橋樑可以是幾個變數，可以是磁碟文件，可以是介面，可以是網路協議，可以是通知，可以是任何可以是橋樑的東西）銜接，大到系統架構小到一個函數全部適用這一原則。這樣每個人的部分就可以逐個擊破，保證自己是正確的，可讀性好的，整個就是好的。這個東西需要悟性與訓練，關鍵是需要有一個導師能告訴你他的經驗，不需要特別多，悟性好的人可能一次談話就能領悟。還有一點不要怕刪代碼，不好就刪，完了重寫，每次都是一次進步。

自以為聰明卻只愛夸夸其談的程序員太多了

TL;DR 沒有必要。代碼華麗是給人看的，機器運行不看這些。

首先（代碼好看（代碼用新特性（代碼用新框架（代碼運行穩定（代碼運行高效（代碼維護方便都是各自獨立的命題

誠然新特性/新框架的出現是為了解決過去程序開發中的坑，但是一般來說這些新特性和新功能在沒有生產環境大量測試的情況下自己的存在就是一個坑。如果有過用新事物來開發大規模軟體的經驗的話，則更容易意識到這個問題。

這方面，最明顯的例子莫過於新語言了，看起來華麗的特效、組織有序的代碼很可能實際運行起來滿地的bug（看到的吐槽最近的swift的帖子，簡直不能再多），在充分測試之前大多數只不過是玩具。如果論生產效率還不如用C語言宏實現的紅黑樹（jemalloc），雖然代碼看起來不怎麼樣、也很難維護，但是實際效果也是厲害，還合併進了FreeBSD的源碼中。

根據你描述的癥狀，依我的經驗判斷原因有三：

1. 校招後遺症，有的人很快痊癒成為大牛，還有不少過不了幾年就轉行了，此類人就是散布程序員干不過三十的主力之一。

2.要看他是什麼崗位，可能工程經驗不足，但在他自己的領域裡是很牛叉的。另外我覺得用框架用插件用工具都是為了提高開發效率，但在有些情況下運行效率更加重要。比如你說的寫原生sql，我認識的不喜歡寫原生的還真沒有, 那查詢效率杠杠的，直接後果就是省錢！

3. 學習能力不足。設計模式演算法這種東西學一遍用n年，你說的那些都是需要不斷學習更新的。

沒純粹就是個美學問題，我也一直在思考！

漂亮的代碼不一樣效率就高