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

日常工作中發現一些基礎很好的程式員，熟知各種設計模式、演算法等高大上的技術，可是寫的代碼依舊很爛、漏洞百出，並且一直在用最basic的方式編程。

例如忽視很多語言的新特性和新的架構，忽視好用的工具，很喜歡寫原生的SQL，並且使用很老的架構和很老的方式編程。

這是什麼原因造成的呢？這樣的情況在你的身邊是否很普遍呢？

回複內容：

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

原生SQL->ORM->原生SQL教授寫代碼，大括弧不換行。。
但人家是國家電腦中心的大大 。…根本不在意style

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

情境一

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

情境二

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

過了三天，經理又來問：做的怎麼樣啊，快完了吧？實在不行，再加加班吧！這時，技術心裡肯定在想：加你MB，累死老子了。

看看，大多數程式員根本沒時間考慮代碼的執行效率什麼的，在僅有的短時間內，能省則省，能快則快，什麼高品質的代碼啊，這也只有在加班的夢中想象。

情境三

在新人介紹會中，行政帶著新來技術人員，給大家一一做介紹，產品經理過來說：一會過來一下，我把上個離職人員的代碼給你，順便給你分配一下任務，你先把代碼熟悉一下，之後馬上投入開發中。

新來技術在拿到代碼後，看了一會說：靠，什麼爛代碼啊，寫的真爛。

哈哈，中槍了沒有，中槍的有木有，多人的迭代和代碼交接，各種風格亂入，一眼望去代碼就像被豬啃過的草原。看到頭疼的代碼，都懶得修改了。代碼品質高？也搞不過多個神人的迭代和寫碼。

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

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

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

著名的移動互連網專家，自媒體人，運營的公眾號“非著名程式員”，每天一篇原創技術分享和移動互連網知識分享，公眾號：smart_android ，頭條號和百度百家帳號都是“非著名程式員”。

一些orm架構支援的查詢模式單一，在非主鍵查詢時十分彆扭。寫出好的代碼不僅需要良好的基礎，還要有良好的品味！對代碼的美學追求，是在有超過基本工資之外的回報的時候才會去把玩的東西。要麼是開源給別人看，要麼是給妹子交作業，有回報當然幹得賣力。其他有些東西隨手寫寫，反正又不用複用，就這樣吧，改好了也沒人給我錢和鮮花或避孕套。

不過我說的不美和你們說的難看可能不是一回事。就算隨手寫，也不會比你們想的難看多少。1、不會；
2、不樂意；
3、不值得；
4、來不及；
5、不漂亮不代表有問題，也許人家從更高的層面解決了；查詢寫原生的SQL問題不大->ORM查詢上實現不了跨平台，ORM不看源碼，還不知會不會有注入。簡單的增刪改還是拼sql就有問題。

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

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

新特性和新的架構是否是好的，應該先在家實驗，最後才能用的工作上，不然個人覺得不太好。聽過很多道理，卻依然過不好這一生

