多面手程序员

先来看看这样的场景：

• “没有美工做的高保真页面，我怎么来开发呢？我没有审美，也不会用PS作图啊。”
• “正交测试这种技巧，是测试工程师应该掌握的，开发不需要了解。”
• “目前进度的瓶颈在产品经理那里，他还没有给我澄清需求。难道要一个写代码的去给客户整理需求么？”
• “我是C++程序员，我是做底层开发的啊，这种页面样式的问题我怎么可能懂？”
• “这是维优人员关注的线上数据，他应该把日志、错误现象全部备齐了再提交问题给开发。”
• “这是他的模块，把问题提给他来处理。”
• ……

这些是我下面要反驳的一些做法，你有没有中枪的？

事实上，我已经在很多篇文章里（比如这篇文章）阐述了这样的观点：程序员要多能。很多情况下，优秀的程序员一个人就可以搞定一切。

但是如果我直接把我的观点扔上来，可能不会遭到很多的质疑。我们的教育一直都讲究“做一行，爱一行”，明确哪些事是自己应该管的，哪些事是别人的，切勿指手画脚。因此，即便有的人暂时赞同了我的看法，却只似雁过留痕而已，在实际学习工作中，依然不容易扭转这样的观念。

所以我摆出这样的几个场景，有异议、有争论是好事。

程序员替代不了美工吗？

有人反驳我，说：“如果程序员可以替代美工，可以替代UI设计师，那还要专门设置这些职位干什么？”

说得好。程序员当然可以做美工的工作，但是程序员不能取代他们，这里至少有两个原因：

1. 多数程序员并不具备美工的专业技巧和丰富的UI经验，换言之，无法如他们那样精通界面设计；
2. 出色的美工需要有非常优秀的审美，这需要审美天赋，也是大多数程序员不具备的。

但是——

• 程序员可以用PS切图吗？可以。
• 程序员可以设计CSS和HTML界面吗？可以。
• 程序员可以设计UI吗？当然可以，而且往往清晰、简洁，组件复用性好。

美工，只是一个特例而已。你可以把它套到各种相关工种名称上，比如测试。有这样一篇文章《我们需要专职的QA吗？》，答案当然可以不是非黑即白的，可这需要放下成见，我想，你会有自己的思考。

请不要忽视工具的威力

工具的威力有多大？想想Bootstrap，可以让一个对CSS和JavaScript只是略懂的人，就可以做出非常简洁美观的界面来；再比如这篇文章，谁说程序员不能做运维？当工具足够强大，运维并没有那么困难。

在工具降低重复劳动和降低门槛的时候，真正精通的专家都去开发工具了。正所谓“授之以鱼，不如授之以渔”，但这句话有个特例，如果对方是程序员，那么这两者都不用，还是给他开发一个自动捕鱼工具吧。

小团队和简单流程

小团队也好，简单流程也好，就是要让沟通成本尽可能小，容易保持对话交流这种高效的方式。在享受这样的好处的时候，“专才”可以吸引你的眼球，但是“通才”却是一个必不可少的要求。

对一支创业团队来说尤为如此。小团队让一个创意可以快速得到实施，但是你没有太多钱和精力，谁负责宣传？谁负责约见客户？谁负责上线？谁负责响应投诉？……你需要多面手而不是技能单一的专家。

一专多能

多面手并不阻碍你成为某一领域的专家。深度和广度往往是相伴而行的，很难想象一名优秀的DBA不懂操作系统底层的知识；也不可能见到出色的“前端工程师”却只会写JavaScript客户端脚本语言。毕竟问题不可能非常单纯，总是牵一发而动全身的，唯有了解的东西多了，才能够去更好地认识自己最擅长和熟知的领域。

事实上，一专多能已经成为了潮流。在足球领域，现代足球的发展造就了多样化的角色，为这些角色使用了独立的词语，以前锋为例，就有Poacher（抢点型）、Trequartista（9号半）和Target Man（站桩中锋）等等。

多走一步

我的同事在定位问题的时候，如果发现不是我们自己的问题，而是别的产品引发的问题（由别的团队维护），都已经形成这样的习惯：尝试花少量的代价去定位一下问题的所在。这其中，我们经常会去阅读对方的产品的代码。有人觉得不可思议，你去读别的产品的代码？其实听起来恐怖，可多数情况下做起来却没有那么困难。至少，你可以把你的调查分析结果给目标团队，了解别的产品和阅读别的产品的代码，对于扩大视野还是有助益的。

