上一代产品的功能，并且得出上一代产品的功能所映shè的客户业务流程。并且要求指出上一代产品业务流程中的漏洞和矛盾。二、他让大家通过改造源代码来学习新技术。

    他不仅仅让大家整理业务，还要画出来详细的流程图，整理出详细的数据结构。然后安排集中会议让大家讲，讲的时候，以流程图为主，走到哪一步，就进入软件界面讲解，并且讲明背后的数据存取到底是处理了哪些字段标志， 表之间是怎么关联的，到底从哪些表中取出来，表结构设计的有什么不合理的。

    这次没讲明的，这次提问没有确切答案的，下次继续讲，而不仅仅是讲一回。我发现，很多团队缺乏这种不断追根到底的魄力。总是虎头蛇尾，第一次讲的很起劲，讲的期间出现了自己也没有理解透的东西，领导只是安排下去再去研究一下，但就没有了下文。自己下去了看了一下，认为找到了答案，但就没有再次校验的机会了，于是最应该细究的地方被这样放过了。我们知道，编写程序，往往是最细节差异的地方最容易出现问题，而且很少能被测试到，而且维护代码的程序员往往不清楚这块是干什么的，一旦出现问题很难阅读懂。

    技术总监还让我们改造源代码。但这个也是有目标的，就是把控件都修改成一个统一的体验风格，没有DB的控件，就去寻找。寻找到了，就把这部分代码摘出来，然后形成我们自己的控件包，力求不要为了一个小小的控件，就安装整个的控件套件包。实在寻找不到，就自己开发控件。

    学习新技术，我认为这种方法是最好的一种方法。我现在也是这样指导我的下属的。

    学习新技术，为了怕误导，一是阅读官方的例子，如JAVA的宠物店或.NET的宠物店。但我后来我明白了，不能这么学。因为本来就对新技术陌生，一开始入主的就是这样的代码，那么以后的编写程序的风格就往往会像这些例子一样。其实，我们编写业务应用程序，并不需要这样的架构风格，也不需要秀那么多代码模式。照猫画虎把我们画的很累，还扭转不了已经固有的思维。我们不需要这种看上去很美的代码。

    学习新技术，第二种方法就是找一个网上开源的什么系统，如某些新技术尝鲜者做了论坛系统或什么什么管理系统。但这种方法也有个弊病，就是他自己写的代码有他自己的风格，而且他还处于尝试期，写这个东西可能是他为了学习这个技术，而非目标是开发这个管理系统。本来咱们对于新技术就是一张白纸，这下被他带到沟里去了。

    学习新技术，第三种方法就是阅读这个新技术本身的源代码。可惜本来就对新技术不熟悉，而新技术本身的源代码更是复杂，看的云里雾里，吃力看不到进展，yù想放弃。

    所以，学习新技术，最好是学习基于新技术的第三方的外国开源源代码。他们对新技术理解快理解深入，他们应用新技术不是为了尝试新技术或者秀新技术，他们是为了完成他们的一个实用产品。我们当时为了摘出某个控件，几乎阅读了那个控件套件包的所有源代码，并且理出了源代码的结构思路，否则我们无法确定我们遗漏了什么，会不会有BUG。

    但是，现在回过头来看，方法是对的，时机却是错的。

    我们是新团队、新产品、新技术，很多我们尚未了解清楚的，我们却把我们学习新技术后得到的控件应用到了我们以后的正式产品中，并且作为基础应用。这给以后的发展带来了几乎是灾难xìng的打击，我最后费了好大的劲才算把基础重构并且稳定住，否则基础崩盘了，上面的应用就不可收拾了。

    所以，我现在都是尽量限制使用新技术。也就是说，不会让新产品、新团队、新技术这三个新都同时出现，风险太大了。而且坚决不使用新技术作为基础技术。

   

『加入书签，方便阅读』