缘由
作为摸爬滚打了若干年的程序员，在交流开发经验的时候，都会讲到各种工程规范，小到变量命名、代码缩进的格式，大到团队的分工合作模式和系统架构的设计规范，而所参照的代码规范，都是些大公司的文档，比如东软编码规范，还有之前阿里发布的JAVA规范，无疑，对于入过无数坑的朋友来说，那些文档读来，都有一种相见很晚的感觉，并积极在自己的公司团队里推行。
然而，这里说然而，大多人所在的公司并不是BAT这种大公司，其中所遇到的坑和解决方案，很多时候，说实话（欲哭无泪），难以适用。没错，我说的，就是那些多如牛毛的小软件公司，那些作坊软件公司，当然，之所以写这样一个话题，并没有任何的不敬或者嘲笑之意，再大的公司即如BAT也是由作坊发展过来的，我们来看一看小公司的问题，聊一聊一些有趣的解决方案，权当是吐槽式总结吧。
作坊公司定义
先从人数来说吧，一般15个人以下的团队，就是属于典型的小团队了，事实上，很多公司，甚至只有几个开发人员，从需求到设计到编码到测试，甚至到客服，几乎都是人人从头负责到尾的，谈不上有什么分工，基本就是看谁空，活就扔给谁，在这样的小企业中，每个人往往大部分时间都是处于赶时间交任务的状态，对于思想工作者来说，还是挺痛苦的。那么，这样的小公司，是不是就是作坊公司呢，还不能说，它得满足这样一个条件：各自为战。若一个团队中的成员，往往都是各自为战的时候，那就是典型的作坊特征了，我们看几个故事吧（都是实事，不过当事公司和成员名字就不具体透露啦）
勤奋的Boss码农
成员数量：5
开发系统：宾馆酒店系统
某一天傍晚，BOSS主持会议，这个BOSS是技术出身，自学编程成才。BOSS宣布：我们要准备开发一套宾馆酒店系统，目前已经有了两个意向客户。闻之，大家都磨拳擦掌，这是个大系统呀，包含众多模块，看来要忙一阵了。思绪未完，BOSS直接亮出了一句语惊四座的话：呵呵，这个系统我已经写好了，VB写的，很容易。
话音未完，昏倒一片，有人问：“需求都没定义，就直接开发出来了？我们以前都没做过这方面的系统啊”。“不要紧，客户根本不懂软件，这些需求我想想就知道了”。“那有设计文档么，我们看一看”，“没有，不要文档，VB写的，很简单的”。好吧，牛逼的BOSS。
那就直接给客户去上系统呗，结果，人家说百分之八十的功能跟实际流程不一样，要想用起来，得改。说到这，兄弟们啊，程序猿有句话怎么说来着。“屎再多，自己拉的都好擦，最怕的是这种给别人擦屎的啊”。后果可想而知，一个没有注释，没有文档，完全按照自己意淫出的需求编写的系统，改起来是多么的费力。
即便如此，BOSS还是每天一大早在办公室兴致满满的等着，兴奋的告诉其他员工，他已经改好了某个函数（捂脸）。 BOSS在整个开发过程中，竟然都是自己亲力亲为，乃至于自己去码大部分的代码，直到发布自己的“成果”，都没有人参与进来，如此的勤奋，这是在开福利院呢？
很多作坊软件公司的老板都有技术背景，经常会在工作中代入这种工程师的角色，实际上对于项目的开发和团队积极性的发挥非常的不利，Boss应该要摆正自己的位置，不要去轻易干扰开发活动，CEO且是CTO的角色，那是留给少数天才的。
代码乱Copy
设计模式？工具库？控件库？呵呵，你真是太讲究了，我只管我的代码能跑起来，反正有现成的代码我就直接拷贝，于是，有了下面的故事。
小王：“发票管理模块有个问题，查出错日志是有个方法有问题，方法名是GetPartRouting”，真是奇怪，为什么发票中会有调用生产工艺的方法啊，没道理啊”
小张：“是不是发票中需要判断产品的工艺版本什么的，防止开错发票”
小王：“没道理啊，发票跟工艺有什么关系，打不着边啊，看这个代码，最后一次修改是你改的，不过没有修改备注，调试一下吧”
调试中……
小张：“知道原因了，GetPartRouting这个方法是取得物料信息的，直接从工艺模块里拷贝了这个方法，跟工艺也没关系，这个方法是工艺模块中的，所以命名就……”
小王：“……”
层次架构的设计，在作坊公司，不是设计出来的，是坑出来的，大家各自为战，完全靠自觉去封装一些函数库，类库。一般比较懒一些的，直接拷贝过来就拉倒了。时间一长，就导致代码中，功能近似的方法会有很多个，而很多人在拷贝的时候，连名字都不改，一旦发生问题，就......。再小的团队，最好也要有个层次分工，尽量不要各自为政，没有分工的概念，就不是团队了。
技术销售
呵呵，我这里当然不是指那种既熟悉技术又擅长销售的意思，而是指，将公司业务绩效横加在程序开发人员身上的做法。是不是有些不可思议？是的，很多作坊公司，在给技术人员开会的时候，讨论的不是技术问题，而是怎么去盈利，怎么去拉单，还美其名曰群策群力。敢问一句：如果一个技术人员在忙于写代码的时候还能搞市场，搞商务，把业务绩效提上去，那他在这里码什么代码？这是很多小软件公司的一个通病，总是会认为人不多，大家要同心协力，什么问题都一起担。No，公司与员工之间永远都只应该是合同关系，做什么就是做什么，况且，让技术人员掺和市场，能搞得好么？
这个其实还是一个分工的问题，但是我想说的是，工程师的管理应该要足够简单，不要参与销售，人再少，也要泾渭分明，让不合适的人去承担不合适的任务，既会容易把事情搞砸，也容易分散技术人员是精力。
盗版组件
腾讯开发的游戏中会有盗版组件么？百度开发的搜索引擎中会有可能带来法律风险的组件么？凡此等等，我相信，在大部分的小软件公司里，都是普遍存在这么一个问题的，需要什么功能，百度一搜，直接下载一个破解版。
有朋友会说，有破解版直接使用不是挺好的么，就算是给用户，多少人能搞得清这个是正版还是盗版。我想说的是，无论在何时都要保持产品的版权是健康的，要是零问题，这不仅会带来潜在的法律纠纷，也不利于产品的广泛推广。
代码库不统一
大约很多作坊公司，连源码版本管理都是不使用的，备份是靠移动硬盘，不同的版本用一个符号表示，见下面一个例子。
小杨：这里为什么有这么多的同名文件啊，名称基本都是一样的，第一个叫Print，第二个叫Print2，第三个叫Print2new，第四个叫PrintNewNew，第五个叫Print3New。
小王：我也不知道，可能有用吧，看看哪个是最新的文件，应该都是同一个功能文件，那个print3New可能是最新的吧。
小杨：我看了，也不是啊，主代码里调用的是PrintNewNew，我也搞不清了
软件开发过程中的文件版本管理，在很多小团队中，几乎就是没概念的，代码库的管理，代码版本的管理，要么就是安排那么一个人手里掌握有的最新版代码，要么就是不断的起新名字，移动硬盘拷，实际上，码代码够累的了，还要去面对那么多考验语文水平的代码文件名，这是典型的自己给自己挖坑。
不止是为了吐槽
说到这里，也聊了不少，这样的例子是很多的，但我们并不打算只是在这里吐槽，我们也知道，一个企业，一个团队要发展起来，是很不容易的，吐槽容易做事难， 其实对于作坊软件企业来说，选择在一开始的时候就规范化书最好的，初期发展不容易，再给自己挖些坑，等于是自己打游戏，故意选择困难模式。游戏可以这样去体验，团队发展最好不要这样。对于小公司来说，最合适的做法，其实就是下面四个字：严格分工。
严格分工
说一千道一万，就做好这四个字是最要紧的，分工，严格的分工，千万不要因为人少就互相糅合在一起，什么事都是大家一起上，分工才能让一个人负责到底，专业到底。