一年内每天向开源贡献代码所发生的事情

本文是翻译,版权归原作者所有

最近我在GitHub连续冲刺了365天,我想写篇博客,记录下为什么开始每天提交,以及它对我的生活带来了什么变化。

github提交图表

我对贡献代码的要求比较简单:

  • 每次贡献必须有意义,必须有实际影响。我可以提交只有空格的修复,但是它们不应该被算作有影响的提交。
  • 它必须是开源的。

早在2013年夏天我就开始了,略早于John Resig,他写了关于每天提交代码的博客,但是我的第一次尝试失败了。正是他的文章鼓舞了我,告诉我不是一个人在战斗。

我和John有着同样的理由:我热爱业余项目(side project),但是我不乐意为了完成它们而投入整个周末。有时候,我在周末投入一整夜,但是这帮助不大:去做业余项目的时间跨度太大了,我经常想不起来在做什么以及项目的下一个想法是什么。我总要用很长时间才能重新回到项目上。另外,我不想在周末的两天里完全忙于业余项目,因为我想花些时间和朋友在一起,以缓解一直坐在电脑前面的紧张状况。

我开始每天贡献代码的其它原因是,我认为这很可能将提高我的技能。

好的方面

改善我的业余时间管理

我的业余时间整个计划发生了变化。往好了讲,我开始计划和管理我的业余时间了。在此之前,我没有真正考虑过工作之外的时间。在完成白天工作之后,我突然(震惊,震惊!)有了一些业余时间却不知道做什么。

技能提高

每天忙于代码,我没有看到每天的工作真正地提高了我的技能。由于我在学Erlang,用Scheme编写了我的第一个程序,我在简历里增加了新语言。我仍然在写Erlang。

我还学到了,较大型开源项目是如何运作和组织的,以及开源对于公司意味着什么(我甚至可以说,对于每家公司意味着什么,但这需要另一篇博文了)。我不是说,开发不包含任何开源组件的产品就不赚钱,据我看来,每个项目都拥有大量的开源组件,盈利并在长期从更好的代码上获益,这是有可能的事情。

另外,我在数不胜数的知识点上提高了我的知识和技能,列举一些:解析和词法分析、分布式计算、架构、安全、项目(代码规范)之间快速切换、理解代码以及代码review。我也提高了软技能:沟通、团队精神、解决冲突、指导和处理高难度/突发情况下的问题。

一份新的工作

刚开始时,我有很多自己的小型业余项目,十分有趣,但是到了某个阶段,我感到不开心了,没人fork,貌似没人使用。我是唯一的开发者,我没有伙伴可以讨论解决方案或得到review的途径,而这是提高代码和技能的最佳途径。

我决定向较大型的项目提交代码,既然我从0.4版本就在使用node,是一名日常npm用户,我就向npm提交了一个补丁。Isaac Schlueter审查了我的一个PR,真不错,这让我为npm提交了更多的代码。

npm registry使用CouchDB做数据库,但是我不知道如何使用。我开始把CouchDB文档翻译成德语,这样我就学会了如何使用CouchDB和如何帮助项目。有一天,我想托管我自己的私有registry,当时我的硬盘里有CouchDB源代码,我不确定为什么registry没有引导。当通读代码时,我看到CouchDB有一个JavaScript MVC app,它不是官方发布的。这一天我开始向CouchDB贡献代码,而npm的PR有一堆,我不想再提交了:我不想让花时间查看的审核人感到太难。我向CouchDB贡献了更多的代码,因为他们真是不错的人们。

有时候,npm有一些与Node.js直接相关的bug和问题,因此我也向Node.js项目提交代码。

加入所有这些项目,得到review,与其他很多不同的贡献者协作,阅读其他人写的大量代码,审核补丁,和用户交流,解决他们的问题,实实在在地加强了我的技能。

在2014年,我足够幸运,得到了一份工作,我因为致力于开源项目CouchDB而获得了回报。

交新朋友

