《交互设计之路——让高科技产品回归人性》读书笔记（五）

第八章

• 代码重用不但可以节省很多时间，而且它们是已经由别的程序员证实可用的代码，不必担心Bug。但代码重用的主要副作用是，程序中很多代码的存在并不是为了满足设计师或者用户的要求，而是因为这些代码事先已经存在。程序员相信简单性和容易获取（在这里是已经写好的代码），比其他人的任何建议更重要。
• 程序员们都很聪明、有能力、关心产品质量和公司的成败。他们努力实现设计师的设计意图，但是他们不愿意以牺牲自己的编程效率为代价。当然，他们会努力实现设计师的愿景，但是不能以改变他们的实现过程的优先顺序为条件。
• 如你所见，在使用者需求和程序员需求之间存在着清晰的利益冲突。法官和律师有共同的技能，但是我们决不会让律师去裁定他们自己的案子。我们也决不让篮球队员为自己的比赛做裁判。然而在利益冲突清晰可见的情况下，我们却一直让程序员根据个人编程的需要做设计。
• 程序员们非常习惯了代码重用，因此就算他们实际上没有复制代码，也喜欢复制已有的技术。例如，很多程序都有大量确认对话框，实际上它们完全没有必要，一部分对话框存在的原因是因为它们已经在重用的代码中存在了，还有很多对话框存在，是因为程序员们只是习惯性地加上它们。
• 程序员很难让设计师明白哪怕是最简单的编程方面的问题。而设计师经常在将花费几个星期做出的产品设计结果交给程序员们时，却被告知实现不了。两个不同阵营里的人使用着不同的语言，带着迥异的知识、文化、心理和审美背景来到了计算机世界。程序员鄙视设计师，因为设计师的想法看上去模糊，没有很好地组织起来，他们觉得设计师的喜好让人琢磨不定。设计师则觉得程序员缺乏想像，保守，不想办法如何实现就断然回绝自己的设计方案。由于对于设计师来说，程序是不可见的，他们没有办法确认程序员坚持其设计不可能通过程序实现的说法是否正确。
• 如果谁要管理一个编程队伍，他必须得到程序员们的尊重。程序员做的工作异常复杂，要求苛刻，他们强烈地捍卫自己的领地。任何人如果不了解，不熟知和尊重程序员的工作而想领导程序员，必将失败。
• 在大多数软件公司中，最有经验的程序员往往负责软件产品中最核心的部分。与此对应的是，企业一般不会安排他们去接听技术支持电话。技术支持电话一般会转到技术支持人员或初级程序员那里。如果资深程序员偶尔接到电话，多半是因为用户问的问题有一定的难度，技术支持人员回答不了。经过这样的过滤，资深程序员几乎没有与一般用户交谈的机会。而且，他们会错误地认为他们接触到的用户代表着一般用户。
• 程序员知道程序的质量取决于自己的道德。老板可以要求质量，但是不愿意投入相应的时间和精力去检测质量是否达到。
• 阅读并理解别人的代码需要花时间，比重新编写代码花的时间还要多。程序员知道这个道理，所以，最终他们要对产品的成功全权负责，他们知道，自己责任重大。
• 让程序员做设计，得到的不仅是糟糕的设计，还导致他们失去对设计过程的尊重。他们已经蒙混了设计过程那么长时间，因此他们习惯了抹杀设计的价值。因而，雇用的交互设计师自然会受到程序员们的轻视。
• 这种状况导致了交互设计师、设计过程，甚至设计本身都没有受到应有的尊重。对设计的不尊重，让人们觉得设计文档只是一种意见或模糊的建议，而不是清晰、具体，必须遵循的陈述。既然设计是一种意见，程序员认为可以随心所欲地对其进行选择。最终由程序员根据编程的难易或个人爱好做出决策的，因此这样的决策往往是错误的。
• 另一方面，每一位程序员都能讲出好产品最终失败的故事。例如，一位不喜欢打字的资深主管要求公司的所有软件产品只允许用鼠标操作。而另一位拙于使用鼠标的资深主管宣布其公司的所有软件产品只能用键盘操作。这种毁灭性的，自我参考性的设计导致程序员们绝望情绪的蔓延。
• 在通常的开发过程中，因为交互的设计和交互的实现交织在一起而更加增加了难度。一位经理可能会要求改变程序的行为，只是他不会认为要程序员用不同的实现方法。但是由于程序的行为和实现紧密相连，不可能改变前者而不波及后者。
• 从程序员的角度看，仅仅有人告诉程序员去做（无论对方职位多高），独立意识很强的程序员是不会去改变代码的。如果想改变已有的代码，首先必须改变程序员的想法。你必须提供合理而有根据的理由来改变代码，必须以程序员能理解的词语陈述，而且必须得由有直接利害关系的人来陈述。
• 二三十年前，计算机处理能力有限，计算资源稀缺，任何好的想法都有可能受制于计算机有限的能力。那时计算机科学的主攻方向是发展能够解放有限计算机资源的技术。那个时代编写的软件，优先考虑处理性能，而牺牲其他效果，如容易使用。
• 为了得到人性化的产品，我们必须改变我们的软件开发过程，让使用交互系统的人成为焦点。在过程上我们能做的唯一而最重要的变化是，在编程开始之前完整地设计我们的交互产品。第二重要的改变是将设计责任交给经过训练的交互设计师。