走出软件作坊《公共代码开发员-软件作坊里的高人》

完整内容在

http://blog.csdn.net/qinzhihu/archive/2009/01/13/3766423.aspx

在这里我们假设一个最典型的作坊模型，按照阿朱的《走出软件作坊》里所述，我们可以为一个项目配置如下人员。一个研发部，一名研发部经理，1-2名开发人员，一名项目经理，一名公共代码开发人员，一名测试，一名文案。在这个配置里，各个人员的角色和任务分配，大家大概可以推测。下面我重点强调一下公共代码开发人员的职责。

有一个大家都了解的事实是，在一家小型公司里，项目做成一槽烂的情况非常普遍，大部头的书，大家读的未必少，可是凡是什么东西，在这一个小公司里，就觉得处处掣肘，什么都实施不起来。看人家书上写的是天花乱坠，跑到自己公司里真正一实践，才发现那不过是镜中花。一槽烂的情况是因为大家基本都不怎么写注释和文档，不管你强调多少遍，喊的声嘶力竭，到最后把文档和注释给你写好的人，也是屈指可数。

为什么呢？难道程序员都是笨蛋？难道每个程序员都是混子，都不想写好？

按概率论来说，如果你觉得大家都是笨蛋，那大家是笨蛋的概率就很小了，最有可能是的你自己是个笨蛋。当你做到程序员的位置，从程序员的角度想一想，实际做一做，会发现真的很难。小公司项目的一个典型特点就是着急，催，催。而且实际上小公司里的大部分程序员水平都不是那么高，最起码没有项目经理想象的那么高。实际情况是小公司里员工流动非常频繁，能把员工留住的好的小公司十分稀少。

而在这频繁的流动中，小公司招聘的人大部分还是很初级的一些程序员，有不少是刚刚毕业的学生，这些学生一出门来，没有培训，没有培养，上来就是干项目，因为小公司也从来不花钱培训这些人。而这些程序员因为经验少，底子薄，写代码是不可能中规中炬，非常严谨的。最多的情况是，先紧着完成任务，其他的废话不要多说，先把功能做起来，让那按钮能按，让那表单能提交。

说一句实在的话，这么短的时间里，能把功能搞出来是最重要的，其他的什么流程啊，编码规范，设计模式啊，这些东西都是扯犊子。人家大公司能这样搞，不一定代表你小公司也能这样搞。如果哪个经理非要较真，上这些东西，最终的结果就是大家耗死在这个里面，流程严重滞后。程序员能够从百度，google上搜索到相关的代码，能够复制粘贴进来，把这个界面动起来，程序跑起来，就着实不错了。

说到底一句话，你公司给的待遇太低，大家的积极性是不大可能自发起来的。至于说什么理想，责任之类的废话，老板你说说可以，千万不要当真。还是按概率论，公司里十个人有两个能够甘于奉献，积极向上，则公司幸甚，老板幸甚。下面这些话，给予那些目前无力改变现状的经理们。这现状包括，公司招的程序员，你不能想赶走就赶走；公司的薪酬制度，你插不上嘴，也插不上手；你没什么东西能够强制这些程序干什么事情。说白了，公司就这些人，就这些破枪，你干不干？

要真想干的话，咱们说到的这个公共代码开发员，可就要大大的重视了，关于这个人员的职责，我还是引用下阿朱的《走出软件作坊》所述。

公共代码开发人员，一般就一个人。对于企业管理软件的开发，框架的开发和维护，公共代码的开发，高难度的问题跟踪，需要高性能的设计，需要高扩展性的设计，需要高稳定的代码，需要高安全的代码，需要高并发的操作，需要复杂代码重构。需要性能优化，不知道的技术API，都可以寻求这位公共代码开发人员的帮助。他还负责新技术跟踪、新技术介绍、新技术试验。但这个新技术必须是为了改进公司现有产品和现有客户。新技术的跟踪必须上报给技术总监，以防不符合公司目标乱跟踪或跟踪方法和思路不对。对于有利于现有开发的新技术，可以筹备好培训课，由研发部经理安排时间，让公共代码人员给研发部全体人员讲解。如果大家认可这种方法，就需要选择适当的时机在产品中引入。

因为你现在不能把宝压在刚毕业的程序员身上，但是你又得保证项目的质量不至于太差劲。那怎么办呢？你必须有自己的中坚力量，这个中坚力量就是公共代码开发人员，这个人你可以死皮赖脸的要求老板招一个有2，3年工作经验的人，如果老板不肯，那你就从招收的毕业生里重点提拔一，两个。这个中坚力量，在大公司里就是架构师，在咱这小公司里，叫公共代码开发员。

这个人唯一的责任就是保证代码质量和文档完善。别的活计，无论任务多紧，都不要分给他。一个公司，不管多小，横竖都会有公共代码，框架代码，一些通用的东西，前人写过了，后辈绝对不要重复。但是在这里，这个公共代码，不单单是说那些可以公用的类和方法，而是说所有共性的东西。比如说上传文件的代码，这次和那次的需求差不了多少，这个人就要维护好这些类似的东西。

因为你不分配给他具体的项目上的任务，所以他是有很多时间的，他这么多的时间来干吗呢？整理代码。你手底下的程序员不是忙吗，不是没空吗，这个事你就交给公共代码员。不必担心这个公共代码员水平不足，即便是你提拔的初学者，他见的多了，翻的多了，就熟悉了，因为他要翻开人人的代码，而且他有充足的剩余时间去百度上搜索，研究，他的水平慢慢就会上去。除了这个任务之外，他剩下的时间，就是要写注释，写文档，仅仅从程序员的角度写，不管其他的项目文档什么的，注意，这个人是宝贝，你得使劲保护着。王牌部队，给养要充足，任务要明确。只要这两个活干好了，你就得大大的赏。

用这个王牌军的好处有很多，一个是，让他从框架的角度把握程序质量，有他在，出不了大乱子。第二个是他要维护程序文档，从模式或者组件或则思想的角度来写这个文档，即便公司里铁打的营盘，流水的兵，因为在他这有良好的文档，所以新来的人，都有据可循。第三个，因为他常常检查代码，就能总结出好和不好来。货比三家，有些程序员也就跟着提高了，总写不好的代码，他不好意思。第四个，这人是后备军，以后公司假如有成长壮大的时候，这个人就是骨干人才。

就跟古代的皇帝有御林军一样，这个人也是自己的嫡系部队，要保证其绝对的忠诚，绝对的积极主动。而且对一个人来说，想要讨好所有人那是不可能的，可是想要讨好一个人，确是很容易的，只要你下了功夫，给予优厚待遇，可以保证这个人不要象其他人那样频繁流动，频繁跳槽，那么这个项目，这个公司，就稳固的多。

老板抠门也好，公司财务制度混乱也好，接项目青黄不接也好，诸多因素，会导致公司运营始终走不出作坊的境地，但是你却可以在自己的位置上，尽量做到最好，在软件方面，撑得住大局，一个小型的公司，能够持续运行，就是靠你，你保持的住，老板只要不是太愚蠢，会有重视你的一天。到那时，你在想办法整顿整顿其他的。