只要代碼足夠亂，老闆就不可能開了我

本文標題黨，酸奶爸爸是反對這種觀點的，特此聲明。

一開始擁護啥（由於什麼）讓你把代碼寫的這麼複雜？

新產品須要快速上線

產品經理：競對出了新產品，咱們也要立刻跟進，新立的項目，我無論大家技術怎麼實現，總之老闆就是要儘快上線。

程序猿：儘快是多快呢，這都快下班了。

產品經理：今晚加班，明早上線。

因而乎，命名規則裏夾雜着拼音。前臺後臺一套代碼。別說服務化了，MVC根本都沒有，界面業務數據庫邏輯都混合在一個函數裏了。更別提什麼服務化，將來業務擴展了。

矛盾爆發

項目上線後，若是業績不理想。那麼最終關停新項目，回收服務器，代碼被丟在git倉庫的角落無人問津。若是業績炸裂了，那麼程序猿們的悲慘命運就要開始了，大機率這個階段業務需求會源源不斷的提來，根本沒有時間來重構代碼，因而只能在現有的小平房上加蓋摩天大樓。

破解之法

功能需求，新立的項目不要作的大而全，只作最核心的功能。如若否則，競爭對手死沒死不知道，本身先把本身搞死了。程序架構不要太先進，微服務等架構是用戶日活百萬千萬階段須要作的架構。立項初期只要可以應對日活過萬的需求變動就能夠了。好的規範要從項目的第一行代碼就要實施，命名規範、核心業務的文檔、單元測試等等。

職場小萌新，看不到長遠的將來

微信公衆號比較火，咱們公司也要以公衆號的形態呈現，新事物年輕人接收比較快，因而這個需求就交給了組內的職場萌新來作。過一段時間小程序也火了，再過一段時間又要上馬企業微信。大機率這些後續的騰訊系需求都會由這位職場萌新來作。

矛盾爆發

因爲職場萌新經驗不足，開發公衆號需求只關注當下業務與公衆號的接口，不會考慮將來的小程序和企業微信的擴展。因此代碼裏充斥了各類switch-case，數據庫表裏充斥了各類type。加班與延期是不可避免，工做平常也大機率被各類bug纏身而無暇新功能開發。若是這位職場萌新扛不住離職了，那就是悲劇的開始。

破解之法

技術經理與組內老鳥有不可推卸的責任，若是可以及時codereview，至少能保證職場萌新所搭建的樓不會歪。公司要上一個市面上流行的技術或業務，將來確定要大規模上新需求，這裏就須要老鳥們的技術經驗與業務遠見。畢竟若是職場萌新的樓歪了，恰巧又離職跑路了，那麼這座歪了的樓大機率會由組內老鳥接手，由於市場已經爆發，大老闆已經感覺到職場萌新開發週期delay的痛了。

程序猿老油條，個人代碼無人能夠接手

公司業務平穩，平常新增需求也很常規，但就是有這種老油條型程序員將代碼寫的無比複雜，不一樣業務之間耦合度很高。

矛盾爆發

別人計劃開發一週的須要，由於涉及老油條的代碼，看代碼就要看3天。這種亂麻型的代碼，不知道哪些需求線上在用，哪些需求線上已經下線，搞得測試同窗都得跑一遍，都很痛苦。上線以後每每是按下葫蘆浮起瓢，好不容易開發2週上線，後續2~3天各類線上bug報出來，各類補丁文件上線，搞得OP同窗也很痛苦。

可是在老闆眼裏倒是另一番景象，老油條天天加班，天天幫助同事解決bug，天天上線補丁解決線上問題，辦公室一派欣欣向榮的景象。因而老闆瘋狂招人。

直到某天，代碼實在改不下去了，線上每天出bug，公司業務高度依賴線上操做，老油條跑路。公司，卒。

破解之法

這種老油條是公司的毒瘤，它不一樣於新項目的趕工期，也不一樣於職場萌新的經驗不足，而是主觀要將代碼寫爛。這樣作短時間會保住本身的飯碗，長期看是逆勢而爲。老油條把青春與經歷都花在了辦公室厚黑上，而沒有精進技術，違背客觀規律的行爲終將被時代淘汰。

解決之法：開掉。

寫在最後

好的代碼是爲了提升將來的效率，這裏的效率不僅是編碼的效率，還有溝通的效率。接收人不問原做者就能快速讀懂業務邏輯，新需求開發可以儘可能少的修改現有業務邏輯。開發規範，設計模式等這些前人大牛留下的精華不是在無病呻吟的。用一樣的人力支撐更大的業務規模纔是王道，該重構就重構，痛一陣是必要的。

我一直深信：加班能解決的問題，必定有其餘方式解決。