gettingreal学习笔记(编辑修改稿)

gettingreal学习笔记(编辑修改稿)内容摘要：

寻找并庆祝小小的胜利： 在开发过程中作重要的东西就是成员的热情与动力，阶段性的胜利是激发团队斗志的最好方法。 如果你把胜利的周期拉的太长，成员的斗志会被消磨，也就不可能开发出优秀的产品。 如果你处在长达一个月的产品周期里面，争取每周来个阶段性的成功。 当然最好的情况就是每天都能够有个小小的胜利，你可以通过下面的方式来界定阶段性的成功： * 实现一个小功能 * 增强一个现有的功能 * 重写一些帮助文字来降低客户支持的成本 * 移除一个你不需要的功能特性 持续性的成功会让 你的团队保持最高的开发热情。 七、 Getting Real 学习笔记：关于雇员 尽可能少的雇人： 其实不需要过早的让你的团队规模膨胀，也许今后也不需要。 如果真的需要 100 个人的话，你也不用一次性的把他们都招回来，从来都没有一个有效的办法让很多人快速的融入到一个工作环境之中的。 过多的人员会让你为培训而头痛、时常发生的个人摩擦、无法避免的沟通障碍，大家各自有各自的主张，总之是十分麻烦。 所以，尽可能的避免雇人，同时想想其它的办法来解决人手不足的问题。 看看负担是否过重，那件事情是否需要去实现，或者用其它的 办法来解决，总之最后再考虑增加人手。 GE的前任 CEO Jack Welch在雇用一个人之前都会考虑一下如果没有这个人情况将会怎样，因为通常都不会向你所想象的那样需要那么多的人。 炒掉不合格的人： 除了看简历、了解雇用人员的工作经历之外，试用也是一个非常重要的过程。 在你正式录用一个人之前，你应该给一个小项目让他去尝试一下。 你可以了解到他是如何处理这个项目、如何沟通、如何工作的，如果你有机会在屏幕前看看他的编码和设计，你将会了解到更多的细节，这些对于考察一个人是否合格非常有用。 8 不要只说不做： 用来 考查一名技术人员， OpenSource 是一件非常棒的礼物，如果他参与过开源项目（国内好像太少了），你很容易就可以从中可以看出他的能力和对技术的热情，那些只说不做的应聘者很快就会在你的眼前漏出马脚。 你可以通过下面的条件来判断一个开发人员的能力：工作质量、对于文化的看法、热情程度、完成度和社交能力。 37Signals 只雇用参与过开源项目的开发人员，要知道真正热爱开发的人才是你的团队所需要的。 雇用能力全面的人： 对于一个小的团队，更多需要的是能力全面的多面手，而不是某一个领域的专家。 你需要一个善于书写的 设计师，一个有设计能力的开发人员。 每个人都有系统架构的能力，善于组织自己的思维，并且能够和客户沟通。 因为小的团队经常需要快速的改变决策方向，所以你的团队成员也必须有很强的学习能力，能够快速的适应决策的变化。 热情是不可能伪造的： 你所需要的并不是一名技术专家或业界名人，通常第一个跳槽的就是这类人。 对于你来说，一个快乐的能力稍逊的人要比一个经常抱怨的专家适合的多，因为热情是不可能伪造的。 你应该雇用那些充满热情的人，不要你费心就能够独立的完成任务的人，厌倦了大公司那种官僚和缓慢节奏的人。 当然，如果他们想你 所想、恨你所恨，如此志同道合，那就再好不过了。 你需要“语言大师”： 如果你正在为录用那个人而举棋不定，选择最善于书写的那个。 不管他是设计人员、开发人员、市场人员还是销售人员，写作能力才是最重要的。 有效与简洁的文字会带给你高效简洁的代码、设计、邮件、即时通讯和更多的好处。 一个善于书写的人并不仅仅是会用词，他们善于沟通，他们让事情更容易被理解，他们知道那些细节被忽略掉了，他们有清晰的思维，而这些正是你所需要的。 Clear writing leads to clear thinking. —— Michael A. Covington, Professor of Computer Science at The University of Geia 八、 Getting Real 学习笔记：界面设计 界面优先： 很多应用程序的开发都从程序的设计开始，这是一个糟糕的方式。 在你编码之前先设计好界面。 编码是开发一个程序最繁重的一部分工作，它是昂贵的并且在确定之后难以改变的。 而设计相对廉价许多，只需要简单得草稿就行了，当然你也可以用 HTML 代码来实现你的原型界面。 界面优先的另外一个原因 —— 它 就是你最终产品的样子，大家都能够看到你将做出什么样的产品。 从界面开始你能够感觉到产品是存在的，容易使用吗。 能够解决什么问题。 大家能够在开始就找到这些答案，你也能够灵活的去调整程序。 核心式设计： 从最核心的页面开始设计，然后延伸开去。 这意味着在开始你并不需要去考虑页面导航条、页脚内容、颜色和 LOGO之类的，你应该将精力花在核心功能的页面上。 例如你设计一个 BLOG程序， BLOG文章的显示就是最重要的页面，而不是旁边的分类、页头导航和用户的评论。 只有当页面上最核心的元素设计完成了，你才应该去考虑那些相对次要的内容，然后一步步地向边缘移动，这就是核心式设计。 它和那些框架式设计正好相反，先是整体结构，最后才是核心部分。 核心式设计让你把时间花在真正需要关注的地方，你能够尽早的与设计师和开发人员交流，而不是等到所有的部分都设计好了再去。 界面的三态： 9 对于你设计的每一个功能页面，你都必须注意它的三种呈现状态。 * 常规界面：用户在正常使用时操作的界面，上面已经有用户的使用数据显示。 * 初始化界面：当用户第一次来到时看到的界面，上面没有任何用户的数据。 * 错误界面：它会在产生任何错误的时候出现 初始化界面：忽视你的初始化界面将是一个非常严重的错误。 它是用户使用你的程序所见到的第一个界面，失去这个第一印象你将再也无法挽回。 设计师们通常会把页面模版的所有地方都填充上数据，任何一个列表、表单、缝隙和剩余空间都不会放过，他们认为这样看上去很不错，程序会工作得很正常。 在大多数的情况下，程序都是出于缺乏数据的状态的，只有用户长期的使用才会慢慢的填充数据，其实用户都会通过初始化界面的好坏来决定是否使用这个程序。 然而很多开发者和设计师都忽略了这一点，因为他们从 来都是在一个充满了数据的测试界面下工作的，很少会扮演一个新的用户进入系统去看看。 一个成功的初始化界面应该包括下面的内容。 * 显示快速的教程和帮助性内容 * 给一个填充了内容的示例图片 * 向用户解释如何开始以及最终会看到什么 * 回答初次使用者的基本问题，我看到的是什么。 我应该如何做。 记住，一定要给你的用户一个好的开始，留下一个好的印象。 防止错误的设计： 在线的操作难免不会产生错误，这一点是我们应该认同的。 不管你是多么仔细的实际你的程序，经过多少次的测试，用户 总是会碰到问题。 那么如何处理这些不可避免的问题呢。 使用防止错误的设计。 就像预防事故的驾驶那样，开发者需要坚持不懈的寻找那些容易让用户混淆和受挫的地方，并且要提供更加友好的错误的提示页面，给用户清晰的引导，提高用户体验。 关联性胜过一致性： 应该用按钮还是链接，这取决于要执行的动作；日历是用列表显示还是用网格显示，这取决于它会显示多长时间；是否全局的导航链接要出现在所有的页面上，是否每个页面上都要显示搜索框或者相同的页脚，这些都取决于是否真的需要。 当用户需要的时候再给他，用相关联的操作来提示用户，去掉那 些没有必要的，不要被那些生硬的一致性原则束缚了你的设计，用户的体验永远是第一位的。 书写也是界面设计： 伟大的界面是写出来的。 你在界面上的用词和像素、图标与字体一样重要。 你需要关注那些阅读你的界面的人们想知道什么，以及如何简洁又清晰的表达。 你要使用与你的用户相同的语言来表达，千万不要用那些技术化的词汇，不要像工程师之间的交谈那样，用户看起来会觉得是天书的，尽量使用短小而亲切的句子来表达内容。 几乎在所有的地方文字都是设计的一部分，例如图标旁边的文字、表单的示例、带标签的按钮，还有操作的步骤说明，所有这些 都是界面的设计。 统一界面： 将管理界面整合到前端的公共界面中去，所谓管理界面，通常都是用来设置一些参数，管理数据和用户的。 因为大部分的精力会花费在前端的界面设计，所以可以将管理界面前置，不要分隔成两个不同的操作界面。 例如一些常用的编辑、添加、删除操作，放在前端的界面里比较合适。 如果你同时维护两个不同的界面，其实是一件痛苦的事情，就像同时交两份税一样，所以尽可能的减少界面的数量，这样才能提高界面的质量。 九、 Getting Real 学习笔记：关于编码 10 小巧的软件： 随着代码量的增加，你软件 的复杂度也会随之增加，每一次调整和变动的效果都会叠加，所以让你的程序代码尽可能的保持简洁。 那么抵制这种代码复杂化的最好方法就是只做小巧的软件，它也意味着更少的功能、更少的代码和更少的浪费。 小巧的软件让你放弃对未来功能的规划，将重点放在解决现在的问题上。 为什么呢。 因为你所担心的未来的扩展通常不会立刻到来。 开发小巧的软件会给你带来如下的好处： * 容易管理 * 少量的代码让你的维护变得简单 * 你可以更灵活的改变功能（代码修改的成本降低） * 更少的 BUGS和更少的客户支持 让你的开发人员敢于向不合理的功能需求宣战，他们知道如何简单的实现一个合理的功能，用最好的方法。 为快乐而编码： 一个快乐的程序员会是一个高产的程序员，选择那些能够让你的团队保持激情的工具，而不要选择那些符合业界标准的陈旧的工具。 你的成员需要有趣的、富有挑战的、能够让人感到自豪的，能够在 8 小时的工作内充分感觉到快乐的方式来工作。 就像 37Signals 选择了 Ruby 作为他们的开发语言，他们用最大的热情推动了 Rails 框架的发展（在此之前 Ruby 还默默无闻）。 当然不仅仅是开发语言，一个他们喜欢的 平台、应用或者是框架，都能够给他们带来快乐。 只有快乐的程序员才会写出简单的、可读的代码，他们拥有清晰的思路和一流的解决方法。