经过在开源技术社区的工作,我结识了大量新朋友。我遇到很多忙于同样工作的协作者,还有人在使用我参与的项目。他们大多比我聪明,至少对于我参与的项目来说,我可以说,他们都是非常优秀、思维开放的人。

他们就是我在发送了最初PR之后、还提交了更多补丁的理由。我认为,任何人没有兴趣把业余时间(甚至工作时间)投入到一个充满敌意的、糟糕的环境里。

坏的方面

每天贡献代码并真正坚持下来,不会一直都顺利。我想,大部分让人郁闷的事情都是那些对开源产品有着古怪期望的人们,他们免费用着人们在业余时间维护的产品。

npm里的这个issue是个例子,我过去和Domenic一起在业余时间做了大量工作,Domenic也花了大量时间去维护npm:

开源review截图

结论

每天向开源软件贡献代码的决定,改变了我生活的很多方面。我现在有偿参与着开源,在很多项目中交了很多朋友,这提高了我的技能。

我乐于看到公司支持他们的员工向开源软件贡献代码—他们99.99%都依靠开源软件,比如,他们的开发工具,直接应用的产品,甚至两者兼而有之。令人悲哀的是,对于大部分员工来说,在工作时间参与开源软件是相当难的,不是每个人都有足够的特权能够每天花费业余时间里的1小时参与到开源软件里。

Kyle SimpsonMathias Lafeldt这些人开始了类似的项目,貌似也改变了他们的生活,还有他们看待世界的方式,我对未来充满着渴望。

我是如何在48小时内创建1QAD网站的

本文是翻译,版权归原作者所有

我是如何hack了4种免费工具来创建每日邮件发送app的。

本文是关于如何创建One Quote A Day’s(1QAD)每日引用邮件服务的。

挑战

手头有数据库或名言(quote)和邮箱地址列表,我的任务就是每天给这些列表发送带有名言的邮件。名言应该按他们在数据库的顺序或状况进行读取。

理解挑战

让我们把问题分解为简单的任务:

  1. 在某处存放名言
  2. 在某处存放邮箱地址
  3. 创建一个重复任务,把一句名言放到邮件模板
  4. 发送邮件模板到邮件列表

存放名言:名言本身需要被放在某处。Dropbox、S3、我们自己的服务器;选择有很多。一旦确定好了,每句名言的URL不得不被记在某个地方。它可以放在一个json文件、或者你自己服务器等等。

存放邮箱地址:你可以存放在一个自定义的json文件、数据库、或使用mailchimp

重复任务:很多极客愿意开发自己的计划任务(cron)来发送邮件。cron在linux世界应该广泛,用于定期的重复任务。尽管如此,问题在于如果采用这种方法,你不得不控制邮件模板的输出。它将是纯html,而不是所期望的输出。

发送邮件:同样,很多极客将考虑使用自己的系统来发送邮件。问题在于你没有一种非常灵活的方法,来发送邮件的自定义模板文件。

解决方案

据我研究,最基础的信息是mailchimp提供了名叫“RSS to Email”的活动(campaign)功能。这意味着,只要有了RSS地址,对于每条新的RSS条目,mailchimp将自动给列表发送一封邮件。

Mailchimp还提供了最简单的、创建自定义邮件模板的方式。

搞定!

Mailchimp ping我的服务器—运行在Heroku上【注1】—针对特定URL每天一次。

当ping的时候,该URL将生成一个动态的、带有当天名言的RSS输出。

这些名言被存放在公开的dropbox目录里,他们的URL存放在firebase【注2】。为什么?因为dropbox免费,firebase也是免费 :) firebase还帮我存储了一个start_date的值。如果start_date是昨天,那么我就需要为今天读取数据库中的第一条名言。

扼要重述:

  1. 名言存放在dropbox,通过firebase访问
  2. 邮箱列表在mailchimp里动态更新
  3. 使用mailchimp的“RSS to Email”的活动功能,来重复发送email

