一件悲傷的事實，這兩周，成長值為零～～
從大數據部門臨時抽調到互聯網部門，支援重構的“配置下單”項目。
一個變種的低代碼架構設計，唯一比較有意思的是它的業務組件的設計與校驗設計，算是學習到點東西吧，其余的時間都是趕工中度過～～
一、價值
（一）架構
有幸與公司的前端技術高經聊天，向大佬請教架構師之路，大佬給的建議。
- 技術是為業務服務的。API 學習是基礎，但不是重要的，重要的是要懂這個新技術解決了哪個業務場景。
- 深耕業務。深度熟悉某一類業務是架構師的必走之路，比如活動秒殺設計、低代碼設計
- 前瞻性。擁抱變化，做設計時需要考慮后期的擴展，更友好的支持。比如：服務人數從 1K 擴展到 1W、新加功能特性
這些是建設性的建議，真正落地還是有一段路要走：
了解技術背景
一個新技術的出現，必定伴隨著特定的業務場景，在這個獨特的業務場景，持續完善這個技術，最終才會有面向世人的技術.
反思：通常看到一個技術時，會首先一股腦的去學習 API，反而忽略了最本質的東西。
透過技術學習架構
一個好的技術，必定伴隨著一套穩固的架構設計。空談架構有點虛，可以從一門技術的設計，慢慢去學習它內在的架構。學習它、模仿它、使用它。
很好的例子，Vue 中存在雙向綁定，React 中為何一直沒有雙向綁定呢？
打破限制
每一個小的業務做到極致都是一項很龐大的版圖，像數據、日志、隊列、資產等。架構的本質是為業務服務，打破技術人的邊界思維，敢想敢做，是否可以更進一步、再進一步呢？
（二）互聯網
不曾真正在互聯網網絡做過事兒，這兩周支援互聯網部門，明顯體會到不同的氣氛。
怎么說呢，互聯網部門與內部系統部門，最直觀的感受，就是互聯網部門更有朝氣，使用最新的技術、說著最潮的行話、下最晚的班。
互聯網部門是善變的。作為直接對接用戶的部門，一個需求、一周變化個兩三次都是有可能的。不要擔心，會有一堆小伙伴陪著你加班，UI、UE、產品、開發…
互聯網部門是自由的。完全基于敏捷思想，快速迭代，以最終產品說話。
（三）外包
不得不說的一件事兒，要遠永避開外包、避開外包、避開外包…
需要支援的項目，工期緊張、任務繁重。所以，一件很悲傷的事兒，就是沒人關心支援的人是否了解項目，也不需要支援的人了解架構、業務，按照人家已設計好的架構填空就行。
外包的滋味十足，基本上天天在趕工，整個人都在透支中…
二、反思
連續兩周未有效讀書了，一直給自己找借口。覺得加班忙，所以可以諒解。啊哈哈哈哈哈
時間總會有的，懶而已
三、往期回顧
- 雙周回顧#004 - 滿眼歡喜
- 雙周回顧#003 - 新生
- 雙周回顧#002 - 紅樹林
- 雙周回顧#001 - 火燒云
)
)
