代碼，寫的複雜點還是簡單點？
先說下個人」暴論「，肯定是簡單好。
為什麼這麼說，我們先從事物的本質來看。任何學術研究，科普文章，都是試圖將一件複雜或困難的事情簡單化。複雜的知識點通俗易懂得講給學生聽，你就是一位好老師了。同樣複雜的系統功能，用淺顯易懂的代碼實現，你就是一位好的程序員。
這會兒肯定有同學會問了，「我司有個老員工，整個項目只有他一個人能看懂，能修改，別人根本沒辦法下手」。 這種已經發生的，不在咱們的討論範圍內。不過我們可以討論一下，為什麼項目會變得這麼複雜。大概有以下幾種原因
1、可能項目人員參差不齊，可能從需求側就是有問題的。畢竟很多產品經理，在設計功能的時候，並不會考慮功能以後的擴展性。甚至，是直接借鑒友商的升級，稍加改改。
2、程序員的能力有限，或者說，在寫代碼的時候，並不會考慮擴展性，功能上線了，能跑就行，後續有問題，直接在代碼上打補丁。函數的入參由一兩個，變成多個，執行邏輯，變成if，else 各種堆疊。
代碼之所以寫成這樣，是因為從代碼層面來說，沒有一個即時的負反饋，剛開始沒人會意識到，這是一個問題，但是隨着產品功能的迭代，慢慢才會被人發現，可能是已經無法維護了，或出現bug無法修復了，拆東牆補西牆。這個時候，可能最初開發功能的程序員都已經跑路了。他們沒有意識到「防微杜漸」才是解決這類問題的根本手段。所以為了防範這類問題，市面上有很多軟件工程，設計模式，代碼規範之類的基礎思想（這塊咱們後面也可以展開聊一下）。
3、在有限的工期下，為了快速迭代，只能保交付，犧牲一部分質量。但如果一直犧牲質量，慢慢技術債會越積越多，代碼腐壞，最終形成不可維護的項目。
但是，」代碼的生命力「是一個不可控的偽命題。很多年頭很長的項目，最終的歸宿是徹底重製，而不是迭代更新。可能從公司層面來說，高層決定換一個產品或者系統。
複雜度不會消失只會轉移
說回程序員本身。個人認為優秀的實用型程序員的職業素養之一，就是不斷在有限的開發時間和優雅的代碼實現之間找到一個平衡點。你可以用各種設計模式，基礎思想，但你得找好平衡點。三天後有個功能需緊急交付，你給我整DDD，六邊形架構，那人家可能覺得你不靠譜。
