程序员不应该就是专职敲代码的吗

[From 程序员秘书](https://mp.weixin.qq.com/s/_PqYyky7nMLT6ALGGvYfOg)

# 程序员不仅有代码，还有和产品经理、测试人员之间的“爱恨情仇”

 

#有关程序员的一个段子

网上看到的，分享一下：

当你看到一个程序员的两只手在键盘上，上下翻飞，行云流水的时候，多半不是在敲击代码，

大概率是在跟产品经理sibi讨论需求，

另一种可能就是在跟测试打口水仗，

10%几率是在论坛码字摸鱼，

可以手速飞快而不需要停下思考的代码，多半也可以靠Ctrl + C/V 搞定。

而当你看到程序员双目呆滞，遥望天际的时候，多半编程开始了。

对于已经参加工作的人看到这个段子，可能会觉得调侃之中有几份贴切；但对于没有参加工作的人，可能会有一丝疑惑，“咦？程序员不应该就是专职敲代码的吗”

 

[From 程序员秘书](https://mp.weixin.qq.com/s/_PqYyky7nMLT6ALGGvYfOg)

# 谈谈我的感想和经验

 

针对上述段子提到的观点挨个谈一下：

 

1. 跟产品经理sibi讨论需求

首先需要知道一个真相：当我们自主学习时，可以是以兴趣为导向的，想怎么学怎么code是自己的事情；但是当工作时，一定是以公司的产品最终功能需求为导向的。注意“最终”二字，产品具体需求可能来自市场的调研、产品经理或团队的创意idea，总之需求可能是随着市场、idea不断在变的，映射到开发人员身上，那就可能是不同的代码架构、不同的业务逻辑、不同的Code工作量。

关于sibi大概有以下几种情况：

• 需求变更频繁，导致程序员反复修改，工作量不断增加(程序员心想能不能不挤牙膏)，理论理论；

• 前面提的需求，都要基本完成了，突然一个消息，这个需求不这样做了，彻底改头换面了，但是项目进度还是原来的进度(程序员心想又要加班重新实现了，能不能不这么善变，敢不敢提前两月确定需求)，理论理论；

• 产品经理提的需求，站在程序员的角度看，需求本身可能对于产品(用户)实际意义不大，而且从技术上看实现成本又很高(开发周期长、涉及代码修改和沟通领域多，单元测试路径覆盖困难、后续维护成本也大)，拉着软件经理，一起理论理论；

• 产品经理idea，天马行空，软件或者硬件层面根本无法支撑实现；

• 产品经理需求不明确，或程序员思考深度不够，必须要互相掰扯才能你清我楚;

• . 产品MM太漂亮，pk pk认识一下(程序员的怪思维)；

• ...……

总结：会产生矛盾的点，可能是产品经理只关注卖点、一味的突出亮点而缺少可行性和实用性、而开发人员主要站在代码角度思考需求可行性，以及会轻量级从用户角度出发思考实用性；还有项目层面还思考整体工作量和开发周期的一个匹配情况。一款好的产品，可能需要天时地利人和，开发周期容许的情况下，必须是产品经理和开发深度参与讨论、掰扯、打磨以后才会有的，而这些需要公司层面合理的沟通流程和机制来保证才行，不然需求和开发之间可能混乱不堪，尤其针对需要快速迭代的互联网产品。

 

2.跟测试打口水仗

我们知道测试一般分为硬件测试 和 软件测试，硬件测试主要cover硬件参数、状态、平时交涉的主要是硬件开发和底层驱动软件开发人员；软件测试主要cover软件版本各功能点(含产品经理的需求)，交涉的主要是所有软件开发人员。

所以关于争论，大概有以下几种情况：

• 测试人员提了问题，开发分析为手法问题，测试认为手法没问题；必须要理论出一个所以然，不能打了自己脸；

• 再复杂一点的情况，比如硬件指标测试，测试人员提了问题，软件分析是硬件问题，硬件分析是硬件层面ok没问题，怀疑要么软件驱动配置问题，要么测试手法问题；测试人员认为测试手法没问题；于是硬件、软件、测试一起参与到了一场理论当中；

• 开发认为测试提的问题，属于没问题找问题型，不合理，客户/用户手里几乎不可能出现的操作路径；但是测试认为存在就是问题；

• 测试认为开发很多情况下欠缺考虑测试人员的感受，很多功能连测都不测就扔给过来了，但开发认为，开发任务这么多，啥功能我都测了，那还要测试人员干什么；互相理论，有必要时，可能拉软件经理、测试经理加入；

• 最差的情况，互相对接的bug太多，很多交流，沟通不顺畅，产生了“敌对思想”，一交流bug，就感觉是互相找茬一样；

• ……

总结：开发人员这个角色其实既生产代码，也生产Bug，世界上可能就没有 没有bug的软件，作为开发人员应该更多的换位思考，结合自己开发的功能，代码流程，给出测试人员合理的测试意见；测试人员针对一个功能点的测试，可以更多的向开发人员发起评审，合理采纳意见。

测试的目的其实是为了验证软件缺陷，测试人员作为不懂代码的人，测试功能时，其实更贴切于实际用户角度，而开发人员分析问题时可能更倾向基于软件流程和代码解析问题，所以就会有信息差。建议开发人员一定要静下心来倾听测试人员的心声，一个专业的测试人员可能带给开发人员不同角度看问题的感受，那应该被视为一种“收获”。反过来，试想一下，如果整个项目软件一个bug都没有，那是不意味着，测试人员是不是就可以失业了？测试和开发之间，需要多一份换位思考，多一份理解。

[From 程序员秘书](https://mp.weixin.qq.com/s/_PqYyky7nMLT6ALGGvYfOg)

3. 论坛码字摸鱼

公司内网、外网，论坛，必不可少，论坛不仅仅是放松、灌水的地方，也是讨论人生疑惑、探讨技术问题的地方，程序员必备。

 

4. 靠Ctrl + C/V

我觉得应该主要有以下几种情况：

• 很多时候，一个公司在完成一个项目A后，结合市场情况，很可能改改外观，个别器件，立马又是一个新的项目B成立了，在项目A时已经有了很多开发过的代码，那这个时候我们针对新项目B，要做的工作就是移植以前的项目A的可用代码，靠的就是Ctrl + C/V；

• 平时开发工作或者学习过程一定要注重个人代码的积累；比如你自己手头已经有以前写的一套完整的链表的插入，删除，排序代码，刚好有一个需求实现要用到这些，那就完全可以直接使用了，Ctrl + C/V，不需要重复造轮子；新使用的过程，也属于对自己积累代码库的不断验收和完善；

• 别人优秀的，已经实现的代码，直接Ctrl + C/V使用。这个前提是要自己一定先搞懂，学习和吸收了，不然后续一旦出了问题，挖了坑，都不知道怎么填。“拿来主义”并没有什么不好，站在前人的肩膀上我们才能看的更远；

• …..

总结：高效完成工作，Ctrl + C/V的同时，不忘自我积累。

 

5. 双目呆滞，遥望天际

编码前的深度思考时间，建议提前准备个牌子 “请勿打扰！”，拒绝产品经理[可选项：产品MM]、测试人员，等等，一切干扰。

 

PS.End：我自己从一个开发人员角度出发，要感谢认真细致、耐心负责的测试人员，正是这样，才让开发人员可以发现自己写的bug并有机会提升自己。emmmm，也要感谢产品经理让我们挑战了一个又一个不可能。

[From 程序员秘书](https://mp.weixin.qq.com/s/_PqYyky7nMLT6ALGGvYfOg)

欢迎关注 和 加好友，交流。

<完>