我写的所有东西都在我的服务器 /rss 端点(endpoint)里,它们将生成RSS文件。60行的代码,0美元的花费。

  • 注1:Heroku是一个支持多种编程语言的云平台即服务。在2010年被Salesforce.com收购。Heroku作为最开始的云平台之一,从2007年6月起开发,当时它仅支持Ruby,但后来增加了对Java、Node.js、Scala、Clojure、Python以及(未记录在正式文件上)PHP和Perl的支持。基础操作系统是Debian,在最新的堆栈则是基于Debian的Ubuntu。http://zh.wikipedia.org/wiki/Heroku
  • 注2:Firebase也是类似的云服务,不同于Dropbox的文件,Firebase同步的是数据,服务对象是网站开发者,帮助他们开发具有实时(Real-Time)特性的应用。http://www.csdn.net/article/2014-10-22/2822221-google-acquires-firebase

自由/开源软件开发者Joey Hess的采访

本文是翻译,版权归原作者所有

原文地址(original source):https://zgrimshell.github.io/interviews-with-floss-developers-joey-hess/

很难有一种更好的方式就自由/开源软件项目背后的开发者展开一些列的采访,他们有着难以置信的思维,比如Joey Hess。对于他在自由软件生态系统上的贡献,特别是Debian上的贡献,要用笔触来写的话,本身将是一部书。他的影响甚至超过了其项目——人们直接关注他的博客文章来留意他在做什么以及过得怎么样。一名来自小木屋的hacker。如果你真的需要对真正hacker有个印象,那么Joey就是代表。由于本文不是一部书,我将只提到他已经参与到背后的几个项目——git-annex、ikiwiki、etckeeper、debian installer、部分dpkg、debhelper、devscripts和taskel。就这么多吧。

Joey Hess, Debian

我:给大家打个招呼?

Joeyh:我是Joey,个人网站是 https://joeyh.name/

我:你是如何开始编程的?

Joeyh:Atari 130XE电脑,装有BASIC和一个无聊的字处理软件,就没有其它了。其他朋友都没有电脑,因此得到软件的唯一途径就是手动在demo程序里敲代码,然后开始修改并编写自己的软件。这就是容易的学习方法。在学校也有一些这种logo。

我:你能给其他想学习编程的人什么建议?

Joeyh:你给了我一道难题,这比我开始的时候去真正理解一些东西还要难,比没有太多可用的资料时还被激励学编程更难。或许装备有真正交互的、简单的Arduino【注1】裸机系统能够回答你。

我最近有提到我的侄子,他正在学习Python,“Python the Hard Way“网站已经让他快速地掌握了很多东西。

我:说说你用来做开发的电脑配置?

Joeyh:卸载了间谍软件的Lenovo笔记本,Debian非稳定版、xmonad、xfce、vim。

我:你是如何看待Purism的(开源硬件笔记本发起项目,最近得到了CrowdSupply的投资)?

Joeyh:我对此了解不多,不过貌似消费层次的硬件质量不高,因此关闭了、且不值得信赖,需要搞清楚开发或者挑选开源的替代软件,做为一个社区,它们应该是能够满足我们需求的东东,并专注于此。一些项目正在尝试,我希望它们能够成功。

我:你如何看待Debian开发的未来?

Joeyh:嗯,我差不多不再担心它了。如果你回头看看我在过去2-3次的DebConfs会上的演讲,你就能找到关于它的最好的思考。

我:做为Debian开发者,你退休了。那么,你想过有一天重新回来,以及(或者)你计划去加入一些其它社区吗?

Joeyh:回归将是自豪的,不是吗?但是我想我不会的。毕竟,人不能两次踏进同一条河流。

相反,Debian可能将不得不容忍我这个让人讨厌的上游作者,我不会提交tar包,而是提交debian/directories,做为一名bug报告人员,我乐于享受报告有意思的bug,比如 -0 NaN

自从我离开Debian后,我好像有更多的时间可以参与到其它在线社区了,不过是以更加扩散的方式。或许这只是本来的样子,参与到自由软件、但没有拥抱像Debian之类的大型软件。

我:关于Debian会议,都有哪些值得回忆的时刻?

