引言:
春暖花開，草長鶯飛，然而和煦的陽光並沒有給互聯網的嚴冬帶來多少溫暖，互聯網大廠的裁員消息層出不窮……作為技術人員，如何過冬?就是要使自己更優秀!通過提升自身的經驗與能力，加強自己在團隊的影響力，擴充發展空間!本文主要是作者回顧蘇寧採購平臺搭建到現在，從系統的框架演進，項目迭代開發中遇到的問題進行的總結與思考，以及一些共性的問題跟大家聊聊，拋磚引玉同時也避免大家在踩坑的路上“前仆後繼”。
要成為一名優秀的開發，首先要成為一名合格的開發!作為一名合格的開發，需要有相關意識!
代碼更多是給人看的!
代碼雖然最終是編譯成二進制的文件給jvm執行的，代碼寫的是否優雅機器不會挑剔的，但是一個合格的開發者應該意識到:代碼更多是給人看的!
(一) 命名合理:
簡潔易懂，合理的命名會給你的代碼極佳的印象分。也有效幫助review代碼的人快速瞭解代碼的邏輯。有不少開發者有這樣的想法，與其費盡心思想個類名方法名不如多寫幾行代碼。其實大錯特錯的，這是別人瞭解你代碼的窗口，猶如人的眼睛，無論你長得多麼英俊，漂亮，缺少一雙明亮有神的眼睛也會讓人對你的印象大打折扣。
(二) 格式清晰:
這裡的格式包括類文件，配置文件，各種腳本，靜態文件以及方法都需要分門別類的放置，循環/判斷不亂用，提升整體可讀性和可用性。這裡有幾點經常被忽視。
1. 永遠不要用一個常量類來放置所有的常量，一個公共類存放所有公共方法。這就猶如你把自己所有衣服放到一個箱子。想象一下，在週一早晨你起晚了，還要在雜亂無章的箱子裡翻找一雙襪子的情形，是多麼的令人抓狂!相信如果條件允許，你更願意買雙新的，周而復始，最後你會發現有了一堆很像的襪子，更不知道哪兩隻是一雙……
2. 深度過大的循環和判斷，會使代碼可讀性成指數級降低!人的記憶暫存時間是有限的，超過三層的循環或判斷，特別是一些較複雜的條件，一般人很難記住整體邏輯。導致的後果是，review代碼的時候循環往復的看一段代碼，不僅耽誤時間，而且極度影響review者的心情，一些隱藏的bug可能就陰差陽錯的漏過了!
(三)註釋規範:
註釋的主要作用是準確反應設計思想和代碼邏輯的， 同時需要和代碼邏輯變更保持同步更新。註釋不規範甚至和代碼實際邏輯相悖，往往給交接功能和後續處理問題的同事挖下一個深坑。
好的註釋永遠只有一個標準:能讓別人快速準確的瞭解這塊代碼的邏輯!現在大部分公司都採用敏捷開發，要求快速迭代和迅速響應問題處理。作為開發，代碼就是第一手的資料。當分配給你一個功能優化點，只給你一天時間，你找到這個類的時候發現近千行代碼，結構命名混亂，全篇無一個註釋的時候，相信你的心情是有多麼的崩潰!所以合理註釋從自身做起。藉助《流浪地球》的一句名言，請記住”代碼千萬行，註釋第一行，註釋不規範，同事兩行淚!”
(四)日誌合理:
日誌是排查生產問題的重要途徑，有排查過生產問題經歷的人應該都有同感，那麼什麼樣的日誌是好的日誌?答案只有一個，能幫助快速定位生產問題的日誌就是好的標準。日常review代碼過程中，日誌是最容易被開發忽視的，當有生產問題需要排查時，你會覺得合理記錄日誌的同學是最可愛的人!
1. 日誌有明確的等級劃分，亂用日誌級別只會帶來反作用。濫用error級別的日誌，相關的報警次數多了，就如同狼來了喊多了一樣。
2. 幾個關鍵記錄日誌的地方:方法，接口調用前的入參，返回的結果。核心判斷邏輯入口，對處理邏輯有影響的中間變量，異常處理場景
細節是開發質量最有力的表現形式!
一個有經驗的開發不是代碼寫的多麼天花亂墜，更多的是細節考慮是否周全。 禍患常積於忽微，隱患往往都埋在細節裡面，這裡的隱患是個很寬泛的概念，包含了安全/性能/邏輯上的一些隱藏問題，即使忽視了，通常情況下不會對業務有什麼大的影響，但是在極端情況下，忽視的某些小問題可能就是致命的根源!下面從日常開發涉及的代碼編寫，線程管理，緩存使用中，列出容易忽略的細節供借鑑。
1. 創建新方法能私有就私有， oop開發中首先要保護好自己，其次是提供更優質的服務。使用你提供公用功能的開發者，不是你想象的那麼單純，即使你修改自己的public方法也可能影響了一個你做夢也想不到的一個功能!
2. 不要忽視基本數據類型的默認值的影響。當你把考試成績定義成int，你如何應對產品提出的統計下沒考試的和考0分的需求?0和沒值永遠是兩種業務含義
3. 警惕巨型的類和方法，以及方法的無腦拷貝，這些順序思維編程的產物除了給團隊挖坑，另外一個作用是暴露你新手的特質，即使你有了幾年的開發經驗。
4. POJO對象不要混用， 數據對象後綴DO，數據傳輸對象後綴DTO，展示對象後綴VO，業務對象後綴BO。可能有同事基於好心，優化某個功能時糾正你一個命名不規範的地方，即使他很小心的通過IDE查了所有影響範圍，可是不知道你VO和BO混用了，結果可想而知。
5. 永遠不要用float和double這種浮點數參與計算和直接比較，偶發的精度問題的排查足以令你抓狂，因此而產生的問題數據的處理更是會讓你追悔莫及!
6. 不要忽視數據庫更新和插入操作的返回值，即使你通過各種手段和預查詢確認數據庫操作一定會成功，現實是很骨幹的，未知的情況往往會給你一個非你期望的結果的。導致整個後續邏輯的執行偏離你預期。這個後果可能需要你的團隊花費幾天甚至更長時間去處理問題數據
7. 線程是把雙刃劍，能不用線程的不要用線程，能用線程池的決不單起線程，能用容器管理的線程池，不要自建線程池。亂用線程，線程池生產環境的OOM足以令你抓狂。
8. 雞蛋不要放到一個籃子裡，即使使用容器託管線程池，但也不要把所有業務的線程都用一個線程池。除非你想體會一下核心功能服務積壓了一堆需要立馬處理的數據，但是線程池線程被一些非緊急的下載任務瘋狂佔用的無能為力感。
9. 線程池配置的拒絕策略需要慎重，數據無緣無故的毫無痕跡的丟失問題，一般人的小心臟經不起幾次折騰。
10. Redis是很便捷，大的value值存入redis，帶給你的便捷建立在傷害其他功能的基礎上的，記住redis是單線程的!大value值的存取使redis的多路併發基本成為擺設。
11. Redis的雪崩和穿透能瞬間壓垮數據庫，這都是大併發和惡意操作賦予的威力。
12. 要求數據強一致性的業務不要使用緩存，即使你用種種手段去保證數據同步，但是總有你想不到的情況。
數據庫，系統的絕對瓶頸!
毫不誇張的說系統性能問題或多或少的都能看到數據庫的影子。一個糟糕的表設計不僅制約相關功能實現，也為日後的擴展設下層層障礙。下面主要從建表，索引，sql語句3個方面總結以往開發過程中數據庫相關的常見問題(項目主要使用mysql，一些特性問題單指mysql)。
(一)建表規範:
1. 建表同樣離不開命名。表名，字段名除了固定格式要求，更多的和上面提到的變量命名規則是一致的，好的表名能讓人通過表名就知道該表屬於哪塊業務的，存放什麼業務數據的， 好的字段名能準確表達字段的業務含義
2. 不同表同業務含義的字段類型一致也至關重要，實際項目開發過程中這塊也是最容易被忽視的地方!類型不一致表關聯時，隱式的類型轉換會使表關聯查詢索引失效!
3. 字段的類型定義需要嚴謹，業務上定長的字段定義varchar，這是你不瞭解char和varchar對索引效率的影響!
4. 字段長度定義隨心所欲更是常見，特別是varchar的濫用，當你擴幾次過億數據的表的字段長度，那個執行過程會保證令你記憶深刻!
5. 規範的字段命名是需要的，詳盡的字段備註描述也是一個負責任的開發應該做的，當你糾結01，02，03…。。不知道其代表的業務含義的時候，你會打心底感謝那個備註了字段含義的同學。
6. 強烈推薦每個表建一個自增的id並且設置成主鍵，至於原因呢B+樹和聚簇索引瞭解下……
7. 在表中冗餘一些字段儘可能減少表的關聯個數，是提升查詢性能的很好的手段，即使違反第二範式，空間換時間還是很值得的。
(二)索引合理:
1. 建新表的時候，一起加上合理的索引是個好習慣。等數據量上來了，功能響應變慢了，再被動的去加索引，那會已經影響了用戶的體驗。
2. 索引不是越多越好，也講求個”中庸之道”，但必要的索引還是要加的，因為索引引起的插入更新而導致的性能影響其實對大多數的業務系統來說是很小的，如果實在擔心做個插入壓測就知道了。
3. 加個業務字段的唯一索引其實是很有必要的，不是去依賴數據庫做唯一性校驗，而忽略代碼裡面業務邏輯的校驗，記住總有你想不到的異常場景會導致數據重複存庫，這是最後一道防線。
4. mysql的數據表其實稱之為一個”大索引”更貼切，數據都是掛在主鍵索引上的，其他索引依賴主鍵索引取數據，索引數據就能滿足需要而帶來的微小性能提升有時候能給你帶來一些驚喜。
5. 建了單鍵索引的字段又出現在同表的組合索引的頭部也比較常見，養成良好習慣清除重複索引，一定程度上提升數據庫優化器的性能，也節省了寶貴的數據庫空間，何樂而不為呢。
(三)語句健壯:
1. 寫出複雜的sql，不是你牛的表現，恰恰相反，反應出你很low。sql牽扯過多邏輯不利於後面運維，也給數據庫的運行帶來巨大壓力，說雪上加霜也不為過。
2. 過多的表關聯查詢sql，在數據量少的時候是沒問題。後面業務推廣，數據量上來了怎麼辦?請記住欠賬總是要還的。
3. 平時寫sql的時候都要想有幾種影響索引生效的情況也不太現實，只要記住一點索引都是左匹配的原則，基本上能避開大部分的索引的坑。
4. 即使使用分頁查詢也需要注意大數據結果集的影響，數據庫返回分頁的數據不是跳到特定行的取值，而是取出所有行後慮出分頁返回的那些數據，深度查詢對數據庫的影響足以令你懷疑人生。
5. 防止數據覆蓋，除了共享鎖以外，表中多加一個版本號，通過版本號去控制也是一個不錯的方法。
6. 安全意識要提高，當前的持久層框架有效避免了sql注入的風險，安全的意識還是不可或缺，這裡的安全偏向數據安全。記住不懷好意的人時刻垂涎你認為的”不重要”的數據。除了數據洩露風險，日常更新刪除數據也需要有安全意識，你能想象更新或刪除語句的where條件失控帶來的後果吧。
當你有了上面的意識，並在實際開發中高標準嚴要求自己，你已經是一名合格的開發了，如何進一步做到優秀，其實只差了思維上的昇華。
開發要有產品的思維!
什麼是產品思維，簡單點就是站在用戶的角度，想用戶之所想。產品思維應該貫穿在整個產品的生命週期中，從項目開啟前的用戶調研、每次項目更新的用戶需求評估到產品設計，開發以及測試過程中等等，一個好的產品應該做到蘋果喬老爺子宣稱的比用戶更瞭解用戶的需求。開發作為產品功能的絕對意義上的第一個使用者，同樣要有產品思維。
1. 需求評審，優秀的開發是從用戶體驗出發，協助產品同事完善需求，大家以如何提供一個用戶體驗好的又能保證系統性能穩定的為共同目標。作為開發要用於挑戰技術框架束縛，這也是提高自身能力的契機。
2. 產品實現，產品細節的完善。再優秀的產品設計也無法考慮全部的細節，而開發過程是對產品細節完善的一個絕佳階段。優秀的開發會在開發過程中對一些細節提出自己的見解和完善方案。做一個有思想的開發，會助你打破職業瓶頸。
結尾:
再寒冷的冬天也會過去，只要你足夠優秀，不會懼怕任何寒風!驀然回首你會發現這不過是你成長路上的一道風景。