其它开发组是基础库开发组的用户，上级是基础库开发组的客户。基础库开发组和其它开发组不是协作关系，因为其它开发组的成果不影响基础库开发组的质量。
推动基础类库，而不是拉动基础类库。拉动基础类库，至少会有如下几个问题：
一，没人能100%正确，我自然也是。
二，就算我是正确的，我和使用者的思维不一定是同一层次。水平高的认为简单无用，刚入门的认为太复杂。
三，拉动不容易尊重用户的使用习惯。想教育用户的人，往往会被用户教育。除非垄断产品，否则别想改变用户的习惯；就算是垄断产品，强行改变用户习惯，也会让用户愤怒。
四，人天生是扛精，同样的观点，如果是自己提出的，更高的几率支持；如果是别人提出的，更高的几率反对。
分五个阶段：
一，熟悉同事。收集大家的库、类、函数，整理并推广公共库。推广是主要工作。这是长期的过程。
二，熟悉代码。协助一个项目，收集好的东西，提一些书面的建议。一般2到4周。
三，收集天使用户，种子用户。主导一个项目或虚拟项目，优化到用户、绝大部分程序员满意，大部程序员（种子用户）比较满意，少数程序员（天使用户）很满意。一到3个月。
四，完成框架。在第三阶段的基础上，完成一个框架，并根据程序员的建议修改。一个月左右。
五，验证、完善框架、培养人才。和至少一个程序员协作，利用新框架完成一个项目。等项目基本完成后，我退出此项目，进入新项目。一到2个月一项目。
不同类型的项目，可能使用不同的框架。一个类型一类型来。 第一个框架建议最简单（万事开头难），第二个框架用得最多的，第三个框架最难的。
工作内容（减少重复造轮子）：
1，抽取已经封装的函数或类，整理文档和测试用例。
2，发现多次重复的代码，列出可能封装的函数和类供大家选择。
3，根据选择的结果封装类和函数。
4，完成相关相关类和函数的自动化测试。
5，反复测试可能的缺陷（尤其崩溃），避免坑惨调用者。
6，请不忙的同事，进行评审。有则改之，无则加勉。反复修改，直到大家满意。
7，查阅代码，看此函数可以代替那些代码。和作者沟通，告诉他那些代码可以直接用封装的类代替，如何代替。由作者自己决定是否代替，如果代替出问题及时反馈给我，我负责解决。
我以前看过一本书，新发明是否存活，和能否让用户爽有关，能否提高效率反而是次要的。所以，刚开始推广公开库的时候，不能因为提高效率而让用户不爽。推广结束，提高效率才是重要的。不要影响其他开发组程序员手头的工作，这是作死之路。
拆掉一个可用但不完美的房子，必定弄得天怒人怨，众口难调耳。每次拆掉几块坏了的砖，换上新砖，只有人赞成，无人反对。等砖换光了，问题依然存在，这时大家的意见就统一了：框架的问题。一般而言，换掉部分砖，大家的意见就统一了：每次更换都有少量好处。少量好处证明优化的方向完全正确，但无法从根本上解决问题。
如果把基础类库当成一个产品，程序员是用户，公司是客户。开发过程中，用户重要，用户搞几个小动作，就让开发成本翻倍；开发的结果，客户重要，付款、评价权在客户手中。所以整个开发过程，用户的重要性不断降低，客户的重要性不断升高。显然，第一阶段以用户最强的需求开始。我估计：某些程序员对驻场深恶痛绝，此乃基础库开发组的天然同盟。如果找不到此类同盟，试图寻找其他类型的同盟。
标签：类库,框架,基础,用户,程序员,开发,公共 来源： https://www.cnblogs.com/he-zhidan/p/15314130.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。