Joeyh:太多了!在会场外面的波兰农贸市场的野餐,吃的是浆果和玉米粉蒸肉;在瑞士忙碌一天后的虹鳟鱼和篝火;在爱丁堡离奇夜晚的会场即兴修理管风琴;夜晚和Ian Murdock一起漫步在Porto Alegre,他对于即将从事的事业是多么地谦虚;在西班牙整夜地hack;在芬兰的午夜太阳和持续不断的派对下无法入眠;呆在亚特兰大的宾馆大堂里设计Build-Depends。

我:你玩游戏吗?Valve Steam免费提供给Debian开发者,你使用Steam玩Valve游戏吗?

Joey:我玩过Half Life和Portal,但是攻略已经占用了我太多时间。我通常喜欢时间短的独立游戏,或者能告诉我们一些新的游戏玩法的游戏,最近喜欢的游戏是 A Dark Room

不过我更喜欢有趣的、现实中的桌面游戏,和朋友一起玩,比如Carcassanne Discovery和Hive。

三月份,为了参与“Seven Day Roguelike Challenge”,我将试着在一周内用Haskell编写一个rouguelike游戏【注2】,每天在博客写我的进展。

我:当前你是一名Haskell黑客(git-annex),你是如何评价这门语言的,它和Python、C、JavaScript、Ruby和Perl相比,你又作何评论?

Joeyh:不只是git-annex项目;我当前的所有项目都是用Haskell语言写的。

我认为,我们期望程序员在写代码时脑子里存多少东西,这是让人惊奇的。缓冲会溢出吗?修改全部变量的值将破坏代码的其它地方吗?输入已经被过滤了吗?接口改变了吗?Haskell马上解决了当中的一些问题,但更多的是,它让你开始注意到这种无处不在的问题,它提供了完全消除你代码中的一类问题的方法。

比如 http://joeyh.name/blog/entry/making_propellor_safer_with_GADTs_and_type_families/。我避免的这类bug从来没有影响过我的代码,但是阻止这类bug仍然是值得做的,因此我不必再担心它们了。

我:你建议把Haskell做为学习的首选语言吗,尤其是那些对于数学跃跃欲试的人?

Joeyh:我认为这个建议不错。或者它可以是另外的方式——在我年轻的时候,我就喜欢数学,但是数学把我淘汰了,这种方式在很多人身上都发生过,我想学习更多的关于高阶数学时,像Perl和C之类的语言不能提供太多帮助。我在Haskell里却能处处碰到一些。

我:相比于你使用Perl的时光,你是如何比较Haskell效率的?

Joehy:这很难比较;我现在是一个非常不同的程序员了。当我用Perl时,我很可能将更加迅速地发现了一些快速hack。但是,它们更像是保持快速hack。现在,或许我要花更长的时间才能达到这一步,但是代码好像更牢靠了,在扩展成更大的或不同程序上变得更有延展性。

还有,我对编写软件资源库感到非常疲惫了。

我:你能描述下你的生活哲学吗(你生活在森林里的小木屋,大量使用太阳能,包括我在内的很多人都很好奇,是什么在驱使着你向往这种生活,它又是如何影响着你的总体生活质量和幸福的。看看当今掠夺性的资本主义社会,你能够在一个月之内轻松赚取$10,000,貌似你是一名无政府主义者,且非常谦虚)?

Joeyh:我想开发一些或许可持续的、有价值的东东。这对于软件世界,难度是非常大的,因为很难过于超前考虑,也因为大部分工作没有强调这种真正价值。我非常幸运,能够找到一个点,在自由软件上投入这么多年的全部时间,我愿意为之放弃很多东西。

舍弃现代便利性,生活在小木屋里是非常棒的,因为这里安静,你可以尽可能多地思考;互联网随处都有,没有私密空间(或许有点儿慢);当你用太多时间静静地思考时,你将需要根据季节去砍木柴、挑水、跳到河里去避暑。

