喜歡go和php的原因都是因為簡單明瞭，就算是複雜的系統，我們也應該化繁為簡，用最簡單的方式實現複雜的系統，同時保持嚴謹，邏輯閉環。
對開發的吐槽
- 不是說設計模式不好，我覺得設計模式特別好，設計模式本身也是為了各種業務模型抽象出來的，用好設計模式，可以讓我們用更簡單的方式完成複雜的業務，寫更少的程式碼完成更多的功能。
但是就很容易走偏，初學者有一本好書或一個好老師帶還好，一點即通，但很多時候是有一部分經驗但經驗又欠缺的人，很容易亂套設計模式，這導致程式碼越來越四不像。 - 也不是說封裝不好，封裝是鍛鍊抽象能力的第一步，封裝是每一個開發的基礎能力。
可是，封裝應該是為了抽象而封裝，而不是為了封裝而封裝。
而且，好的程式碼是給人看的，你寫那麼複雜，封裝那麼多層，你不累嗎，炫技嗎，有什麼意義呢？ - 團隊規範很重要，是每個團隊在專案初始階段就必須確定好的事，討論確定下來後就要少數服從多數。
但是規範統一更重要！請大家根據當前專案既有規範的基礎上制定規範。
我在做現在專案有個很迷惑的事，專案之前的組長推崇單行為控制器（就是一個控制器只負責一個介面，只有一個public index方法，其他都是私有方法，為index方法服務，這種程式碼結構會有AddController、ListController、DetailController、UpdateController、DeleteController），現在的組長推崇Services層必須有，controller中不允許呼叫model。其實這兩種結構都挺好，但是有些矛盾啊，單行為控制器其實是為了解決Services層肥大的問題，現在的專案結構又是多個單行為控制器去調Services，有什麼意義呢？我其實還是有些懊惱的
（如果是我自己的話，我喜歡單行為控制器，因為Services層中大量的方法是沒有被複用的。我覺得Services層很必要，複用的情況再用Services） - try catch很好、很嚴謹、很必須，但是我有時候就很困擾 我不知道為什麼很多人的程式碼裡充斥著try catch，每層都定義一個新的err code，排錯很想哭好嗎，尤其是微服務的情況下，一層層呼叫，排查錯誤的時候，怎麼定位錯誤呢，有錯誤鏈嗎…..
我總覺得try catch 應該用在呼叫外部介面無法預知外部情況、避免次要業務影響主要業務的情況下，如果用laravel的話，可以在Exceptions/Handler.php中處理下常見的異常（球球了別再包了），生產環境的env中的APP_DEBUG肯定是false吧？資料庫redis之類的連線異常，使用者名稱密碼沒問題的話是不是應該找運維了…. sql之類的錯誤，fix bug啊 - 迴圈裡避免操作庫/調介面操作。這條是自己的筆記。其實一直有注意這點，但是有時侯還是思維定勢。上個月寫一個功能，3張表ABC，兩層1對多關係，思維定勢想著C表要用B表的id，得再迴圈裡先create B表資料，再insert C表資料。然後組裡的小哥說可以優化，id是分散式id，可以提前生成，迴圈裡只組裝資料，迴圈外分別 insert B表 和C表。 學習了學習了，感謝小哥。
如果沒有用分散式id的話，可以定義一個唯一code去關聯B表和C表，也可以迴圈裡組裝資料，迴圈外寫表。
對微服務的吐槽
微服務很好，並且它也是現下的趨勢，要搞分散式高併發，最後怎麼都會發展到微服務。
此處推薦一篇文 一文詳解微服務
小明小皮小紅這篇看完會有豁然開朗的感覺，謝謝作者和分享者，比心～
- 多個產品的情況下，請產品先對對產品，至少產品層面邏輯走通
- 請在團隊都準備好了的情況下，再拆分成微服務（領導、產品、開發、時間、硬體、日誌、監控、思維轉換），否則很容易大家一頭霧水，“啥也不敢說，啥也不敢問，大佬怎麼說，我們們怎麼幹”，但是幹了啥開發大都還是一臉懵逼….
- 合理架構設計和模組劃分，我們組長說，要鍛鍊大家的抽象能力，架構設計和模組劃分。可是這並不是一朝一夕就能get的能力啊
- 人員分工和顆粒度分多細呢？肥腸極其容易扯皮。微服務的模組劃分稍微設計不好，耦合度就太高，然後新一輪扯皮…..
- 需要有大佬過產品，產品天馬行空設計一堆功能，如果沒有靠譜的大佬把關的話，開發懵逼著寫，後面太容易出問題了……
- 找到主體，分清主次，這條是自己的筆記，希望自己做到。就不容易做錯主流程。
本作品採用《CC 協議》，轉載必須註明作者和本文連結