作為一名開發(fā)人員和技術(shù)管理者，每次做技術(shù)選型時都好像是在理想與現(xiàn)實之間走鋼絲，求取平衡成了我必須要掌握的技巧，有時候真可以說是戰(zhàn)戰(zhàn)兢兢，如履薄冰。
記得參加一次OpenParty，有位產(chǎn)品經(jīng)理將程序員與產(chǎn)品經(jīng)理形容為汪星人和喵星人，這樣的比喻似乎也可以套用在開發(fā)人員與技術(shù)管理者這兩個角色上。然而若身兼此兩種角色，又會是什么星人呢？或許可以稱為雙子星人！
技術(shù)管理與技術(shù)研發(fā)并非水火不兼容，然而在判定優(yōu)先級上，二者不可避免存在本質(zhì)的沖突。技術(shù)管理需要關(guān)注產(chǎn)品的質(zhì)量，進度以及研發(fā)團隊的生產(chǎn)效率與工作氛圍，而作為擁有極客范兒的技術(shù)研發(fā)，則天生容易將注意力放在技術(shù)的新、奇、炫， 更有一種技術(shù)人的“情懷”或者“抱負”，因而極客們體驗到的成就感更多地是自己是否能將這么艱深的技術(shù)玩通，能否用上當今最新潮的技術(shù)，能否造出更漂亮更強勁的新一代輪子；而管理者呢？追求多少有些“俗氣”，考慮的還是商業(yè)價值與投入成本了。
在做技術(shù)選型時，這兩種不同方向的力量就開始角力了。
這就是技術(shù)選型的理想與現(xiàn)實。
這幾日，我們團隊在糾結(jié)前端技術(shù)的選型，而產(chǎn)品的研發(fā)周期也是迫在眉睫。選型時，我們既要考慮當下，又得著眼未來。可嘆的是，對于前端技術(shù)，除了一位前端開發(fā)，其余團隊成員對之知之甚少。
針對前端的可視化庫，我們的前端已經(jīng)花了不少時間對D3進行了封裝與簡化，并開始嘗試在產(chǎn)品中使用。然而畢竟開發(fā)時日尚短，許多功能尚待完善，穩(wěn)定性更是我極為擔憂的風險。一個可以現(xiàn)成重用的庫是ECharts，它基本能夠滿足我們的要求。我們該如何抉擇？從規(guī)避可能的風險，降低成本，縮短研發(fā)周期的角度來講，在目前這個研發(fā)階段，似乎選擇ECharts才是明智之選；然而誰又愿意將自己傾力打造的庫束之高閣呢？中斷自研庫的開發(fā)，是否會澆滅前端人員的熱情之火呢？
每個人都在提“不要重復制造輪子”，但是對于大多數(shù)有技術(shù)追求的程序員而言，當他（她）面臨技術(shù)問題時，第一時間在腦中浮現(xiàn)的解決方案都是自己來制造。即使是這個口號的倡導者Rod Johnson，不也重復制造了一個輪子么，否則哪里還有Spring？
當我們在討論前端的數(shù)據(jù)流控制框架時，我們陷入了Reflux與Redux之爭。我非常驚嘆于Redux的設(shè)計理念，尤其是因為引入函數(shù)式編程與不可變狀態(tài)帶來的簡單可預測的模型，真是讓人著迷。可是Redux這種專注狀態(tài)管理的設(shè)計機制固然遵循了“關(guān)注點分離”原則，卻也在知識理解的復雜度上更增加了一層間接，似乎并沒有Reflux對數(shù)據(jù)流的單向控制來得直截。Redux的Reducer機制會讓我們想起Actor，想起事件驅(qū)動，想起模式匹配，較諸Reflux的代碼，終歸在理解上還是要復雜一些。
最關(guān)鍵的一點在于我們所有團隊成員都不熟悉Redux，而運用Reflux，我們已經(jīng)在前端有了不少的實現(xiàn)。這一點，徹底擊中了我的要害！
在進度壓力的迫使下，我在這兩次技術(shù)選型中我選擇了“現(xiàn)實”，但我并沒有放棄“理想”。我會嘗試著推動前端人員繼續(xù)制造滿足自己“情懷”的輪子，我會繼續(xù)關(guān)注諸如Redux之類新酷的技術(shù)，雖然我可能會在下一次繼續(xù)向“現(xiàn)實”低頭，但只要“理想”不滅，總會有研發(fā)思想占上風的角力場。 我甚至要告誡自己，作為技術(shù)管理者，首先我還必須是一名熱愛技術(shù)的極客，追求技術(shù)卓越的夢想。
只要敢想，一切仍有可能！