(谦虚?和大多数程序员一样,我内心深处有着飘飘然的自负……)

  • 注1:Arduino,是一个开放源代码的单芯片微控制器,它使用了Atmel AVR单片机,采用了基于开放源代码的软硬件平台,建构于简易输出/输入(simple I/O)接口板,并且具有使用类似Java、C语言的Processing/Wiring开发环境。http://zh.wikipedia.org/wiki/Arduino
  • 注2:《Rogue》是迷宫探索式电子游戏,最早由迈克尔·托依和格伦·韦科曼在1980年左右开发。部分因为游戏内容的过程生成,游戏在1980年代中期大学Unix系统上很流行。《Rogue》使迷宫探索在电子游戏领域普及,其他开发者制作了诸多统称为“类rogue”(Roguelike)的派生作品。比如它直接给与了《Hack》灵感,此游戏之后又衍生出《NetHack》。类rouge还影响了其他类型的商业游戏,如《暗黑破坏神》。http://zh.wikipedia.org/wiki/Rogue

年轻开发者的那些伤心事

本文是翻译,版权归原作者所有

这是关于一位有激情的年轻开发者的、几乎真实的故事。在2004年年末,他开始在一家小公司上班,这家公司有他想要的一切:丰厚的薪水、使用他钟情的编程语言,处理复杂性和搭建架构。

这并不是该年轻开发者的首次工作经历。但是他的第一个项目已经被证明是有问题的。当时,他认为功能从来不会改变。但是他错了,每次修改功能都需要一次彻底的重构,引发了bug以及大量时间的浪费。他甚至尝试过编写测试之类的、有效的方式。不过他的测试需要维护、编写所需时间、甚至更多执行的时间。

对于每个年轻的开发者,他在成长过程中总是听到有经验的开发者说到的“当心!过早优化是万恶之源!”、“编写测试!测试!测试!”。或许他只是在重构一个微小的实用程序方法,而这时有经验的开发者将走过来、以严厉的表情警告说“你没有做过早优化,对吧?”、或“你在写测试,是吗?”。

但是所有这些警告都被忽视了。因为年轻开发者不理解过早优化为什么是万恶之源、也不理解测试应该是正确的。根据他自己的经验,他知道下面的需求从长期看是不合理的(因为它们可能有修改),编写测试就是在浪费时间。

“我究竟为什么每次都必须重写我的代码?我究竟为什么必须在当下编写代码、随后再重构,我什么时候能够编写世界上最好的代码?还有,我究竟为什么不得不用我所有的时间来编写没用的测试?”这就是年轻开发者的疑惑。

一天,年轻开发者开始着手一个新项目。他决定无视有经验开发者的警告;为了应对每次需求变化,他期望每块代码是快速的、可配置的和健壮的。需求清晰了,不过他要做得更好。比如,当有个功能,生成以大写‘S’结尾的产品代码时,他创建一个配置对象,这样结尾的字母就可以通过配置来修改,通过配置还可以决定这个字母应该是大写还是小写。当需求说明需要一些校验时,他就创建一个庞大的校验器,不仅包含需求要求的,还有很多没要求的。

在编写了项目的核心之后,一种完美的感觉充满了年轻开发者的全身。“那个有经验的开发者是错误的!”年轻开发者看着自己的杰作得意地说。他夜以继日地工作,认为数周后就可以发布产品了。

光阴荏苒……

一天,客户告知他们一个bug。有经验的开发者看到这个bug,对显示器上出现的情况保留着厌恶:年轻开发者看到了大教堂,而有经验开发者看到的是贫民窟;年轻开发者看到了模式,而有经验开发者看到的是一个充斥着class的复杂网络;年轻开发者看到了比光速还快的代码,而有经验开发者看到的是不必要的复杂算法。他不想碰这些代码,因此他让这个年轻的开发者去修复自己的bug。

其他人不认为年轻开发者的代码是优美的,只有这个想法让他感到失望。他充满愤怒地打开了项目……才发现代码对于他来说,也是费解的!代码背后没有清晰的意义。“这就是我不打算再使用这门语言的原因,语法太糟糕了”,往往是年轻开发者的第一反应。但是他在内心深处知道,这不是真正的问题。真正的问题是他。

