【双语】程序员——请学会交流

本贴最后更新于 2244 天前,其中的信息可能已经时异事殊

英文原文链接:https://henrikwarne.com/2017/05/28/developers-talk-to-people

Many software developers have a tendency to avoid talking to people. They would rather just rely on written communication in chats, email or issue tracker tickets. However, talking to people more can make them more effective as software developers. Here are some examples:

程序员大多都有同样的毛病就是不愿意与人交流,他们宁愿用通讯工具比如 email,提交工单也不远与人直接交流,但是在工作中主动与人交流会很大程度的提高我们的工作效率,下面举几个栗子来给大家解释一下:

Example 1. Suppose you are implementing a new feature. The ticket in the issue tracker describes how the new functionality should work. As you start working on it, you discover that implementing it exactly the way it is described will be difficult and take quite a bit of time. However, if the new feature it changed slightly, it fits right in with the existing code, so it would be possible to implement it much faster. At this point, many developers think to themselves: “they asked for the more complicated version, so that’s what I’ll implement”.

第一个栗子::假设你正在实现一个新的功能,需求文档里描述了该功能的内容,当你开始着手开发这个功能的时候,你发现这个功能非常的复杂而且会耗费你很长的时间。但是如果稍作修改,就可以重用之前的代码从而很快的完成这个功能,不过即使是如此,大多数程序员还是会认为:“他们可能是想让我开发一个更复杂的版本”。

Instead, talk to the product manager (or whoever requested the feature) and explain the trade-off you discovered (slightly changed feature would be much faster to implement). Ask if they still want it as originally described. The point isn’t that you should persuade them that the feature should be changed – the point is to let them know about the trade-off. Often they are not aware of it. Whether they change their mind or not, the discussion leads to better understanding for both of you.

相反,如果你去和你的项目经理(或者其他提出需求的人)讨论这个问题,让他们知道做这个简单的修改所带来的好处(可以更快的完成这个功能),问是否还是采用原来的设计,注意这里的重点不是让他们接受或者采纳你的想法,而是让他们知道这么做的好处,他们不会感到奇怪或者有什么不好的反应。不管最终他们是否采纳你的意见,这对你们双方进一步理解这个功能有很大的帮助。

Example 2. Recently, a tester was verifying some small changes I had made. He wrote down in the ticket the cases that worked, and some cases that didn’t work. The reason some cases didn’t work had to do with how I had deployed the new version of the software. I could have written down an explanation of that in the ticket. However, it takes time to explain something clearly in writing. So instead I walked over to him and explained what had happened. This way, he had the opportunity to ask more questions, and I had the opportunity to add more clarification without it ping-ponging back and forth as comments in the ticket.

第二个栗子: 最近一个测试人员给我提交了一些小的需要修改的问题,他描述了哪些功能可以正常执行,哪些功能不能。那些不能运行的功能是因为他不会去部署新的版本,我需要去告诉他怎么来部署,我完全可以写一个说明文档给他,但是我没有这么做,我直接跑去他面前跟他解释该如何去做,通过这种方式他有更多的机会问我更多的问题,我也不需要噼里啪啦的敲半天键盘来解释这件事了。

Even better, as we were talking about the ticket, I showed how I would check if the problem was due to the deployment or not. As I did that, he said “wait, what was that” – he had never used the command I used. So not only was the problem cleared up quickly, the tester learned a command he didn’t know about.

更赞的是,当我们在讨论这个问题时,我向他展示了我是怎么去检查并解决这个部署的问题的,当我展示时,他很好奇这个操作而且他从来没有接触过,所以除了解决了当前的问题,他还学会了以后再遇到这个问题该怎么去解决。

Example 3. The other day, I was going to add a feature that required knowing if another feature had been activated or not. The activation check had been a bit problematic before, so I wanted to clean it up a little in the process. So I thought about where to put the changed activation check. But before going ahead and implementing the solution, I mentioned to a colleague what I intended to do.

第三个栗子: 又有一天,我准备开发一个监控器去监控一个功能是否运行正常,之前的监控器有点问题,我准备在他的基础上去修改一下,替换一些新的代码进去,但在做这一切之前,我还是打算先去找同事讨论一下我的想法。

