生命太短暫，不要去做一些根本沒有人想要的東西。本文已被 https://www.yourbatman.cn 收錄，裡面一併有Spring技術棧、MyBatis、JVM、中介軟體等小而美的專欄供以免費學習。關注公眾號【BAT的烏托邦】逐個擊破，深入掌握，拒絕淺嘗輒止。
前言
各位好，我是A哥(YourBatman)。以下文章來源於softech華山論劍 ，作者徐凌雲。
技術選型是個很大的話題。「靈活」與「高開發效率」是技術選型最看重的兩點。感謝徐總的分享，很受用。
正文
關於技術選型，我們不少技術從業的朋友容易進一些誤區，而這些誤區大多俗話是某種技術開發思維定勢在作怪。選型怕遇到噴子，也怕詆譭性總結。
技術選型沒選好，每往前走一步，都可能變成捱揍的理由，也是讓人心碎得理由。
技術選型
我相信自驅動的團隊學習，意識提升，分析度量，團隊信任，勇敢能做好選型的更好實踐。當然技術選型中也存在著天時、地利、人和。技術選型的能力是一個各方面綜合作用的能力，而不是僅僅我們認為的技術範疇。
很多技術同學對新技術有天生得衝動，有時候開發人員自己玩的很high，但專案卻玩死了，這是作為技術管理者需要面對的魔鬼。這是件很悲哀的事情，我們需要抑制內心深處的魔鬼，技術只有跟業務有機的結合起來，產出所追求的價值，才是有意義的。
在工作中完成一次技術選型，絕不能簡單的僅僅從純技術角度出發思考。一次看似偶然的選型會給後續工作帶來方向性的影響，這裡的影響指的不光是技術層面，更多的是管理層面。這就如同在公司一次公開的專案招標中，考慮絕不僅僅是解決方案本身的優劣，更重要的考量方案的成本是否符合預期，方案提供方的實力、誠信度，甚至還要從商業模式上去思考未來的合作方式是什麼，等等。而這一切，都能在一次技術選型的過程中，得以體現。下面就從幾個主要闡述下選型中遇到的常見問題。團隊的穩定性重要性要遠大於一些其他的因素的重要性。
技術選型誤區與雷區
做任何決策時，蒐集資料，無論是在簡書，掘金，公眾號還是csdn這些平臺上，亦或是開源專案地址和官網上，請記住：最重要的不是它告訴了你什麼，而是它對你隱瞞了什麼，這些隱瞞的資訊最終會置你於險境。
蒐集資料的時候如果資料的作者對某項技術具有顯著的傾向性時，請深入想想，他向你推薦的每一項優點是否真的“對你”有價值，以及它背後的代價是什麼。比如，推崇“自由”的技術往往不夠“嚴謹”，如果你的產品需要嚴謹，那麼請把“自由”看做減分項而不是加分項。比如，推崇“體積小”的技術在現在動輒幾T硬碟、幾M頻寬的環境下，到底對你來說有多大價值？它是不是因為沒有其它的優點了才把這種細枝末節亮出來吸引你？
如何避免減少技術選型踩坑或者踏雷呢，在這裡我們需要一些原則和意識進行精確的指導。
技術選型原則
我們為了團隊影響力適度使用新技術，也鼓勵在各方面情況需要的時候造點輪子，但是前提是穩定第一，並且還要善於應用新技術和自己造成熟了的輪子。
技術選型的意識
生命週期的意識
《聊聊架構》這本書，貫穿全書的詞恐怕就是生命週期了。系統都有他系統特性所帶的生命週期，從生到死，經歷少年、中年、老年三個階段。複雜度的管理貫穿系統的整個生命週期,就像進化論的自然選擇一樣，不停的優化著系統，不停的斷舍離，保持著系統的生命力。
度量意識
《人月神話》是把軟體工程的過程量化的國內最早的一本書。沒有度量無法說服自己，更別談說服團隊。
突破定勢思維
突破自己的技術思維定勢的意識個體技術認知是有侷限的，如何來打破這種侷限? 學習，分享，交流，提升，這也是技術創新的基礎。
權衡取捨意識
選型也是一種精細化選擇，權衡取捨意識我們技術和工程領域的朋友很多都是完美主義者,追求完美，但是我麼要明白沒有銀彈。
技術選型的取捨也是一種取捨的藝術。不僅僅是限於技術視野的綜合判斷力的體現。
有時候不必糾結於技術本身的挑戰踩坑的認可自己的觀念，而是在遇到技術難題，長時間無法解決的時候，可以選擇繞口，曲線超車。不把過多經歷放在細微之處，而把精力聚焦到核心問題上。
職責劃分意識
做好選型也需要格局，不僅僅是深深認識到業務規模是發展變化的，技術是演進迭代的，還有企業的商業戰略(技術人也要培養商業敏感度)。還有技術選型誰主導，誰參與，誰監督。
運維需要參與嗎，測試需要參與嗎，安全部門需要參與嗎，當然誰需要參與取決於選型的物件的規模和選型的目的。
風險意識
需要識別好風險，在清楚風險的基礎上，考慮推進過程中的影響面以及推進過程需要把握的度。特別強調關於已知的未知 和 未知的未知進行區分，一個人花了四個月時間試圖弄清楚為什麼會出現 GC 停頓，結果發現是因為他往檔案中寫入了統計資訊。顯然，他事先並不知道會發生這樣的事情。軟體中的很多 bug 都是這樣的。我們並不知道系統裡存在這些 bug，它們都是"未知的未知"。
一個專案最好超過30%得新技術，對於完全未知的新技術，很難控制使用過程中出現的風險。如果技術leader不能得到下屬的尊重，很可能受到懲罰。
產品意識
作為使用者是否有能力解決問題，給你一本億級流量，但是需求是隻需要做個管理系統給國企下面一個部門的辦公室幾個行政人員使用，而且可能一個月也就使用幾次。這其實反應了技術人員的產品意識。
很多技術人員喜歡玩酷的東西，願意探索新的領域，把不可能的變成可能，但是很多時候，他們做出來的東西很難使用。
技術發展的史學觀意識
中國近現代是一部師夷長技以制夷的歷史，而當年的中國逐步從這種現狀轉變成自主創新的國家，雖然完全自主創新的科技少之又少，但是這種變化標誌著中國對科技的認知和科技長遠發展樹立了一個里程碑,而這一點在計算機應用領域更是淋漓盡致，造福每一個當代人。我深信多讀歷史才能增長智慧。
只有瞭解技術的發展歷史，才能更好，更精準，更穩的做好技術選型。喜歡深入研究技術的從業人員多半會喜歡讀一些技術發展史，如《數學之美》這本書就是歷史的看從資訊理論到計算機的發展史。這本書是本不錯的計算機從業人員的計算機啟蒙書籍。
技術選型考量因素
成本考量
在開發層面，造輪子和開源是我們技術從業同學繞不開的兩個問題。很多技術領導害怕重造輪子, 大多數技術領導層希望儘量避免造輪子。我們都知道重造輪子會耗費人力和時間成本。前段技術瑣話右導組織過一場造輪子的討論，有幾個同學的觀點挺有意思。一個同學提出，造輪子的幾個正面論調：自我展示和他人超越；自我保護和程式碼安全；自我超越和程式碼專利。
還有個同學說到開源不易，做得不好沒人用，做得太好又投入不起。所謂的造輪子是小事，重要的是解決開源能更好的提供服務，商業更好的服務開源，只有達成良性迴圈才能有更好的開源，有更全面的服務，商業與開源相輔相成。還有個同學聊的很多，大體提到三點，認知問題和商業利益以及自我能力提升，認為自己的需求獨一無二，現有的庫就是在某個點上滿足不了，對現有的輪子理解不知比如老輪子沒有規格說明書，或者介面太複雜，不知道怎麼用，搞明白太難，不相信老輪子。
譬如老輪子可能有後門、漏洞（想想OpenSSL的心臟出血漏洞）、後期萬一要修改沒把握等，反正是覺得自己造輪子心裡更踏實，需要對老輪子上新增新功能，然而老輪子程式碼難讀無人可問，不知道何時能弄明白，看不到結果，容易放棄，眼界有限，不知道已有這樣的輪子，版權原因無法使用第三方庫，比如Google Android實現JVM（Google曾因為一行程式碼而和Oracle打官司），比如阿里YunOS自己實現JVM不想讓自己產品的關鍵技術掌握在別人手裡，也不想讓自己的核心使用者資料流經別人的系統，別人的輪子不開放，我就是要趕緊造（山寨）一個出來以便獲得話語權或商業利益，就想鍛鍊自己，因為造輪子對自己的設計、編碼能力有很大好處，對理解業務也有很大好處。
當你造輪子的時候，你要考慮到總有一天還可能會換輪子，網際網路行業換輪子是一種高風險操作，有時候我們也偶爾要說服自己，自己造輪子反倒是可能挖坑了。因為確實遇到了一些技術小夥伴引數調優沒研究透，遇到問題就認為元件或者框架不好，想自己造輪子的。之所以提到造輪子和開源的問題，是因為做技術選型很多時候我們都會遇到這兩個問題。無論是造輪子還是開源專案，程式碼的可讀性和可維護性也是很重要的考量因素。
開發效率還是執行效率，這個選擇是個老生常談的問題。對於不同階段的公司和專案會有不同的選擇。新的商業專案更趨向於選擇開發效率優先。因為商業模式的儘早驗證比其他因素更重要。老專案優化更多提到執行效率，效能調優等問題。
團隊考量
選大家熟悉的，方便開發，排查問題。
康威定律深刻地影響著很多方面，技術選型也不例外。特別是做巨集觀技術選型時，必須考慮它在最終技術架構中的位置，以及與團隊溝通結構的匹配程度。即使是一項很先進的技術，假如它與體系中的其它技術棧不匹配，也可能導致翻車。
當選擇多個第三方庫的時候更要加倍小心，因為它們開發時互相不知道彼此的存在，特別是對於一些較新的技術，可能都沒人把它們搭配使用過。除了開發架構之外，還要考慮更廣泛的運維架構。
除非你是個前後端 + DevOps 全棧，否則就需要儘早對組織架構方面的因素進行驗證並排除風險。也就是說，在一個可控的演習環境中，用一個小型案例，完整地走一遍開發、上線、發新版的流程。在這個過程中，一些顯著的風險將會暴露出來，要評估其影響，來決定如何選型。
我認為技術管理者身上必須有一個特質:技術佈道。充分激發團隊的技術熱情，感染團隊裡的每個成員，是技術管理者必備的人格魅力。一項技術適不適合團隊，只有用了才知道。但是技術管理者大可不必親力親為，尤其是CTO，總監級別的管理者，只需要指定技術目標，保持一定的技術熱情即可，最後再積極配合進行技術佈道。
不同的企業，不同的部門，不同的團隊管理模式不同，技術文化不同，當然就很可能在技術選型上發生不一樣的故事，像一個技術同學的團隊teamleader+業務架構師+技術架構，進行民主決策，少數服從多數。這個方式體現了組織架構的重要性，技術架構師和業務架構師以及teamleader。有的企業有技術架構委員會，會參與大專案的技術選型的評審，有些時候可能他們對待選型的物件所選擇的技術並不太熟悉的時候，他們最差也能站在自己技術經驗的角度考量一些可能會遇到的問題。提到這個主要強調組織架構對技術選型的影響力，《架構即未來》這本書，對彈性，高效的組織架構做了很詳細的闡述。
方案1/2/3...N,綜合評價，傾向選型優缺點詳細列明，如果某個環節可能會出現問題，風險備案是什麼。並且附上開發計劃排期，關鍵事件的里程碑和時間截點。相信上面也是能看得懂的，這個時候就看要你個人遊說能力了。那這樣好不好，有一句話說的好，人捋順了，事就好辦了。但是也有另一面，因人而廢制度，就變成了人治，誰的嗓音高，誰的許可權大，誰就有話語權，這樣的組織長久不了，團隊會潛移默化的形成個因人而成事，因人而廢法這樣的團隊你呆個兩三年出來之後基本就知會唯唯諾諾，很難養成自己的獨立思考和決策能力。
那究竟事制度重要還是人重要呢，這是另一個層面的討論。這個話題的思考從《大江大河》裡面老水的因人成事，因人廢事那句話開始。因為我認為錯的人好的制度，未必能辦成好事，但是犯錯誤的可能性會低一些。對的人好的制度是比較完美的狀態。
先客觀的從團隊各維度梳理團隊現狀，然後據此選型，要知道選型錯誤只能團隊來承受。阿波羅神廟上鐫刻著一句警世名言-瞭解你自己。千萬不要懶於梳理，懶於總結盲從潮流。惰性確實是技術發展的驅動力之一, 而過於懶惰卻不是。
團隊技術選型自然會選擇團隊所有成員熟悉的技術，否則會出現開發節奏問題。比如所有人熟悉 Java，小部分人熟悉 Scala 的情況下，需要忍痛割愛選擇即使從其他層面考慮更適合的 Scala 語言。一般情況下，某項技術至少需要 1 – 2 位高階工程師解答遇到的所有相關問題，這位工程師需要從原始碼級別理解這項技術。優先選擇成熟技術。
技術選型一定要考慮當前團隊人員的技術組成。對於一些比較基礎的技術的選型，比如語言和框架、資料庫等等，往往最合適的選擇就是團隊最熟悉的技術。如果打算選擇不同的技術的話，那就要考慮下團隊是否有人能夠 Hold 住了。另一個必須要考慮的是招聘，如果使用的是比較小眾的技術，那麼當需要擴充團隊的時候，招聘人員會比較困難。
還有一點就是，雖然技術選型需要考慮團隊人員的喜好，但千萬不要因為某幾個人的個人喜好，來決定技術的選型。還是通過細緻的分析和實驗來進行選型。而決策者也需要看的更長遠一些，推動團隊技術向前發展。
我們經常會遇到，一項新技術在公司內久久難以推行,因為業務主管的阻撓。即使排除利益糾葛，仍然會發現一種發自內心的不信任存在。而這種不信任，又往往來源於對同事工作的不認可。
對於技術管理者，在技術選型時，重點還需注意團隊人員流動性。人員流動帶來的損失比大多數人所認為的要大得多。人員流動會帶走知識和文化。企業要避免損失，就要把這些知識和文化儘可能記錄在程式碼中。
當然，這並不意味著應該要求大量寫註釋，而應該使用那些能留存知識的技術，比如型別系統和規範化命名。型別系統和規範化命名可以半強制性地要求開發人員把原本只存在於自己腦子裡的知識記錄到程式碼中。如果更有追求一點，可以再嘗試普及單元測試。這樣，當他離開的時候，即使沒有文件，這些知識也仍然能留存下來。從效果上說，程式碼往往比文件和註釋更好。而文化的留存則更加困難，事實上，程式碼中的奇葩註釋往往留存的是負面文化。應該在程式碼中留存的文化，是嚴謹、專業的工作態度。雖然自由也是文化的一部分，甚至在管理領域是非常值得嚮往的文化，但在工程領域，它往往是一種負面文化，因為軟體開發領域並沒有公認的法律甚至道德。你可以想象一下管理領域中沒有約束的自由會導致怎樣的後果。
所以，要想應對人員流動的風險，除非你有信心留存知識與文化，否則就應該在技術選型時，傾向於選擇更加嚴謹的、隱式資訊更少的技術。
專案產品考量
短生命週期的產品通常要求快速起步：門檻低、書寫自由、不強制遵循任何最佳實踐。當它的使命結束時，程式碼會被直接拋棄。所以，對於這類產品，“快糙猛”的技術是較好的選擇，當然，能做到“快精猛”更佳。
而長生命週期的產品則會強烈要求可維護性，因為它們在很長時間內都是不可報廢的。甚至對於一些生命線產品，連重寫都會要求在重寫期間線上系統平穩過渡，一點點遷移到新技術。
這種要求對團隊的工程化能力是個極端的考驗。如果沒有相應的工程能力，其代價甚至會高於用新技術重新寫一個功能相同的系統。
穩定第一的專案比如銀行專案，雖然不少銀行也研究新技術，但是較少用在生產，因為銀行受到評級和監管約束，一旦將新技術引入線上，會導致評級下降，監管問詢等。
探索型產品往往也是短週期產品，但是同時也有自己的特點。它要求快速，但往往同時會要求高質量。探索型的產品如果證明了可行性，那麼過渡到長生命週期的可能性很大。
這就要求它最好是一個微核心系統，提前留出一些擴充套件的空間。當然，設計微核心系統對架構師的能力具有相當的考驗，如果沒有一個優秀的架構師，建議還是不要刻意做任何預留，優先保障系統的簡單性。
除此之外，探索型產品的技術棧必須支援可靠的、自動化的重構。因為探索型產品的迭代速度很快，如果完全靠人工去新增功能並手動重構，那麼一旦出現 BUG，將給此產品的使用者體驗帶來嚴重的負面影響。
所以，除非由於人才儲備等原因而被迫做出折中，否則探索型產品的技術棧一定要快速而嚴謹。而對守成型產品的選型則會側重於與現有技術棧的相似程度和無縫整合能力。如果整合時需要藉助很多技巧，那麼可能你就是在給自己挖坑。
在引入新技術的過程中，要儘可能符合現有的開發流程、基礎設施和開發習慣。當然，如果現有的這些已經嚴重過時，那麼應該找新老技術的專家，共同幫你設計一個路線圖，讓你可以平穩地引入新技術，這份投資絕對值得。如果老技術已經有新版本，則應該優先考慮升級它。不要幻想換個技術棧就能解決一切問題，事實上，它帶來的問題往往會更多。
業務考量
所有脫離業務需求的技術方案，都是耍流氓。
只有真正契合業務上下文的方案才是好的方案，而每個專案都有自己的特殊性，需要把專案上下文儘可能瞭解清楚，找出專案成敗最核心的1到2個標準，以此作為基礎來做選擇題。譬如說，創業專案，靈活是明顯的述求，產品推出後必然會面對朝令夕改的需求，如何快速反應是選型的重點。再譬如說，陳年專案效能遇到瓶頸需要重構，再往下挖可能原有系統吞吐量不成問題，但瞬時響應太差，選型時就需要特別注意這個點。
如何做好技術選型
如果我們從天時，地利，人和這幾方面去梳理當前業務的情況，會發現很多我們原本沒有注意的問題。我們必須從業務角度去梳理企業業務規劃，業務戰略以及當前業務遇到的痛點和難點，組織架構。團隊成員的技術特徵以及技術棧偏好。還有當前使用的技術情況等。
梳理當前能解決我們需求的開源專案或者工具，並分析一些核心指標能滿足我們大部分的需求進行篩選並列出表格。從中我們梳理一些選型中會考量的核心指標，並把核心指標對應的權重做出表格，讓相關人給對應的指標分配合適的權重，綜合相關人的權重算出合適的權重。做出指標和權重的表格，讓參與選型的相關人進行指標值打分。對打分結果進行計算，對不同的待選項的得分高低進行篩選。切記篩選核心指標要細緻準確。
技術選型最好羅列至少3個以上的待選，並在選好型之後，還附加一個備選技術方案來兜底。我們應該瞭解選型物件的不同，有時候核心考量指標可能差距偏大。以大資料平臺為例：
這些指標是我和技術分享@華山論劍@湖北群組中的大資料平臺架構師wander聊過後梳理的。因為在從業早期，對不同的選型物件，所偏向的指標在某幾個點上是有很大差距的，大資料平臺，中介軟體，雲平臺等等。
有一個點可能是共通的，就是無論是什麼技術產品或者專案，我們都需要有個人能體系化的熟悉選型物件涉及的技術並瞭解相關生態，基於這點我們排除團隊，成本等因素更可能做一個靠譜執行順利的技術選型。
常見選型案例
開發語言，開發工具，專案管理工具，知識庫，中介軟體，框架，儲存，監控運維平臺的選型是我們經常會遇到的。
通常我們選型會考慮一些通用的選型指標，具體的選型可以在通用選型的基礎上具體化對應的指標，亦可根據選型的特殊性在通用選型的基礎上篩選核心指標。
以API閘道器為例，在某公有云公司的時候，當時開發一個人，運維屬於跨部門溝通沒有垂直SRE，由於當時公有云在發展初期的樣子，規劃是整個公有云的開放平臺和閘道器，IAAS和PAAS部門幾十條產品線陸續在開發結束等著接入API閘道器把能力開放給大客戶。IAAS部門高階中間和產品高階技術總監對專案趕的很緊，但是人力投入不夠，為什麼人力投入不夠，這個涉及到領導各方面意識的錯位，這點錯位一直到半年之後的一次公司重大組織架構調整之後才有所改觀，對於閘道器和開放平臺的主要研發來說，一個人從各部門溝通，方案，設計，維護，測試各個層面來講，承受的壓力都不小。2017年的時候可選的開源閘道器不如如今這麼多，當時比較多的zuul1被技術圈的朋友在設計上和效能上詬病，sc gateway。從技術棧上看，lua棧的有kong和orange，基於OR自研。go棧的悟空，tyk，自研。java棧的zuul1，sc gateway剛開始版本v1在進行中(下半年才開始推廣中小企業應用)，zuul2一直未發。
面對當時的情況，有幾個想法：1 找一個功能強大，口碑較好，方便易用的(如kong)快速驗證上線，後期做二次開發。2 基於內部的RPC框架做開發，但是當時公有云部分正在去集團的RPC框架，糾結了一會。3 基於go語言改造一套，但是問題是我們部門多是java棧的，我對lua的比go熟一些，公有云很多是go棧的，又是一個糾結。真是天時，地利，人和三點都不沾。當時的處境如同，老闆給你遞了兩個爛核桃，你還不得不吃。
還是得一步一步來，而且要快速去驗證，於是快速對kong的社群和原始碼進行查閱，並快速部署，去驗證。任何新東西的引入都會踩坑，我驗證的過程中發現對於kong叢集的通訊，節點資料一致性，konga管理後臺的配置和使用，kong的部署安裝，資料庫的支援，運維部署的複雜度等等都或多或少要不就是坑，要不就是不符合國內使用習慣和架構設計風格，但是唯一就是外掛很豐富，功能很多。其實如果時間充裕一點，不是一個人做，我寧可選擇java自研或者go自研。或者說當時kong不成熟吧，與kong的國外研發團隊溝通的過程中卻是也覺得，他們技術的深度可以，然後再不斷的踩坑中進行著kong的二開之路。我相信這次選型不是一次充分的選型，當下可選的API閘道器很多，開源的也太多，soul，APISIX進入Apache基金會，sc gateway的成熟等等新成員陸續出現。
API閘道器除了上面通用的選型要素還應該注意什麼呢。大多數人會說協議支援，路由粒度及策略，負載策略，安全擴充套件，高效能這樣幾塊，這些屬於技術要素裡面我們需要考慮的細項。
我們根據通用選型指標給出對應的專家打分權重，篩選了幾個備選的API閘道器：APISIX，soul，kong，tyk等。注意三個以下備選行不算有選擇。
接下來基於通用指標考量之後，我們進行細化指標考量。
帶著以上指標去快速調研和驗證，並填充上面表格，根據當前的選型背景選擇合適的。至於具體如何量化的對閘道器進行選型，因為考慮到不同的團隊面對的情況不一樣，將在下一篇 API閘道器的設計中去聊API閘道器的量化要素。
題外話，最近和一些技術圈的兄弟準備發起《技術價值分享會(湖北) 暨老鄉會》的聚會，希望技術朋友們，特別是老家在湖北的技術從業朋友，不管你在北京還是深圳，廣州，或者在杭州，蘇州，成都，武漢，我們都很歡迎和期待您的加入。
總結
凌雲：技術價值分享會(湖北) 暨老鄉會發起人。湖北武漢人，計算機碩士研究生，在校期間主要研究方向是人工智慧演算法的優化演算法和軟體質量度量模型。相關論文《脈衝神經網路影像分割的編碼方法》發表於計算機工程期刊，《改進粒子群的軟體質量綜合評價方法研究》，《粒子群演算法改進策略研究》也被一些論文和期刊引用。崗位從研發到架構到架構管理，涉及行業包括線上教育，數字社群，智慧交通，公有云，電商，重資產長租等領域。同時也參與中介軟體開發及負責開放平臺，服務框架，安全威脅建模等領域。在新華網負責過教育平臺技術架構，後被朋友推薦去京東，在京東雲和京東商城主要致力於API閘道器，流量閘道器和開放平臺方面的研發和架構，目前是重資產長租領域獨角獸企業技術架構委員會委員，softech華山論劍作者。致力於最有價值的技術傳播分享，推動輕鬆高效的技術氛圍建設，希望能順利推動湖北地區技術氛圍建設與技術壞境的良性轉變。同時也希望組建我們的技術從業者足球隊和籃球隊，提升技術從業人員"健康第一"的意識。
特別值得介紹的是我們的發起人團隊都是87到95的一群年輕陽光的小夥子。如果您自驅動的學習，樂於分享，熱愛開源，並執著於技術，如果你是一個利他、陽光、正氣、勇敢、執著、創新的技術從業者或者在校學子，歡迎掃碼加入。如果你是湖北地區或者漂在一線城市的湖北技術從業人員或學子，我們也歡迎你加入，我們在這等你。