只要程式碼足夠亂，老闆就不可能開了我
本文標題黨，酸奶爸爸是反對這種觀點的，特此聲明。
一開始擁護啥（因為什麼）讓你把程式碼寫的這麼複雜？
新產品需要快速上線
產品經理：競對出了新產品，我們也要馬上跟進，新立的項目，我不管你們技術怎麼實現，總之老闆就是要儘快上線。
程式猿：儘快是多快呢，這都快下班了。
產品經理：今晚加班，明早上線。
於是乎，命名規則里夾雜著拼音。前台後台一套程式碼。別說服務化了，MVC根本都沒有，介面業務資料庫邏輯都混合在一個函數里了。更別提什麼服務化，未來業務擴展了。
矛盾爆發
項目上線後，如果業績不理想。那麼最終關停新項目，回收伺服器，程式碼被丟在git倉庫的角落無人問津。如果業績炸裂了，那麼程式猿們的悲慘命運就要開始了，大概率這個階段業務需求會源源不斷的提來，根本沒有時間來重構程式碼，於是只能在現有的小平房上加蓋摩天大樓。
破解之法
功能需求，新立的項目不要做的大而全，只做最核心的功能。如若不然，競爭對手死沒死不知道，自己先把自己搞死了。程式架構不要太先進，微服務等架構是用戶日活百萬千萬階段需要做的架構。立項初期只要能夠應對日活過萬的需求變更就可以了。好的規範要從項目的第一行程式碼就要實施，命名規範、核心業務的文檔、單元測試等等。
職場小萌新，看不到長遠的未來
微信公眾號比較火，我們公司也要以公眾號的形態呈現，新事物年輕人接收比較快，於是這個需求就交給了組內的職場萌新來做。過一段時間小程式也火了，再過一段時間又要上馬企業微信。大概率這些後續的騰訊系需求都會由這位職場萌新來做。
矛盾爆發
由於職場萌新經驗不足，開發公眾號需求只關注當下業務與公眾號的介面，不會考慮未來的小程式和企業微信的擴展。所以程式碼里充斥了各種switch-case，資料庫表裡充斥了各種type。加班與延期是不可避免，工作日常也大概率被各種bug纏身而無暇新功能開發。如果這位職場萌新扛不住離職了，那就是悲劇的開始。
破解之法
技術經理與組內老鳥有不可推卸的責任，如果能夠及時codereview，至少能保證職場萌新所搭建的樓不會歪。公司要上一個市面上流行的技術或業務，未來肯定要大規模上新需求，這裡就需要老鳥們的技術經驗與業務遠見。畢竟如果職場萌新的樓歪了，恰巧又離職跑路了，那麼這座歪了的樓大概率會由組內老鳥接手，因為市場已經爆發，大老闆已經感受到職場萌新開發周期delay的痛了。
程式猿老油條，我的程式碼無人可以接手
公司業務平穩，日常新增需求也很常規，但就是有這種老油條型程式設計師將程式碼寫的無比複雜，不同業務之間耦合度很高。
矛盾爆發
別人計劃開發一周的需要，因為涉及老油條的程式碼，看程式碼就要看3天。這種亂麻型的程式碼，不知道哪些需求線上在用，哪些需求線上已經下線，搞得測試同學都得跑一遍，都很痛苦。上線之後往往是按下葫蘆浮起瓢，好不容易開發2周上線，後續2~3天各種線上bug報出來，各種修補程式文件上線，搞得OP同學也很痛苦。
但是在老闆眼裡卻是另外一番景象，老油條每天加班，每天幫助同事解決bug，每天上線修補程式解決線上問題，辦公室一派欣欣向榮的景象。於是老闆瘋狂招人。
直到某天，程式碼實在改不下去了，線上天天出bug，公司業務高度依賴線上操作，老油條跑路。公司，卒。
破解之法
這種老油條是公司的毒瘤，它不同於新項目的趕工期，也不同於職場萌新的經驗不足，而是主觀要將程式碼寫爛。這樣做短期會保住自己的飯碗，長期看是逆勢而為。老油條把青春與經歷都花在了辦公室厚黑上，而沒有精進技術，違背客觀規律的行為終將被時代淘汰。
解決之法：開掉。
寫在最後
好的程式碼是為了提高未來的效率，這裡的效率不只是編碼的效率，還有溝通的效率。接收人不問原作者就能快速讀懂業務邏輯，新需求開發能夠盡量少的修改現有業務邏輯。開發規範，設計模式等這些前人大牛留下的精華不是在無病呻吟的。用同樣的人力支撐更大的業務規模才是王道，該重構就重構，痛一陣是必要的。
我一直深信：加班能解決的問題，一定有其他方式解決。