He immediately said “why don’t you put it there instead?”. Sure enough, his proposal was much better than mine – a better place to put it, and less impact overall on the code. So by just discussing for a few minutes, we found a better solution. I think of this as an informal design review, similar to a code review, but done before implementation, not after. I frequently try to discuss a change with a colleague before going ahead and doing it. Time and again I am grateful that I did. Many times we discover flaws, or better solutions, that I would never have thought of, no matter how hard I tried. So with a little bit of discussing, I end up with much better solutions.

我的同事立刻就回答我:“你为什么要替换这段代码?”果然,他有比我更好的思路,影响更少的代码。我跟他讨论了一会,得到了更好的解决方案。我想这就是_结对编程_(敏捷开发中的一种方式,我觉得这样翻译比较好接受,虽然可能不是很准确)的好处,就像一次代码回顾,但是是在代码实现之前进行的,不是之后。从那之后我每次要实现什么功能都要跟同事去进行讨论,慢慢的发现了其中巨大的好处,经常会发现一些缺陷,一些我根本想不到的更好的解决方案。不管我有多努力,一点点的讨论都能给我的工作带来很大的好处。

CONCLUSION

in a lot of cases, talking to developers, testers, product managers and other stake-holders is beneficial to both parties. It is usually also faster than written communication. Despite this, I see many developers that are a bit reluctant. If you are one of those developers, make an effort to talk more to people for a few weeks, and see if it makes a difference.

结论:

通过这些例子,不管是和程序员,测试人员,项目经理还是其他有关的人员进行交流和讨论,对双方都是有好处的,通常这种方式要比通讯软件效果要好的多。尽管如此还是有很多程序员不愿意去交流,如果你是这样的人,可以尝试几周,你会看到它给你的工作带来的变化。(注意这是在你没有影响其他人工作的前提之下哦,别人家正忙着呢去打扰别人,会引起反感)。

  • 职场

    找到自己的位置,萌新烦恼少。

    126 引用 • 1699 回帖
  • 双语
    2 引用

相关帖子

欢迎来到这里!

我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。

注册 关于
请输入回帖内容 ...

