俗話說得好：代碼擼得好，搬磚搬到老。如果你不是程序員裏的top 5%精英，高質量的代碼與升職加薪，迎娶白富美的相關係數幾乎爲0，除了給你帶來一種虛幻的優越感與滿足感。
難道我們這麼多年接受的教育是錯誤的？不好好寫代碼，怎麼升職加薪？教育是沒錯的，高質量的代碼是我們追求的目標，也是我們必備的技能。但是，作爲普通碼農，我們日常工作的目標是面向人民幣編程，而不是教科書式的面向對象編程。沒有人民幣，你都new不出一個對象。
會寫高質量代碼和日常工作中如何寫代碼其實是兩回事，作爲有追求的程序員，我們一定要掌握如何編寫高質量代碼的各種技能，因爲我們還需要：
面向面試編程：大廠面試必須有足夠的理論基礎加忽悠能力，不然不足以體現你的過人之處。業內某技術大咖曾放話：只要代碼不上線，PK從來不會輸。面試造火箭，工作擰螺絲是大多數大廠員工的現實生活。
能力展示：文無第一武無第二，功夫用不用是一說，但如果一點不會同事們是肯定不會服你的。如果代碼評審，設計評審說不出點有分量的，除非有其它過人之處，兄弟們是不會高看你一眼的。
裝B：比如著名的博客技術專家耗子老師和阮老師，工程能力怎麼樣不評價，起碼理論水平擺在那裏，相關博客本熊也是時不時上去學習一二，開內容收費韭菜割起來嗖嗖的。看不起？不存在的，只恨自己做不到，羨慕嫉妒恨都來不及呢。
爲什麼要在日常工作中寫爛代碼，這要從資本家如何賺錢說起。對於資本家來說，利潤越高越好，成本越低越好。大多數情況下，資本家們更懂如何賺錢，但是對編程基本一無所知。他們關注的是產品能否以最低的成本交付，至於怎麼實現的並不關心。我付了錢就得在規定時間內把活幹了。說兩個真實的笑話，某市值千億上市公司CEO親口所說：
這個功能有什麼複雜的，不就一個頁面，爲什麼一晚上畫不出來？
爲什麼不能把Excel的功能做到我們的系統裏？Excel這麼簡單的東西，微軟已經有了，抄一下不是很快的事嗎？
對於大多數業務驅動公司來說，程序員的牛B與否是無法改變甲方爸爸能給多少錢的，真正決定的是甲方爸爸的現有業務能賺多少錢。這也就是爲什麼我們發現大多數牛B程序員都在互聯網大廠或者底層廠商（操作系統，數據庫等等），因爲對於這些廠商來說業務是由技術驅動的，而且有足夠的利潤率支持用來招聘牛B的程序員和支持他們試錯。甲方只爲產品和服務付費，不爲中間過程和看不到的地方付費。架構設計再好，編碼質量再高，設計模式運用爐火純青，Nobody cares...反正項目就這麼點預算。
對於團隊來說，個人的牛B無法改變整體產出的。大廠的牛B程序員們大多數是因爲站在了正確的行業風口，而他們又比其他人更爲出色一點，當然也有少數人是憑一己之力開創一個時代。對於一個作坊裏一個超過5人的程序員團隊，即使有一個人編碼效率是別人的3倍，但是他一個人不可能把所有的活做了。而且與我們想象的程序員每天工作埋頭編碼不同，大多數時間是在與產品撕B，排查線上故障，編寫文檔，偶爾還要跨部門扯個蛋，每天真正有效編碼時間不超過30%。所以3倍生產力在老闆看來也就撐死多個30%的產出，而且項目也不是天天排滿，加個15%的工資已經是天地良心。
所以，對於程序員來說去大廠並不是你乾的活更有難度，而是享受了大廠高利潤率的紅利。說白了就是糧倉裏的老鼠與糞坑裏的老鼠的區別。那麼，對於大多數混跡與軟件作坊的普通程序員來說，該如何最大化我們的利益呢？簡單說就是寫爛代碼！！！如果對自己技術自信就趕緊跳槽去大廠，或者擠出業餘時間努力自學，如果都做不到，那麼就乖乖的按我下面說的去做。
老闆關注的是產出的結果，只要功能都做完，bug別太離譜，那麼你就是安全的，對得起老闆的這份工資。真有外包公司按代碼量考覈工作量，對於不懂得老闆，這是最簡單得考覈指標。什麼重複功能封裝抽象，業務解耦合，參數配置化，統統扔一邊去，把功能實現了就行。反正這代碼我天天打交道，要改哪些地方我都知道，大不了多報幾個bug多修幾次。什麼，你說工作量大效率低容易出錯？不！老闆不會這麼想，工作量大你加班解決就是，沒準我還能向甲方多報幾個工時；容易出錯？那是因爲項目複雜啊，加錢。對於老闆總不見得跟甲方說因爲這個項目我用了牛B程序員，1周能把原來1個月的活幹完，你得加錢？
爛代碼是職位安全的有效保障。功能交付了，運行穩定無故障，甲方後續需求因爲架構設計合理，隨便上個實習生就滿足了，對於老闆來說這些都是理所當然的工作，後面隨便找個便宜的人替代維護，提高利潤纔是重要的事情啊，類似的項目找人抄抄就行。這種事情聽着魔幻，但在各種作坊裏卻是真實發生的事實。如果代碼寫得爛，就需要不斷有人維護，要加新功能，就不能隨便找個人接手，不然等工期結束原來的代碼都還沒整明白。而且只要這個系統還在線上運行不能下來，老闆基本上得捏着鼻子付你工資，因爲找人接手不是那麼容易的事情。不如你的大概率不知道哪裏有坑捅了大婁子沒法收拾；比你強的去哪不好非得來收拾這個爛攤子。老闆即使各種不滿意，也磨合這麼久了至少對下限有個底，不能忍還咋的？
寫爛代碼也要對自己負責，爛的地方自己要心中有數，線上出現不可控的bug是不允許的。曾看過一段代碼，下面列的問題差不多基本都齊了，開發做需求每天工作量滿滿，我去和他聊重構，啪，這哥們掏出一本筆記...不怕，坑都有記錄，保證不出大問題。重構出了故障算誰的？重構能增加業務營收嗎？重構好了系統不需要我維護了怎麼辦？靈魂三問！得了，咱繼續這麼愉快的玩耍吧。員工每天很有安全感充實的工作，老闆覺得大家每天很忙，而且系統老出bug是因爲難度大，所以不穩定，大家每天加班都很努力了，態度端正是最重要的嗎。
下面簡單說下我見過的某公司內部核心管理系統的一些見聞，因爲系統爛，所以...
大量業務信息硬編碼，修改掛一漏萬，上線了用戶就是最好的測試。
前端混合業務邏輯，上千行的函數到處都是，反正東西都在腦子裏，不怕死的自己琢磨去。
封裝看心情，類似的功能寫了十幾個地方，能一次找到改完算你贏。
業務緊密耦合牽一髮而動全身，動不動某個功能就要全部重寫。一個星期後想用？咱哥們這麼多年的交情就等一個月吧。
數據庫查詢大量字符串拼接，想注入攻擊分分鐘。
大量業務邏輯存儲過程寫死，查詢效率感人...
雖然公司一直想動這個系統，但是不管業務方還是技術部門，都沒有不怕死的跳出來，所以整個系統還在繼續忍辱負重...相關人員還得繼續養着，多好啊。