在模块划分上亦如此，不要把模块的责任划分得那么清晰，谁都有查看、修改代码的权利和义务。

多走一步还表现在团队中非设计编码的其它事务上，程序员应当尝试做各种各样的事情。比如招聘——招来的人是要和你每天在一起工作的好伙伴、好基友，这是事关你切身利益的大事，如果让别人去决定你的团队要安插什么样的人，这谈何合理呢？

有的人甚爱搞科研，这些人叫做研究员、科学家；有的人擅长做工程，这些人才是工程师。做工程就是要解决实际的问题，于是你不可避免地接触到形形色色的领域和现象。SDE不只是Software Development Engineer，同时更是Someone Do Everything。

文章系本人原创，转载请注明作者和出处（http://www.raychase.net）

注：本博客已经迁移到个人站点 http://www.raychase.net/ ，欢迎大家访问收藏，本ITEye博客在数日后将不再更新。

评论

19 楼 su1216 2013-01-03  

RayChase 写道

su1216 写道

1.切图
这个可能离大家比较近一些，所以争议可能小一些，只是切图也好
但是阴影效果怎么做，图片切换的色彩搭配谁来做，.9文件的各种padding谁来定义
当然，程序猿在一定程度上可以克服，勉强同意
2.CSS+HTML
可能楼主是针对web开发
我是做android的，你让我为了一个CSS样式去学3天CSS，然后再花7天时间适配各种浏览器，最关键的是，下次再用CSS的时候是两年后，之前的时间完全浪费了。不如找个专职人员去做这些，省时省力
3.程序猿设计UI
我觉得设计UE还行，设计UI总得有些艺术细胞吧
虽然不要求是艺术学院毕业，但是总得有些审美
垃圾UI咱们已经见了不少了，如果是自己的应用，那可以自己来，否则。。。如果我是老大，我估计我不放心

还有陈浩关于测试的那篇文章
很早之前就看过，测试不是开发，他们对产品的理解可能不那么深刻。可是最终用户就像他们一样，在一定程度上，他们可以代表最终用户。何况我们的测试还会为开发考虑，实际用户呢？
我们做android的，到项目中后期经常需要场测，难道让程序猿今天飞印度，明天飞巴西吗
这得多高的成本，一个项目飞出去30人，10个项目公司就没人了。。。
再说成天坐车抓log，做着和开发几乎完全无关的事情，开发人员很痛苦。公司更痛苦，因为开发工资相对较高
不说场测，说monkey，说cts，说memory leak，说performance……
开发如果这些都管，那我想他自己也不好意思管自己叫开发了

我觉得你说的有点意思。不过，提醒的你的是，运维也好、客户洽谈也好，并不一定要程序员本身“在场”，就像你说的，今天飞印度、明天飞巴西，这是不合理的。足够强大的工具可以减缓或者解决这样的问题。这是有实际例子的。
另外，我觉得程序员懂一些monkey测试、cts测试是好的加分项，至于performance和mem leak，则是必须要掌握的吧。你说的开发还是什么别的名称，并不重要。

之前你是不是误会，我说的各个国家跑，是场测需要，和业务洽谈什么没有关系
是使用当地运营商提供的网络进行测试
比如打电话、短彩信、上网、流媒体测试等

还有mem leak
我们现在很少自己写新的应用，都是移植、优化。拿到别人的应用，那么多代码，我想一般不太可能拿过来就手动点击俩小时来找mem leak。mem leak大多都是monkey测试测出来的。或者专门的脚本跑出来的。代码太多，我们也没有办法

18 楼 su1216 2013-01-03  

RayChase 写道

su1216 写道

1.切图
这个可能离大家比较近一些，所以争议可能小一些，只是切图也好
但是阴影效果怎么做，图片切换的色彩搭配谁来做，.9文件的各种padding谁来定义
当然，程序猿在一定程度上可以克服，勉强同意
2.CSS+HTML
可能楼主是针对web开发
我是做android的，你让我为了一个CSS样式去学3天CSS，然后再花7天时间适配各种浏览器，最关键的是，下次再用CSS的时候是两年后，之前的时间完全浪费了。不如找个专职人员去做这些，省时省力
3.程序猿设计UI
我觉得设计UE还行，设计UI总得有些艺术细胞吧
虽然不要求是艺术学院毕业，但是总得有些审美
垃圾UI咱们已经见了不少了，如果是自己的应用，那可以自己来，否则。。。如果我是老大，我估计我不放心

