11 2018 档案
摘要：为什么要并发 并发是一种解耦策略。它帮助我们把做什么（目的）和何时（时机）做分解开。解耦目的与时机能明显地改进应用程序的吞吐量和结构。 迷思和误解 1、并发总能改进性能：并发只在多个线程或处理器之间能分享大量等待时间的时候才能改进性能。 2、编写并发程序无需修改设计：并发算法的设计有可能与单线程系统
阅读全文
摘要：Kent Beck的简单设计四条规则 1、运行所有测试 2、不可重复 3、表达了程序员的意图 4、尽可能减少类和方法的数量 简单设计规则1：运行所有测试 遵循有关编写测试并持续运行测试的简单、明确的规则，系统就会更贴近OO低耦合度、高内聚度的目标。编写测试引致更好的设计。 简单设计规则2~4：重构
阅读全文
摘要：无论是设计系统或单独的模块，使用大概可工作的最简单方案。 将系统的构造与使用分开 1、分解main 将构造与使用分开的方法之一是将全部构造过程搬迁到main或被称之为main的模块中。 2、工厂 有时应用程序也要负责确定何时创建对象。 3、依赖注入 有一种强大的机制可以实现分离构造与使用，那就是依赖
阅读全文
摘要：类应该短小 1、单一权责原则（SRP） 系统应该由许多短小的类而不是少量巨大的类组成。 每个小类封装一个权责，只有一个修改的原因，并与少数其他类一起协同达成期望的系统行为。 2、内聚 类应该只有少量实体变量。类中的每个方法都应该操作一个或多个这种变量。 3、保持内聚性就会得到许多短小的类 为了修改而
阅读全文
摘要：TDD三定律 定律一 在编写不能通过的单元测试前，不可编写生产代码。 定律二 只可编写刚好无法通过的单元测试，不能编译也算不通过。 定律三 只可编写刚好以通过当前失败测试的生产代码。 保持测试整洁 测试代码和生产代码一样重要。它需要被思考、被设计和被照料。它该像生产代码一般保持整洁。 整洁的测试 在
阅读全文
摘要：1、使用第三方代码，把边界接口保留在类或近亲类中。避免从公共API中返回边界接口，或将边界接口作为参数传递给公共API。 2、浏览和学习边界，不要在生产代码中试验新东西，而是编写测试来遍览和理解第三方代码。Jim Newkirk把这个叫做学习性测试。 3、学习性测试的好处不只是免费，能帮助我们增进对
阅读全文
摘要：1、使用异常而非返回码 2、先写Try-Catch-Finally语句 3、使用不可控异常，可控异常的代价是违反开放/闭合原则 4、给出异常发生的环境说明，抛出的每个异常，都应当提供足够的环境说明，以便判断错误的来源和处所 5、依调用者需要定义异常类 6、定义常规流程，使用特例模式。创建一个类或配置
阅读全文
摘要：数据结构、对象的反对称性 对象（对象式代码）曝露行为，隐藏数据。便于添加新对象类型而无需修改既有行为，同时也难以在既有对象中添加新行为。 数据结构（过程式代码）曝露数据，没有明显的行为。便于向既有数据结构添加新行为，同时也难以向既有函数添加新数据结构。 在任何系统中，我们有时会希望能够灵活地添加新数
阅读全文
摘要：垂直格式 1、推荐单文件200行代码左右，最长不超过500行。 2、每一组思路完整的代码，中间用空白行区隔。 3、紧密相关的代码应该互相靠近。 4、本地变量和实体变量应该在类的顶部声明。 5、概念相关的代码应该放在一起，相关性越强，距离越短。 6、自上向下展示函数调用依赖顺序。被调用的函数应该放在执
阅读全文
摘要：只有代码能告诉你它做的事，那是唯一真正准确的信息来源。 注释是弥补在用代码表达意图时遭遇的失败。 尽管有时也需要注释，我们也该多花心思尽量减少注释量。 好注释 有些注释是必须的，也是有利的。不过要记住，唯一真正好的注释是想办法不去写的注释 1、法律信息 公司代码规范要求编写与法律有关的注释。 2、提
阅读全文
摘要：短小 函数的第一规则是要短小。第二条规则是还要更短小。 函数20行封顶最佳。 if语句、else语句、while语句等，其中的代码块应该只有一行，而且，块内调用的函数拥有较具说明性的名称，还能起到文档的作用。 只做一件事 函数应该做一件事。做好这件事。只做这一件事。 每个函数一个抽象层级 自顶向下读
阅读全文
摘要：名副其实 1、选个好名字要花时间，但省下来的时间比花掉的多 2、一旦发现有更好的名称，就换掉旧的 3、如果名称需要注释来补充，那就不算是名副其实 避免误导 1、应当避免使用与本意相悖的词 hp、aix和sco都不该用做变量名，因为它们都是UNIX平台或类UNIX平台的专有名称。 别用accountL
阅读全文
摘要：勒布朗（LeBlanc）法则 稍后等于永不（Later equals never），任何说以后改的代码最终都不会再去改了。 简单代码规则 1、能通过所有测试 2、没有重复代码 3、体现系统中的全部设计理念 4、包括尽量少的实体
阅读全文
摘要：十大问题 1、产品能吸引目标消费者的关注吗？ 2、产品的设计是否人性化，是否易于操作？ 3、产品能在竞争中取胜吗？即使是面对未来风云变化的市场，依旧有取胜的把握吗？ 4、我了解目标用户吗？产品（不是理想的产品，而是实际开发出来的产品）是否能得到他们的认可？ 5、产品是否有别于市面上的其他产品？我能在
阅读全文
摘要：十大要点 1、产品管理的职责：许多产品经理将大把的时间浪费在与产品管理无关的工作上 2、用户体验：对于大多数软件产品来说，用户体验就是产品的生命 3、机会评估：用方便快捷的机会评估方法取代过时的市场需求文档 4、特约用户：打造优秀的产品没有任何捷径，只能请用户反复试用产品，不断改进 5、产品原则：可
阅读全文
摘要：最具挑战性的工作 产品管理中难度最大，也最能体现产品经理实力的是定义成功的平台产品。所谓平台产品是指一类基础软件，应该开发者能在其基础上开发应用程序 平台产品要面对三种不同的客户 1、应用软件供应商：选择你的平台创建解决方案的公司；应用软件供应商关心平台开发商的生存能力、定价、认证情况、产品质量、技
阅读全文
摘要：十大要点 1、可用性：很少有企业开发这类软件时会进行交互设计、视觉设计、可用性测试，因此产品才会表现得如此糟糕 2、产品正常工作：多数企业级产品根本没法使用，或者还需花大量的时间和资金开发临时补丁，产品才能正常运行 3、特例产品：必须坚持原则才能特例产品的诱惑，对急需资金的小公司而言尤其如此。开发满
阅读全文
摘要：十大要点 1、可用性：大众网络服务产品必须具备良好的用户体验 2、人物角色：按典型特征将用户分类，抽象出有代表性的用户类型（人物角色） 3、扩展性：应该不间断地考虑扩展性问题，永远留有余地，不到万不得已不要满负载运行 4、持续可用性：在系统设计上保证持续可用性与规划扩展性一样重要 5、客户服务：传统
阅读全文
摘要：两者缺一不可 交互设计和视觉设计完全是两回事 视觉设计可以满足用户的情感需求 良好的用户体验是交互设计师和视觉设计师合作的结果。他们共同配合产品经理定义产品
阅读全文
摘要：技术接纳曲线 涉及了技术创新者、尝鲜者、早期消费大众、后期消费大众和跟随者，很少有产品能越过鸿沟——获得尝鲜者以外消费者的青睐 不同类型的用户具有不同的情感需求，除了技术接纳曲线模型描述用户外，还应该增加一种情感接纳曲线作为补充 情感接纳曲线 1、技术爱好者（即技术创新者）购买产品，仅仅是因为产品采
阅读全文
摘要：消费者购买产品大多源于情感需求 企业级消费者出于恐惧和贪婪购买产品：如果不买这款产品，竞争对手会超过我，黑客会攻破我的防火墙，客户将弃我而去；如果买了，会赚得更多，省得更多 大众消费者购买产品的原因更多样化：使用这款产品（登录这个网站），就有机会交到朋友（化解孤独），或者找到约会对象（满足爱的需求）
阅读全文
摘要：精明的公司至少要手握两件“法宝” 1、对目标市场了如指掌，对现有产品的缺陷洞若观火 2、跟踪最亲的技术趋势。新技术层出不穷，让之前无法实现的方案变得可能
阅读全文
摘要：产品需求不能用户说了算 1、在看到具体的产品之前，用户很难知道自己需要什么 2、用户不知道什么样的产品是可行的（在目前的技术条件下可以实现） 3、用户之间缺少沟通，需求很难统一 怎样回避特例产品可能带来的危害 1、根据产品原则决定是否接受客户提出的特殊要求 2、产品经理应该与客户一起梳理需求，发现问
阅读全文
摘要：苹果公司值得学习的经验 1、硬件为软件服务：苹果公司明白硬件必须为软件服务，软件直接服务用户，满足用户需求。采用多点触控显示屏、重力加速器、距离传感器这些硬件技术是为了配合软件满足用户需求 2、软件为用户体验服务：所有公司都把用户体验挂在嘴边，只有苹果公司把它放在心里。苹果公司明白用户体验是产品立足
阅读全文
摘要：十大秘诀 1、了解公司制定决策的方式：知道决策权在谁手里，了解他制定决策的方式，只需要说服他就行了 2、建立人脉网络：主动帮助他人，积累人脉关系 3、臭鼬工程：在工作之余做出产品原型来，产品原型具有超出想像的说服效果 4、自己顶上：缺人的时候自己解决，一切为了推出产品，不要计较个人得失 5、有选择地
阅读全文
摘要：大公司实现创新的方法 20%法则：谷歌的程序员有20%的工作时间可以用来从事创新研究，这个方法最早是从施乐帕克研究所学来的。20%法则鼓励普通员工自己尝试各种想法，让员工打心底愿意倾注更多的激情和汗水去创新 臭鼬工程：利用自己的时间，低调地进行创新研究。有些公司规定员工在职期间研究出来的成果都归公司
阅读全文
摘要：产品设计方式 第一步：创业初期只设三个职位，产品经理、交互设计师和原型开发人员（职位可以兼任） 第二步：快速展开产品设计（高保真原型），邀请真实的目标用户验证产品原型，迭代修改 第三步：随着迭代的深入，产品会渐趋完善，当确定产品原型后，再招聘程序员进行开发
阅读全文
摘要：瀑布式开发方法的基本原则 1、采用阶段式开发：软件开发过程被事先分成固定的几个阶段，撰写书面的需求说明文档、设计高层软件架构、设计低层细节、编写代码、测试、部署 2、采用阶段式评审：每个阶段结束后，对该阶段提交的成果进行评审，评审通过后才能进入下一阶段 瀑布式开发方法有正式和非正式两种形式 1、正式
阅读全文
摘要：十大秘诀 1、产品经理即是产品负责人，他代表了客户的需求，因而需要与产品开发团队保持密切的联系，协助督促开发进程，及时解决出现的问题 2、使用敏捷方法绝不等于省略产品规划。规划周期应该适度缩短，反复迭代，采用轻量级的机会评估方法替代冗长的市场需求文档 3、产品经理和设计师的工作进度应该比开发团队领先
阅读全文
摘要：产品出炉后切莫虎头蛇尾 急于“撤军”是项目管理和产品开发流程中的大忌，只要稍微延长项目周期，观察用户对产品的反应，效果就会有天壤之别。这样做投资之小、回报之高会令你瞠目结舌，绝非其他项目阶段可比 产品发布后的几天至一周内，所有项目成员应该留出时间作为快速响应阶段。这个阶段的主要工作是快速响应、处理产
阅读全文
摘要：避免更新产品导致用户反感 毫无征兆地更新不必要的版本会令用户产生反感。不是所有用户都喜欢新版本的产品。用户产生反感主要有几个原因 1、事前没有收到更新通知，用户觉得措手不及 2、用户没时间学习、适应新版本，产品公司也没有提供旧版本方便用户在过渡阶段使用 3、新版本无法正常运行 4、新旧版本不兼容（比
阅读全文
摘要：不是一味地添加功能 改进产品不是简单地满足个别用户的要求，也不能对用户调查的结果照单全收。能提高指标的功能才是关注的重点。应该找准方向，分析关键指标，有针对性地改进产品
阅读全文
摘要：物色测试者 1、如果你已经拥有一批特约用户，可以邀请他们参加测试 2、如果是企业级产品，同类产品的展销会是寻找目标用户的好去处 3、可以在分类信息网站上发布广告，征集测试者。征集要求可以写得笼统些，不必过于具体 4、如果是大众产品，可以邀请自己的亲朋好友参加测试，但要避开过于亲密的人和科技行业的从业
阅读全文
摘要：证明产品的价值、可用性、可行性 产品验证是指在正式开发、部署产品前，验证产品说明文档描述的产品是否符合预期要求 产品经理向产品团队提供最终的产品说明文档前，需要进行三项重要验证 1、可行性测试：明确在现有的技术条件下，能否成功开发出产品。邀请架构师和开发人员深度参与技术调研，寻找可行的方案。如果你的
阅读全文
摘要：消减功能还是延长工期 不要再试图定义最终产品，转而定义只满足基本要求的产品，简称基本产品 1、产品经理与设计师合作设计产品的高保真原型，这个原型只具备实现商业目标的最基本功能要求，以及良好的用户体验和吸引力。只设计基本功能的产品可以把复杂度降到最低，把开发时间减到最少 2、邀请一位开发人员参与设计原
阅读全文
摘要：先定义用户体验再动手开发 在软件开发过程中，有很多工作可以同时进行。比如，需求调研和产品设计（用户体验设计）、开发与测试 尽管如此，用户体验设计和软件开发就不能同时进行，原因有五点 1、与软件开发团队合作的人要记住一点：一旦产品进入开发阶段，再修改设计思路是非常困难的，而且越往后修改的成本越高。因为
阅读全文
摘要：理想的产品说明文档 1、产品说明文档应该完整地描述用户体验——不只是用户需求，还包括交互设计和视觉设计。用户需求和用户体验是密不可分的 2、产品说明文档必须准确地描述软件的行为 3、产品说明文档必须以某种直观的方式把产品信息和产品行为告诉所有人 4、产品说明文档应该可以修改。虽然进入开发阶段后，应该
阅读全文
摘要：理解目标用户 人物角色又称为用户特征记录（user profile），是指通过与用户沟通交流，确定典型的目标用户类型，在理解各类目标用户的特征的基础上建立的人物原型 为了发掘潜在的人物角色，产品经理必须深入参与创建人物角色的工作，尤其要亲自参加用户交流和用户调查。这项工作千万不能外包 人物角色的主要
阅读全文
摘要：常用的市场调研工具和方法 用户调查：第一，设计调查问卷需要技巧和经验，不是一件容易的事；第二，调查结果为获得解决方案提供了一要途径，但不是解决方案本身 产品使用分析：使用分析工具记录用户使用产品的行为，不断地观察学习，然后调整产品。应该明确告知用户分析工具只收集统计数据，不涉及用户隐私 数据挖掘：想
阅读全文
摘要：产品开发伙伴 为了解决两个问题——既深入洞察目标用户的需求，又赢得用户对产品的推荐，建议征集特约用户协助完成产品研发 在项目的开始阶段物色至少六位积极、活跃、乐于分享的目标户，要求是他们在产品的目标用户中具有一定影响力。至于他们是否使用过公司原有的产品并不重要，只要他们认为未来的产品可以解决他们手头
阅读全文
摘要：制定更及时、更可靠的产品决策 制定决策通常是既耗时又费力的，产品公司需要一套机制让决策者和相关人员及时作出明智的产品决策。成立产品评审团是最好的解决途径 组织产品评审团的难点在于既要为高管制定产品决策、监督产品流程提供透明的信息，又要避免高管插手干预产品团队的具体工作 产品评审团的工作目标 成立产品
阅读全文
摘要：确定什么最重要 产品原则是对团队信仰和价值观的总结，用来指导产品团队作出正确的决策和取舍。它体现了产品团队的目标和愿景，是产品战略的重要组成部分。从形式上看，它是一系列明确的、体现团队特色的产品价值准则 制定产品原则时容易出现两类错误。第一类是原则过于空泛，失去了指导作用。第二类是把设计原则误当成产
阅读全文
摘要：软件项目可以划分为两个阶段 探索产品阶段：弄清楚要开发什么产品（定义正确的产品） 在探索产品的阶段，产品经理负责分析各种创意，广泛收集用户需求，了解如何运用新技术，拿出产品原型并加以测试 从全局视角思考产品方向，兼顾短期需求和长期规划 总而言之，就是探索出兼具功能性与设计性的产品 开发阶段：开发该产
阅读全文
摘要：市场需求文档 大多数的公司产品选择权是由高管、市场部门、开发团队甚至是大客户，在这种情况下公司会跳过市场需求文档或是误写成产品规范文档，回避评估产品机会 在正常情况下，应该是由业务人员会撰写一份论证产品可行性的市场需求文档，描述待解决的问题 评估产品机会的十个问题 1、产品要解决什么问题？（产品价值
阅读全文
