程序人生之项目团队那些人与事(6)

                                                                            6--技术风险

我本人也是喜欢跟随技术的新潮，从业这么多年基本上从最初的C/S到B/S,从企业的B/S系统到基于互联网上的电子商务，包括现在流行的安卓,ios的开发，我也通通参与其中过。当然新旧技术交替也是一个很正常的过程，很多人也以为新潮的技术肯定是主流方向。但有时候也未必，一定要根据你团队你公司的具体环境来分析要不然肯定会导致技术风险的出现。在我的从业经历中，有过那么几次都面临着这样的风险。05年的时候，spring冒了出来。它以一个精简的j2ee框架从根本上可以终结了ejb，虽然那时候我们用ejb只开发过很少的项目，大部分时间里我们都是jsp+javabean的模式。这种模式的缺点就不言而喻了，总之当新技术冒出来的时候，我就迫不及待的想用这种框架去替换掉它。当时我们正好有一个企业级的应用项目，我就想把这些融合到项目中去。心里还美滋滋的想着，在我的职业生涯中又多了一项新的技术应用框架，所以为了让自己的技术生涯多了亮丽的一笔。那时候我们的团队对于SPRING的了解只停留在学院的理论上，并没有真正实现过。那时候spring还是早期版本。离项目预定上线时间只有3个月的时间，我们其实是一片空白去做这个事情。但我说服了我们的主管领导，我告诉他这是正确的技术路线，之所以选择它因为它代表最新潮、最先进的技术，也会让我们的产品包装更加完美。我激动万分的游说领导，把学习成本、还与该平台配套的AJAX抛之脑后。领导被我说动了，然而现实让我们倍感困难。先说说前端和spring的接入问题就搞了好几套方式，个个都不如意。web2.0时代很多东西学起来并不那么块，尤其JS调试这端尤为麻烦。最为我们勉强选择dwr，在spring的使用方面，我们遵从的都是官方文档上的内容开发。并没有多么深入的内容，基本上按模式的需求来做的。像很多spring靓丽的特点我们并未有用到，我们大概就是按照service+dao层来划分业务，dao层本来想引入ibatis持久层技术，但时间已经不容许我们去研究了。所以我们采取了还是jdbc的方式，总之用这个新技术并没有给我们整个项目的进度带来帮助，另外我们觉得新的技术框架似乎没有解决什么问题，因为就算不用这个框架我们也可以做好。另外，在开发中遇到的问题，只能在相应的技术圈讨论，而那个时候关于spring技术圈并没有形成一定气候，很多时候有问题找寻不到解决的办法。只能依靠技术牛人的强力加盟，所幸，在项目后半阶段J爷出现了。他自己花时间去体会，虽然有了他把很多问题都解决了。但是如果不是人事协调的成功，这个项目团队所面临的技术风险就很多。那时候我们依旧很被动了，但还是准时准点上线，但代价就是每日每夜的加班。这个项目上线后，我曾认真的反思过：但凡我们在考察一个框架时，也许被它各种新特性、新功能吸引，但真正开发某一项业务时我们或许只用到一小部分而已，或者说根本不需要用这样的框架。也许正是迎合了自己的发现新技术的猎奇心理而已。所以当项目组的成员想用花哨的表现手法处理某种业务时，我是坚决反对的，因为我知道代码使用越多，出问题的概率就会越大，当采用任何技术时一定想考虑它的维护成本，学习成本。不过最为重要的是，当我们面临一个新技术时，首先还是要考虑这个新技术是不是真的为这个项目解决什么问题，对这个技术要作合理的评估，要多一点挑剔，不要盲目跟风相信吹嘘的技术。因为我们是做项目，不是搞科研。

                                                                                                                                                                                           （未完待续....................）