还有陈浩关于测试的那篇文章
很早之前就看过，测试不是开发，他们对产品的理解可能不那么深刻。可是最终用户就像他们一样，在一定程度上，他们可以代表最终用户。何况我们的测试还会为开发考虑，实际用户呢？
我们做android的，到项目中后期经常需要场测，难道让程序猿今天飞印度，明天飞巴西吗
这得多高的成本，一个项目飞出去30人，10个项目公司就没人了。。。
再说成天坐车抓log，做着和开发几乎完全无关的事情，开发人员很痛苦。公司更痛苦，因为开发工资相对较高
不说场测，说monkey，说cts，说memory leak，说performance……
开发如果这些都管，那我想他自己也不好意思管自己叫开发了

我觉得你说的有点意思。不过，提醒的你的是，运维也好、客户洽谈也好，并不一定要程序员本身“在场”，就像你说的，今天飞印度、明天飞巴西，这是不合理的。足够强大的工具可以减缓或者解决这样的问题。这是有实际例子的。
另外，我觉得程序员懂一些monkey测试、cts测试是好的加分项，至于performance和mem leak，则是必须要掌握的吧。你说的开发还是什么别的名称，并不重要。

程序猿是都懂一些
但是根本没有那精力
至于场测，根本不可能每个国家的跑
performance说实话也没时间，客户给了一个对比机，我们不可能把所有操作都录下来，然后分析相差时间。客户经常因为相差0.2、0.3秒而不满

17 楼 RayChase 2013-01-03  

BUYAOZAIBEIDAOLE 写道

其实在我看来作者想要阐明的观点是程序员应该在日常中更加深入的查看工作当中的问题
这样不仅对自己有帮助还可以得到提升

这不是我的观点。

16 楼 RayChase 2013-01-03  

su1216 写道

1.切图
这个可能离大家比较近一些，所以争议可能小一些，只是切图也好
但是阴影效果怎么做，图片切换的色彩搭配谁来做，.9文件的各种padding谁来定义
当然，程序猿在一定程度上可以克服，勉强同意
2.CSS+HTML
可能楼主是针对web开发
我是做android的，你让我为了一个CSS样式去学3天CSS，然后再花7天时间适配各种浏览器，最关键的是，下次再用CSS的时候是两年后，之前的时间完全浪费了。不如找个专职人员去做这些，省时省力
3.程序猿设计UI
我觉得设计UE还行，设计UI总得有些艺术细胞吧
虽然不要求是艺术学院毕业，但是总得有些审美
垃圾UI咱们已经见了不少了，如果是自己的应用，那可以自己来，否则。。。如果我是老大，我估计我不放心

还有陈浩关于测试的那篇文章
很早之前就看过，测试不是开发，他们对产品的理解可能不那么深刻。可是最终用户就像他们一样，在一定程度上，他们可以代表最终用户。何况我们的测试还会为开发考虑，实际用户呢？
我们做android的，到项目中后期经常需要场测，难道让程序猿今天飞印度，明天飞巴西吗
这得多高的成本，一个项目飞出去30人，10个项目公司就没人了。。。
再说成天坐车抓log，做着和开发几乎完全无关的事情，开发人员很痛苦。公司更痛苦，因为开发工资相对较高
不说场测，说monkey，说cts，说memory leak，说performance……
开发如果这些都管，那我想他自己也不好意思管自己叫开发了

我觉得你说的有点意思。不过，提醒的你的是，运维也好、客户洽谈也好，并不一定要程序员本身“在场”，就像你说的，今天飞印度、明天飞巴西，这是不合理的。足够强大的工具可以减缓或者解决这样的问题。这是有实际例子的。
另外，我觉得程序员懂一些monkey测试、cts测试是好的加分项，至于performance和mem leak，则是必须要掌握的吧。你说的开发还是什么别的名称，并不重要。

15 楼 RayChase 2013-01-03  

runfriends 写道