一天结束的时候,bug修复好了,却产生了另一个bug,这是那一天之后发现的。每次修复都在影响着项目内部的瘦弱的平衡,就像亮白色衣服上的一小块黑色补丁。

此时这个年轻的开发者绝望了,他的大教堂开始摇晃,他感到离崩塌不远了。年轻开发者自问,“或许我不是这份工作的合适人选。为什么我不能编写恰当的代码呢?”带着沮丧和愤怒的交织心情,年轻的开发者打开了有经验开发者维护的项目。

他看到的代码让他感到吃惊:代码有注释和测试,易于阅读。和他最初开始写的代码没有太多区别,有一些清晰的例外:没有可扩展的配置,每行代码都被测试了,每个方法都取着有意义的名字、且简短(最多10行代码),只做必要的,每个文件只包含了能够严格做本质工作的方法。

在这个忧郁的时刻,有经验开发者来到了年轻开发者身边,和他挨得很近,开始重构引起所有bug的代码。

他们一起工作了数天,有时候,有经验开发者写代码,而年轻开发者观看有经验开发者如何解决问题;另些场合,年轻开发者写代码,而有经验开发者在旁边监督。

数天后,一次新的部署标志着bug已被修复。引起bug的小部分代码,现在可以被测试了、易于阅读了,也很稳定。有经验开发者看着年轻开发者说:“你现在明白了吗?

年轻开发者点了点头,他现在明白了。完美的关键不是预测将来,而是编写容易修改、测试(这样修改就不会引发其它bug了)以及只需满足当前需求的代码。当他意识到这一点时,他注意到他正在变化,正在变成差不多有经验的开发者。

年轻开发者问,“我们现在能够重构整个项目吗?”
有经验开发者干脆地答道,“当然不可以!没有预算”
年轻开发者问,“但是,如果其它bug出现了,该怎么办?”
有经验开发者答道,“我们将找个自由职业者(freelancer)来修复”

然后,这个差不多有经验的开发者开始编写优秀的代码,准备学习另外的经验。不过这是另外一个故事了。

  • 年轻开发者的启示:回头看看你过去写的代码,如果你的代码看起来还不够优美,不要感到失望。
  • 有经验开发者的启示:当周围有年轻开发者时,你将不得不给他擦屁股。你最好的机会就是他将学习如何编写得体的代码,越快越好。
  • 自由职业者的启示:你或许想提高你的报价 :-P

— END —

译文:年轻开发者的那些伤心事 》| 腊八粥

为什么工程师会造出蹩脚的产品

本文是翻译,版权归原作者所有

原文地址(original source):http://willschenk.com/why-engineers-build-crappy-products/

就像是工程师自己设计的产品

当你第一眼看到下面的用户界面时,你会尖叫出来,它一定是由工程师设计出来的

pspad-user-interface

via Daring Fireball User Interface of the Week

为什么会这样?对于工程或软件开发过程而言,是什么导致了用户实际不可能去使用的用户界面?

用户不满的完美风暴

简短版本:

  • 对于工程师的工作,最有意思的部分是陶醉于解决空间内的、可改善的地方——你能够让计算机做任何牛逼的东西。
  • 工程师不想做选择,这限制了能力和灵活性。
  • 工程师更看重增加潜在性的功能,而不是移去不必要的复杂性。
  • 工程师想自己搞定设计方面的问题。

成为擅长交际的人

(译者注:上面是来自于youtube.com的视频)

考虑一种新产品的过程,最初是想了解软件应该做什么,那么,就从定义问题的解决方案开始。这里有个假定,问题本身被正确地定下来了,但它经常不是这样的。这些需求经常体现为用户故事和线框图,它们定义了用户要做的事情和具体的界面,用户将借助该界面来完成那些目标。

