如何给别人提供支持库

     做核心模块和公用模块的开发，估计是做架构师的第一步！如何给别人提供库的支持是一个非常需要考量的东西！

     在工作的过程中，免不了要给别人提供公用部分的支持。 一般就是以模板头文件，或者静态、动态库之类的形式来表现！很多的技术的沉淀就是这种方式流传。下面说一下给别人提供支持应该注意的几个地方！

     首先多说几句，其实，这是一个费力不讨好的活。假设别人用你的公用库，出了问题你得负责！不出问题，你不一定得到嘉奖！出错的东西最引人注目，小心给人留下“不稳的”的印象！
    
     如果是别人和你合作，必须(注意这个词：必须)调用你的接口来完成事情，那还好些。因为那是没有办法的事情。麻烦的就是，那些公用的部分，比如网络服务，通用的算法的实现，或者其他的功能的包装等等。特别是在一个技术积累不太多的公司里边，你好像是觉得自己发善心，表现一下自己的积极性，“哎呀，什么公用的东西都没有，我来写一些，大家用多好！” 。 呵呵！ 如果你是职位比较高或者得到职位比较高的人的认可，可以强势推行，还好一点。 否则，估计没有人会用。会有这几点原因！
    
     1. 一般来讲，很多技术人员都喜欢用自己的东西！因为自己做的设计，自己做的编码，自己做的接口，自己统统熟悉。对别人的东西有疑虑：不稳定？不合自己习惯？还得花时间熟悉学习！
     2. 你算老几？为了用你的东西，还得跟你请教！技术人员很多是骄傲的猫！总觉得自己可以！别人不干你干的东西别人是不是认为你在表现自己？特别是大家的资历差不多的时候！千万不要忽略这个心里因素！这是可能是第一反应！否则上边我就不强调那个必须了！
     3. 项目进度管理不善！ 作为一个管理者不清楚、不懂得应该保留提炼什么！放纵做一次重复实现一次，(这种的最恶心)，看起来写了很多的东西，但是很多是无用功！更不清楚下边的人的工作量是多少！
    
     一个公司里边做项目的开发，除了项目代码，设计以外，可以用的高效率的工具库是必不可少的。你不可能总用STL。那个东西是为了通用而存在的。通用的东西放到特定的环境里边一般都是不能达到较高的效率。你也不可能总把代码拷来拷去！拷贝和粘帖是产生那些最难发现的bug的原因之一！如果没有凑手的工具，做开发的效率怎么可能提高！ 当然做开发，写代码只是一部分！但是大多数情况下还是比较重要的一部分! 如果连这个最基本的都管理不好，那么还能管理好什么？最怕的是没有这些意识！如何不断提高生产率、改进过程的意识！
    
     技术，只能改变技术层面的东西！或者是他们得到润滑！我这里只讲上边的第一条，如何让第一条的过度更平滑一些！
    
     需要注意的是：普通的软件的用户跟你的软件的用户不一样！你的面向的受众是程序员！
    
     1. 实现公用东西之前，先写测试用例！
        这个东西是让别人用的。 他的用户关心的是是否好用！其实，如果一行代码都不调用就可以是最理想的。 不过这好像行不通！但是，用最少的工作量来完成工作可能是用户最关心的！这就需要隐藏细节！隐藏的越深越好，最好外边什么都看不见！像STL里边为了因层各个类的内部变量，用了一个iterator！ 要考虑这个东西的应用的场景，在什么情况下用！而且，用户是懒惰的，如果能够场景一致，他们利用拷贝和粘帖就可以完成你的库的调用，是最理想的！那别人就不需要看什么文档了！例子中的几行代码就是最好的文档！不是每一个人都有如此高的兴趣去欣赏你的内部实现--特别是工程比较紧张的时候！这些，都需要有好的调用的实例！而且，这也是后边做测试的基础，同时定义了你的接口--是你在对内部还不知晓的情况下的对接口的定义！也许写到后来你会发现，这个接口怎么不容易实现？不如改改？ 最好不要改！ 改了，增加的是调用的难度和第一感觉！ 还不如自己在后边隐藏这些东西！ 这种情况很容易碰到!       
    
     2. 注意效率。但又要防止过度的设计。
        软件都是有生命周期的！ 没有最好，够用就好，够用最好！我们往往想要把任何的东西都弄到极致！其实，不一定必要。比如说，读配置文件！你说读一遍和读10遍差别大吗？以前，同事给了我一个读配置文件的类，为了读每一个配置文件里边的变量，都需要重新读一遍文件！ 我当时自己也实现了一个，是用AVLtree把配置文件里边的数据全部加载进来，然后对每一个变量进行查找。看起来好像我的效率高啊！其实，读配置文件就是程序启动时读一下！其它情况基本不读！这个文件很小，多读两边无所谓，况且还有系统对这个文件的缓存！我当时的那个实现有点高射炮打蚊子！呵呵！
           
       
     3. 做大量的测试
        对一个设计兼实现者来说，最让人尴尬的可能就是程序出core文件。最好的办法就是让core都处在你的测试当中！想想看，你给比人的东西个顶个都是非常稳定的、有效率的！别人的印象会怎么样！要有意识的树立你的这种形象：我就是稳定的！那估计你的东西推行起来就会很顺利！需要非常注意这种潜移默化的影响！
       
     4. 善待别人发现的问题！
        工程量一大，出现bug或者是设计上的不方便都是正常的！既然老虎也有打盹的时候，那么不妨多看看别人的设计，听听别人的意见！听别人说不好往往心里是不痛快！其实，更不痛快的估计是你的心血得不到别人的认可！提意见的客户都是非常好的客户！否则，他连提意见的心情都没有！
    
     5. 不断的改善和学习！
        很多人都觉得自己水平可以，不过好像还没有几个敢说自己水平天下第一！也没人敢说自己的产品没有bug!  多想别人在设计东西的时候为什么如此的设计，搞懂了那些，让自己受益匪浅！
       
       
     6. 好东西也要会吆喝！
        最起码你得给别人发一封邮件说明你做了什么，这个东西可以完成什么东西吧！既然对自己的东西有信心，希望得到别人的认可，那就需要不厌其烦的推销！说的越多越好--特别是不能强势推行的情况下! 在信息扑面而来的情况下，很少有人自动对你的东西感兴趣！
    
     麻雀虽小，但毕竟是五脏俱全！不要小看任何一个东西的包装！往往越是细节越能够考量一个人的技术水平！举个例子来讲，fwrite可以认为是write函数的带buffer版!  做服务器设计的估计要用到大量的IO操作！ 你有兴趣不妨自己写一个fread,fwrite等函数！往往非常有收获！ 还可以把读写远程文件给包含到其中，让读写远程和读写本地一样！再考虑一下中间出错的情况！不妨实现一下试试！这种的东西一直处在底层，常常让我们忽略了他们的存在！但是，如果他们的稳定性不过关，你可以想想会带来多大的麻烦！ 这种锻炼往往超出自己的预期!
    
     古人云：富贵不回乡，如衣锦夜行！ 都是再说能够得到别人的认可! 我想，能够得到周围同事的认可是最让我们高兴的！但是，要做好受打击的心里准备，毕竟可能是什么地方做的不好！不然，大家为何放着方便不用，自己鼓捣一通！特别要注意自己的形象的树立，人往往都是信任强者！ 要想人前露脸，只能自己偷下苦功！更不要觉得自己委屈：我费了这么多时间精力做了这么多东西，都得不到别人的认可！。。。。光有好的想法和心意是远远不够的！站在别人的角度讲，用你的东西是有风险的，如果你的东西不够好，用你的简直就是添乱！更不要认为自己觉得是对的，也要强迫别人认为自己是对的！很难！能够给你提意见的朋友都是你值得珍惜的好朋友！最需要提防的是那些每天笑脸相迎，不论什么时候都是好好好是是是的！
    
     如果，我是说如果，你把上边说的还有没说的那些统统都做的很好，咦，怎么还是没人用! 我晕！ 伙计，你融入团队的方法不对啊！ 别老闷头干活了！看看别人都在干什么！。。。。。。。
    
     给别人提供库支持？很多情况都是费力不讨好的事情！请三思而后行！