你说的不是程序员，是万金油。
全靠程序员顶着，只能说这不是成熟和专业的团队。
对个人职业生涯不利，让程序员没有专业努力的方向，各方面都懂一点，各方面都不精。
这样的团队永远只能是小作坊，不会有大前途。

除非能有彻底的改变。

当然作为搞技术的，为扩大知识面和为技术水平找到发展方向，或更好的服务于公司业务，去了解ue、去做测试、去探索用户体验都完全可行，但是应该把更多精力放在自身技术实力的提高、对公司业务的掌握，以及对行业动态的了解上面。

将来你作为一个程序员的价值不在于你会多少工具，懂多少测试工作，会不会切图；如果只把目光聚焦在这些上面，永远只能是一个低级的程序员。

我觉得你有一点误解。我没有否定程序员最重要的事情是什么。多面手并不代表没有专精的领域。

14 楼 richie144 2013-01-01  

严重支持13楼的观点，

鄙视LZ

13 楼 runfriends 2012-12-31  

你说的不是程序员，是万金油。
全靠程序员顶着，只能说这不是成熟和专业的团队。
对个人职业生涯不利，让程序员没有专业努力的方向，各方面都懂一点，各方面都不精。
这样的团队永远只能是小作坊，不会有大前途。

除非能有彻底的改变。

当然作为搞技术的，为扩大知识面和为技术水平找到发展方向，或更好的服务于公司业务，去了解ue、去做测试、去探索用户体验都完全可行，但是应该把更多精力放在自身技术实力的提高、对公司业务的掌握，以及对行业动态的了解上面。

将来你作为一个程序员的价值不在于你会多少工具，懂多少测试工作，会不会切图；如果只把目光聚焦在这些上面，永远只能是一个低级的程序员。

12 楼 su1216 2012-12-31  

RayChase 写道

witcheryne 写道

if(i!=我){} 写道

程序员可以是多面手，但公司永远不要拿程序员当多面手。

让一个人干多件事情，对谁都没好处。

我觉得程序员就应该干多面手, UE, 产品, 设计, 研发, 测试, 发布, 维护, 都需要做. 虽然公司在这方面都有专职人员, 但是我都有在做.

程序员是真正能够创造出价值的角色. 
UE, 产品, 设计 + 没有实现 = 亏本
没有实现 + 测试, 实施, 运维 = 没活干

没有程序员参与的产品设计: 能否实现, 工作量大小等都是问题, 如果不参与也可以, 加班这种**事情就很容易发生.

程序员不参与测试, 实施, 维护, 就不能知道自己的实现有多烂, 给别人造成了多少麻烦. 在处理这些麻烦的时候, 反观设计,实现.

以上这些观点不代表程序员一个人能代替其他专职人员, 我只是觉得程序员作为一个最终创造东西的人, 应该参与整个创造过程.

说得真好。这也是我的想法。

我觉得你们似乎说的不是一个事情
首先说楼主的观点

引用

    程序员可以用PS切图吗？可以。
    程序员可以设计CSS和HTML界面吗？可以。
    程序员可以设计UI吗？当然可以，而且往往清晰、简洁，组件复用性好。

这里说的太模糊了
1.切图
这个可能离大家比较近一些，所以争议可能小一些，只是切图也好
但是阴影效果怎么做，图片切换的色彩搭配谁来做，.9文件的各种padding谁来定义
当然，程序猿在一定程度上可以克服，勉强同意
2.CSS+HTML
可能楼主是针对web开发
我是做android的，你让我为了一个CSS样式去学3天CSS，然后再花7天时间适配各种浏览器，最关键的是，下次再用CSS的时候是两年后，之前的时间完全浪费了。不如找个专职人员去做这些，省时省力
3.程序猿设计UI
我觉得设计UE还行，设计UI总得有些艺术细胞吧
虽然不要求是艺术学院毕业，但是总得有些审美
垃圾UI咱们已经见了不少了，如果是自己的应用，那可以自己来，否则。。。如果我是老大，我估计我不放心