这里有个隐藏的条件,对于技术能够做什么是理解的。有时候,尤其对于一种新颖技术方案的产品而言,技术能够做什么 还无法完全了解。不管解决方案是否位于已知的问题领域,在开发产品的时候,常常会碰到不同的挑战。开发软件实际上是非常难的。

鉴于此,工程将注重设计,开始考虑解决方案的总体结构,在产品风险最大的地方应该精心组织他们的开发投入——这部分往往是技术上最有挑战的。如果我们借助原型或某种模拟界面使其运转,以证明这些地方功能正常,那么唯一搞明白的就是理清产品的剩余部分。

工程的不确定特性

到了有意思的环节。每个工程师都喜欢从头开发,因为他们可以探索而不必应对现有代码的折衷、约束和杂乱。这是一种探索的过程,一种能够探索一种技术空间可能性和潜力的过程。这真的很棒,让工程变得有趣的很大一部分。

从小的功能开发,用新颖的方式将其组合在一起,做出逐渐强大的东西。工程师可以接触带有不同功能的各种小物件,使得探索它能够实现所有功能变得更加容易。能够炫耀这些酷炫东西,从社交上是值得做的,除了它不能做什么,还有它能够做什么。关注这些技术层面,使得人们去优化各方面的功能。

陶醉于界面

Engineers Keeping it Real: Go Fuck Yourself

Engineers Keeping it Real: Go Fuck Yourself

问题是 产品不等同于技术。技术对于开发产品是必要的,却不是充分的。技术只是管道,使产品变得可能,但实际上不是人们关心的东西。

对潜力的陶醉与创建优雅产品相冲突,因为产品最重要的是做出选择,从非常复杂的地方创造出清晰明了的东西。这更像是迷失于森林之中;理想和抱负,两个方面的努力是直接矛盾的。

例子:我又做了一件蠢事

我们最近在开发一个产品,它使用email做为一种界面接触点(interface touch point)。当用户打算和另一名仅仅部分地设置了账户的用户交互时,现有的需求说明无法真正解释应该发生什么。我们只是在摆弄着一些东东,因此责备需求不明确是不公平的;因为在开发的时候,经常是这样,我们最终迷失在人们期望不到的杂乱中。

从边界情况的角度看,当关注于工程实现和基于能够实现的东西基础之上所开发的响应的健壮性时,我本能地开始构建能够处理这种情况的代码。它把松懈当做端点,在这种情况下,它做了一些更加聪明的事情,那么,email应该也自然地做着更加聪明的事情。

我开始深入到能够存储那些将要排队的部分请求,便于将来在用户界面去处理。我开始创建一大堆功能,因为我正在考虑技术相关的东西,其它的界面有着“优雅”的地方,我想开发完整的东西。愚蠢慢慢地爬进了界面,因为我一直在搜寻一种技术上的解决方案。

这不是产品的核心。没有人真正关心过它。对于类似情况,答案真的不是过多的技术解决方案。我认为没有问题,但是技术解决方案不是解决问题的最有效方式。这实际上是设计方面的问题。

技术是简单的

如果团队之间协调不够,如果设计组“完成了”他们的工作,然后将东西抛给了工程组,那么将出现这种对话,工程组将针对“漏掉的、但是我们需要解决的地方”提出设计需求。它可以是漏掉的,但是它不需要被解决。在这种情况下,解决方案根本就没有“解决掉这个问题”,而是重新界定了这个问题。这种重新界定把问题放到了工程师所不希望的地方。这不是要建立用户能够解决的、一整套部分完工的请求队列系统,对于重要任务或不管什么任务给予报警,而只需让email界面简洁、并把用户跳转到网站的主流程里。

总之,工程师倾向于成为蹩脚的产品设计人员的原因在于:

  • 对于工程师的工作,最有意思的部分在于痴迷于解决空间内的可改善的地方——你能够让计算机做任何牛逼的东西。
  • 工程师不想做选择,这限制了能力和灵活性。
  • 工程师更看重增加潜在性的功能,而不是移去不必要的复杂性。
  • 工程师想自己搞定设计方面的问题。