作为一名开发人员和技术管理者，每次做技术选型时都好像是在理想与现实之间走钢丝，求取平衡成了我必须要掌握的技巧，有时候真可以说是战战兢兢，如履薄冰。
记得参加一次OpenParty，有位产品经理将程序员与产品经理形容为汪星人和喵星人，这样的比喻似乎也可以套用在开发人员与技术管理者这两个角色上。然而若身兼此两种角色，又会是什么星人呢？或许可以称为双子星人！
技术管理与技术研发并非水火不兼容，然而在判定优先级上，二者不可避免存在本质的冲突。技术管理需要关注产品的质量，进度以及研发团队的生产效率与工作氛围，而作为拥有极客范儿的技术研发，则天生容易将注意力放在技术的新、奇、炫， 更有一种技术人的“情怀”或者“抱负”，因而极客们体验到的成就感更多地是自己是否能将这么艰深的技术玩通，能否用上当今最新潮的技术，能否造出更漂亮更强劲的新一代轮子；而管理者呢？追求多少有些“俗气”，考虑的还是商业价值与投入成本了。
在做技术选型时，这两种不同方向的力量就开始角力了。
这就是技术选型的理想与现实。
这几日，我们团队在纠结前端技术的选型，而产品的研发周期也是迫在眉睫。选型时，我们既要考虑当下，又得着眼未来。可叹的是，对于前端技术，除了一位前端开发，其余团队成员对之知之甚少。
针对前端的可视化库，我们的前端已经花了不少时间对D3进行了封装与简化，并开始尝试在产品中使用。然而毕竟开发时日尚短，许多功能尚待完善，稳定性更是我极为担忧的风险。一个可以现成重用的库是ECharts，它基本能够满足我们的要求。我们该如何抉择？从规避可能的风险，降低成本，缩短研发周期的角度来讲，在目前这个研发阶段，似乎选择ECharts才是明智之选；然而谁又愿意将自己倾力打造的库束之高阁呢？中断自研库的开发，是否会浇灭前端人员的热情之火呢？
每个人都在提“不要重复制造轮子”，但是对于大多数有技术追求的程序员而言，当他（她）面临技术问题时，第一时间在脑中浮现的解决方案都是自己来制造。即使是这个口号的倡导者Rod Johnson，不也重复制造了一个轮子么，否则哪里还有Spring？
当我们在讨论前端的数据流控制框架时，我们陷入了Reflux与Redux之争。我非常惊叹于Redux的设计理念，尤其是因为引入函数式编程与不可变状态带来的简单可预测的模型，真是让人着迷。可是Redux这种专注状态管理的设计机制固然遵循了“关注点分离”原则，却也在知识理解的复杂度上更增加了一层间接，似乎并没有Reflux对数据流的单向控制来得直截。Redux的Reducer机制会让我们想起Actor，想起事件驱动，想起模式匹配，较诸Reflux的代码，终归在理解上还是要复杂一些。
最关键的一点在于我们所有团队成员都不熟悉Redux，而运用Reflux，我们已经在前端有了不少的实现。这一点，彻底击中了我的要害！
在进度压力的迫使下，我在这两次技术选型中我选择了“现实”，但我并没有放弃“理想”。我会尝试着推动前端人员继续制造满足自己“情怀”的轮子，我会继续关注诸如Redux之类新酷的技术，虽然我可能会在下一次继续向“现实”低头，但只要“理想”不灭，总会有研发思想占上风的角力场。 我甚至要告诫自己，作为技术管理者，首先我还必须是一名热爱技术的极客，追求技术卓越的梦想。
只要敢想，一切仍有可能！
