做核心模块和公用模块的开发,估计是做架构师的第一步!如何给别人提供库的支持是一个非常需要考量的东西!
在工作的过程中,免不了要给别人提供公用部分的支持。 一般就是以模板头文件,或者静态、动态库之类的形式来表现!很多的技术的沉淀就是这种方式流传。下面说一下给别人提供支持应该注意的几个地方!
首先多说几句,其实,这是一个费力不讨好的活。假设别人用你的公用库,出了问题你得负责!不出问题,你不一定得到嘉奖!出错的东西最引人注目,小心给人留下“不稳的”的印象!
如果是别人和你合作,必须(注意这个词:必须)调用你的接口来完成事情,那还好些。因为那是没有办法的事情。麻烦的就是,那些公用的部分,比如网络服务,通用的算法的实现,或者其他的功能的包装等等。特别是在一个技术积累不太多的公司里边,你好像是觉得自己发善心,表现一下自己的积极性,“哎呀,什么公用的东西都没有,我来写一些,大家用多好!” 。 呵呵! 如果你是职位比较高或者得到职位比较高的人的认可,可以强势推行,还好一点。 否则,估计没有人会用。会有这几点原因!
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等函数!往往非常有收获! 还可以把读写远程文件给包含到其中,让读写远程和读写本地一样!再考虑一下中间出错的情况!不妨实现一下试试!这种的东西一直处在底层,常常让我们忽略了他们的存在!但是,如果他们的稳定性不过关,你可以想想会带来多大的麻烦! 这种锻炼往往超出自己的预期!
古人云:富贵不回乡,如衣锦夜行! 都是再说能够得到别人的认可! 我想,能够得到周围同事的认可是最让我们高兴的!但是,要做好受打击的心里准备,毕竟可能是什么地方做的不好!不然,大家为何放着方便不用,自己鼓捣一通!特别要注意自己的形象的树立,人往往都是信任强者! 要想人前露脸,只能自己偷下苦功!更不要觉得自己委屈:我费了这么多时间精力做了这么多东西,都得不到别人的认可!。。。。光有好的想法和心意是远远不够的!站在别人的角度讲,用你的东西是有风险的,如果你的东西不够好,用你的简直就是添乱!更不要认为自己觉得是对的,也要强迫别人认为自己是对的!很难!能够给你提意见的朋友都是你值得珍惜的好朋友!最需要提防的是那些每天笑脸相迎,不论什么时候都是好好好是是是的!
如果,我是说如果,你把上边说的还有没说的那些统统都做的很好,咦,怎么还是没人用! 我晕! 伙计,你融入团队的方法不对啊! 别老闷头干活了!看看别人都在干什么!。。。。。。。
给别人提供库支持?很多情况都是费力不讨好的事情!请三思而后行!