还有陈浩关于测试的那篇文章
很早之前就看过，测试不是开发，他们对产品的理解可能不那么深刻。可是最终用户就像他们一样，在一定程度上，他们可以代表最终用户。何况我们的测试还会为开发考虑，实际用户呢？
我们做android的，到项目中后期经常需要场测，难道让程序猿今天飞印度，明天飞巴西吗
这得多高的成本，一个项目飞出去30人，10个项目公司就没人了。。。
再说成天坐车抓log，做着和开发几乎完全无关的事情，开发人员很痛苦。公司更痛苦，因为开发工资相对较高
不说场测，说monkey，说cts，说memory leak，说performance……
开发如果这些都管，那我想他自己也不好意思管自己叫开发了

11 楼 allloveend 2012-12-31  

一个人的钱干10个人的活，老板当然开心了，问题是术业有专精，我一个入世未深的小程序员你就让我又P图又CSS+HTML5+各种各样的事情，恐怕压力不是这么好处理的，结果就是走人，然后就是这样死循环下去。

10 楼 jinnianshilongnian 2012-12-31  

witcheryne 写道

if(i!=我){} 写道

程序员可以是多面手，但公司永远不要拿程序员当多面手。

让一个人干多件事情，对谁都没好处。

我觉得程序员就应该干多面手, UE, 产品, 设计, 研发, 测试, 发布, 维护, 都需要做. 虽然公司在这方面都有专职人员, 但是我都有在做.

程序员是真正能够创造出价值的角色. 
UE, 产品, 设计 + 没有实现 = 亏本
没有实现 + 测试, 实施, 运维 = 没活干

没有程序员参与的产品设计: 能否实现, 工作量大小等都是问题, 如果不参与也可以, 加班这种**事情就很容易发生.

程序员不参与测试, 实施, 维护, 就不能知道自己的实现有多烂, 给别人造成了多少麻烦. 在处理这些麻烦的时候, 反观设计,实现.

以上这些观点不代表程序员一个人能代替其他专职人员, 我只是觉得程序员作为一个最终创造东西的人, 应该参与整个创造过程.

同意。

缩短从构思--->实现的时间；因为大家都参与，其实这减少了不必要的沟通成本，程序员在看到需求/讨论需求时应该就考虑怎么去实现，有问题可以立即反馈，要不天天找产品。

正如写测试能缩短发现问题---->解决问题的时间一样，我觉得做工程 应本着 简单+极速反馈。

还有再吐个槽：大家公司舍得给配置个好机器吗？

9 楼 小斌勿语 2012-12-31  

witcheryne 写道

if(i!=我){} 写道

程序员可以是多面手，但公司永远不要拿程序员当多面手。

让一个人干多件事情，对谁都没好处。

我觉得程序员就应该干多面手, UE, 产品, 设计, 研发, 测试, 发布, 维护, 都需要做. 虽然公司在这方面都有专职人员, 但是我都有在做.

程序员是真正能够创造出价值的角色. 
UE, 产品, 设计 + 没有实现 = 亏本
没有实现 + 测试, 实施, 运维 = 没活干

没有程序员参与的产品设计: 能否实现, 工作量大小等都是问题, 如果不参与也可以, 加班这种**事情就很容易发生.

程序员不参与测试, 实施, 维护, 就不能知道自己的实现有多烂, 给别人造成了多少麻烦. 在处理这些麻烦的时候, 反观设计,实现.

以上这些观点不代表程序员一个人能代替其他专职人员, 我只是觉得程序员作为一个最终创造东西的人, 应该参与整个创造过程.

我很同意你的观点，程序员就应该在前期需求调研，详细设计和后期都在一线，不然别人传达给的东西永远不是自己想要的东西，越弄越乱

8 楼 RayChase 2012-12-31  

witcheryne 写道

if(i!=我){} 写道

程序员可以是多面手，但公司永远不要拿程序员当多面手。

让一个人干多件事情，对谁都没好处。

我觉得程序员就应该干多面手, UE, 产品, 设计, 研发, 测试, 发布, 维护, 都需要做. 虽然公司在这方面都有专职人员, 但是我都有在做.

程序员是真正能够创造出价值的角色. 
UE, 产品, 设计 + 没有实现 = 亏本
没有实现 + 测试, 实施, 运维 = 没活干

没有程序员参与的产品设计: 能否实现, 工作量大小等都是问题, 如果不参与也可以, 加班这种**事情就很容易发生.

程序员不参与测试, 实施, 维护, 就不能知道自己的实现有多烂, 给别人造成了多少麻烦. 在处理这些麻烦的时候, 反观设计,实现.