推荐标签 标签

  • Swift

    Swift 是苹果于 2014 年 WWDC(苹果开发者大会)发布的开发语言,可与 Objective-C 共同运行于 Mac OS 和 iOS 平台,用于搭建基于苹果平台的应用程序。

    34 引用 • 37 回帖 • 495 关注
  • 服务器

    服务器,也称伺服器,是提供计算服务的设备。由于服务器需要响应服务请求,并进行处理,因此一般来说服务器应具备承担服务并且保障服务的能力。

    124 引用 • 580 回帖
  • Git

    Git 是 Linux Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。

    204 引用 • 357 回帖 • 1 关注
  • Sublime

    Sublime Text 是一款可以用来写代码、写文章的文本编辑器。支持代码高亮、自动完成,还支持通过插件进行扩展。

    10 引用 • 5 回帖 • 1 关注
  • Angular

    AngularAngularJS 的新版本。

    26 引用 • 66 回帖 • 498 关注
  • 自由行
  • 京东

    京东是中国最大的自营式电商企业,2015 年第一季度在中国自营式 B2C 电商市场的占有率为 56.3%。2014 年 5 月,京东在美国纳斯达克证券交易所正式挂牌上市(股票代码:JD),是中国第一个成功赴美上市的大型综合型电商平台,与腾讯、百度等中国互联网巨头共同跻身全球前十大互联网公司排行榜。

    14 引用 • 102 回帖 • 406 关注
  • Ruby

    Ruby 是一种开源的面向对象程序设计的服务器端脚本语言,在 20 世纪 90 年代中期由日本的松本行弘(まつもとゆきひろ/Yukihiro Matsumoto)设计并开发。在 Ruby 社区,松本也被称为马茨(Matz)。

    7 引用 • 31 回帖 • 166 关注
  • SMTP

    SMTP(Simple Mail Transfer Protocol)即简单邮件传输协议,它是一组用于由源地址到目的地址传送邮件的规则,由它来控制信件的中转方式。SMTP 协议属于 TCP/IP 协议簇,它帮助每台计算机在发送或中转信件时找到下一个目的地。

    4 引用 • 18 回帖 • 581 关注
  • flomo

    flomo 是新一代 「卡片笔记」 ,专注在碎片化时代,促进你的记录,帮你积累更多知识资产。

    3 引用 • 74 回帖 • 3 关注
  • 安装

    你若安好,便是晴天。

    128 引用 • 1183 回帖
  • 外包

    有空闲时间是接外包好呢还是学习好呢?

    26 引用 • 232 回帖 • 17 关注
  • Hprose

    Hprose 是一款先进的轻量级、跨语言、跨平台、无侵入式、高性能动态远程对象调用引擎库。它不仅简单易用,而且功能强大。你无需专门学习,只需看上几眼,就能用它轻松构建分布式应用系统。

    9 引用 • 17 回帖 • 591 关注
  • MongoDB

    MongoDB(来自于英文单词“Humongous”,中文含义为“庞大”)是一个基于分布式文件存储的数据库,由 C++ 语言编写。旨在为应用提供可扩展的高性能数据存储解决方案。MongoDB 是一个介于关系数据库和非关系数据库之间的产品,是非关系数据库当中功能最丰富,最像关系数据库的。它支持的数据结构非常松散,是类似 JSON 的 BSON 格式,因此可以存储比较复杂的数据类型。

    90 引用 • 59 回帖 • 5 关注
  • Facebook

    Facebook 是一个联系朋友的社交工具。大家可以通过它和朋友、同事、同学以及周围的人保持互动交流,分享无限上传的图片,发布链接和视频,更可以增进对朋友的了解。

    4 引用 • 15 回帖 • 448 关注
  • webpack

    webpack 是一个用于前端开发的模块加载器和打包工具,它能把各种资源,例如 JS、CSS(less/sass)、图片等都作为模块来使用和处理。

    41 引用 • 130 回帖 • 294 关注
  • 小说

    小说是以刻画人物形象为中心,通过完整的故事情节和环境描写来反映社会生活的文学体裁。

    28 引用 • 108 回帖 • 3 关注
  • 周末

    星期六到星期天晚,实行五天工作制后,指每周的最后两天。再过几年可能就是三天了。

    14 引用 • 297 回帖
  • 链书

    链书(Chainbook)是 B3log 开源社区提供的区块链纸质书交易平台,通过 B3T 实现共享激励与价值链。可将你的闲置书籍上架到链书,我们共同构建这个全新的交易平台,让闲置书籍继续发挥它的价值。

    链书社

    链书目前已经下线,也许以后还有计划重制上线。

    14 引用 • 257 回帖 • 1 关注
  • Markdown

    Markdown 是一种轻量级标记语言,用户可使用纯文本编辑器来排版文档,最终通过 Markdown 引擎将文档转换为所需格式(比如 HTML、PDF 等)。

    163 引用 • 1446 回帖 • 1 关注
  • 面试

    面试造航母,上班拧螺丝。多面试,少加班。

    324 引用 • 1395 回帖
  • ZooKeeper

    ZooKeeper 是一个分布式的,开放源码的分布式应用程序协调服务,是 Google 的 Chubby 一个开源的实现,是 Hadoop 和 HBase 的重要组件。它是一个为分布式应用提供一致性服务的软件,提供的功能包括:配置维护、域名服务、分布式同步、组服务等。

    59 引用 • 29 回帖 • 18 关注
  • Postman

    Postman 是一款简单好用的 HTTP API 调试工具。

    4 引用 • 3 回帖
  • TGIF

    Thank God It's Friday! 感谢老天,总算到星期五啦!

    284 引用 • 4481 回帖 • 652 关注
  • 智能合约

    智能合约(Smart contract)是一种旨在以信息化方式传播、验证或执行合同的计算机协议。智能合约允许在没有第三方的情况下进行可信交易,这些交易可追踪且不可逆转。智能合约概念于 1994 年由 Nick Szabo 首次提出。

    1 引用 • 11 回帖 • 6 关注
  • jsDelivr

    jsDelivr 是一个开源的 CDN 服务,可为 npm 包、GitHub 仓库提供免费、快速并且可靠的全球 CDN 加速服务。

    5 引用 • 31 回帖 • 34 关注
  • OnlyOffice
    4 引用 • 19 关注