以上这些观点不代表程序员一个人能代替其他专职人员, 我只是觉得程序员作为一个最终创造东西的人, 应该参与整个创造过程.

说得真好。这也是我的想法。

7 楼 alyouge 2012-12-31  

我就是一个多面手，感觉有些地方就是自己做起来有点费力，页面还是专业的美工，或者UI设计师比较好！

6 楼 witcheryne 2012-12-31  

if(i!=我){} 写道

程序员可以是多面手，但公司永远不要拿程序员当多面手。

让一个人干多件事情，对谁都没好处。

我觉得程序员就应该干多面手, UE, 产品, 设计, 研发, 测试, 发布, 维护, 都需要做. 虽然公司在这方面都有专职人员, 但是我都有在做.

程序员是真正能够创造出价值的角色. 
UE, 产品, 设计 + 没有实现 = 亏本
没有实现 + 测试, 实施, 运维 = 没活干

没有程序员参与的产品设计: 能否实现, 工作量大小等都是问题, 如果不参与也可以, 加班这种**事情就很容易发生.

程序员不参与测试, 实施, 维护, 就不能知道自己的实现有多烂, 给别人造成了多少麻烦. 在处理这些麻烦的时候, 反观设计,实现.

以上这些观点不代表程序员一个人能代替其他专职人员, 我只是觉得程序员作为一个最终创造东西的人, 应该参与整个创造过程.

5 楼 BUYAOZAIBEIDAOLE 2012-12-31  

其实在我看来作者想要阐明的观点是程序员应该在日常中更加深入的查看工作当中的问题
这样不仅对自己有帮助还可以得到提升

4 楼 jinnianshilongnian 2012-12-31  

if(i!=我){} 写道

程序员可以是多面手，但公司永远不要拿程序员当多面手。

让一个人干多件事情，对谁都没好处。

当然还是专业的人做专业的事。一个人做很多的事，不说全部，反正在我可视范围内没遇到过做的很好的。毕竟大部分人都是普通人。

我就是一个多面手，所以我深深知道它的痛。但我认为多面手不是让这个人做多件事，我们应该情况了解自己的角色，相互互补，而且也知道其他岗位的不容易，相互协作开发好产品。

3 楼 jinnianshilongnian 2012-12-31  

if(i!=我){} 写道

程序员可以是多面手，但公司永远不要拿程序员当多面手。

让一个人干多件事情，对谁都没好处。

为什么没好处？我一个产品朋友在公司做产品设计，天天程序员说实现不了（你说这样咋搞）？天天吵着我说“不行，我得学技术”，不是实现不了，是惰性。

我认为“可以不干这件事，但得了解这件事”，这样沟通起来起码有点相关领域的知识。还有在小团队中，这样能提高效率，公司就应该拆正几个人的小团队，快为主。天天扯蛋，这样的生活值得拥有吗？

2 楼 if(i!=我){} 2012-12-31  

程序员可以是多面手，但公司永远不要拿程序员当多面手。

让一个人干多件事情，对谁都没好处。

1 楼 jinnianshilongnian 2012-12-31  

我的观点跟你一样；公司更多的是需要工程师；每个人都有自己的一个主要职责，了解其他职责便于更好的沟通；

比如我在之前的公司了解产品相关知识，技术是实现产品的手段，如果产品做不好，肯定没用户，所以我觉得每个做技术的程序员都应该了解点产品知识，比如《Don`t make me think》这本初级的入门书，还有像《web表单设计:创建高可用性的网页表单》 我们天天设计表单，但不知道有多少个本着用户为主设计的？

美工/前端：我觉得像css精灵、css/js压缩、html解耦/分离，还有一些性能相关的知识了解下就可以了；像《写给大家看的设计书(第3版)》指导如何设计网页，我觉得也很不错；

最重要的还是意识问题，了解其他方面的知识可以更好的沟通，而且也是互补的。《高性能网站建设指南》 《高性能网站建设进阶指南：WEB开发者性能优化最佳实践》 这两本书想必大家都看过了。

还有比如SEO的知识等等，了解下即可。

公司更多的是需要工程师为他们创造价值，我觉得每个程序员都应该有这个意识；了解其他方面的知识，可以更好的沟通。