1.选择商品化的技术
2.关注技术风险和市场风险
3.选择没有技术风险的想法
4.累积技术债务，快速将产品推向市场
5.仅当被黑了才重视安全
6.忘掉可扩展性
7.对好的想法说 “不”
8.没有笨重的语言
9.速度高于质量
10.用户体验高于用户界面
抽象化是一种非常的不同于模糊化的东西 … 抽象的目的并不是为了模糊，而是为了创造出一种能让我们做到百分百精确的新语义。
除数学外，对本土语言的异常的精通会是一个计算机程序员的最宝贵的财富。
程序应该是写给其他人读的，让机器来运行它只是一个附带功能。
性能的关键是精简，而不是一堆的优化用例。除非有真正显著的效果，否则一定要忍住你那些蠢蠢欲动的小微调的企图。
原型的价值就在于它对你的教育，而不是代码本身。
作者：周金银
博客：http://www.cnblogs.com/zhoujg/
原文下载地址：敏捷方法之Scrum v0.2原文下载
软件复杂度有三个主要因素：业务、技术和人员。《agile project management with scrum》（中文书名：Scrum敏捷项目管理）一书中有一个复杂度的图。
X轴表示技术（成熟度），Y轴表示业务（一致度）。从图中可以看到，业务和技术是正交的，各自对复杂度都有影响，我们在开发过程中需要做的通过各种办法尽量确保从Anarchy－Complex－Complicated－Simple进行转移。 技术和业务最终都需要人来执行，而每个人拥有不同的技能、经验和观点，当这些人在一起合作时又会使得开发过程变得复杂。
这些复杂性将导致开发过程中存在很多不确定性，所以项目初期制定的计划其实基本上不能真正的坚持下来。而当项目开发遇到困难时，项目组可能会为了表明自己做计划的能力，或者不想经历复杂的变更过程，而继续努力的坚持这个已经错误的计划。范围、时间和成本，这 个金三角几乎没有领导不知道，而项目组为了保证”遵循计划“，对外宣称项目组运行状况良好，保证当前人员在预计时间肯定能保质保量的完成开发。而代码质量 只有开发人员知道，领导们容易忽略和难以控制这个环节，所以最后一味的遵循计划就势必导致提供给客户的是一个不满意的产品。
Waterfall VS Agile
瀑布式开发是计划驱动的，合同谈判后项目组制定计划并且遵循计划，在过程与工具支持下通过面面俱到的文档来定义不变的需求和其他文档，在时间不够时可以通过增加人员来缓解压力。而敏捷开发是价值驱动，通过自组织团队在短期迭代过程中不断的交付对用后有用的功能来进行产品开发。从上图的正反三角形图形可以看出两者的驱动是不同的。
客户协作 胜过 合同谈判
虽然我们致力于客户协作，但为了双方利益和需要仍旧需要进行合同谈判。
响应变化 胜过 遵循计划
虽然我们致力于响应变化，但并不是像上面漫画所说的不需要计划了,反而我们需要更多的规划。不确定性是影响计划正确的主要因素，对大部分不确定而言，在获取知识、减少不确定性的唯一办法是通 过执行－作一些事情、构建一些东西或模拟一些东西－然后获得反馈。许多项目管理方法是“规划、规划。规划－执行”，而敏捷开发方法是“规划－执行－调 整”、“规划－执行－调整”。一个项目的不确定性越高，敏捷开发方法对取得成功就越是至关重要，不断学习和调整是敏捷开发的核心。
个体与交互 胜过 过程与工具
一个使用普通工具的优秀人员会比使用优秀工具的普通人 员做得更好，一个具有合作精神、自组织的团队比通过过程规范的团队工作得更好。敏捷项目首先拥有一个小规模但拥有各种不同职能的成员，每个成员都需要定时 和团队的其他成员一起查看团队的整体进度，计划下一步工作，并一起探讨所遭遇问题的解决方案。自组织团队通过个人能力和协作能力，可以自发的通过各种途径 解决开发过程中遇到的问题。
可以工作的软件 胜过 面面俱到的文档
虽然我们致力于提供可供做的软件，但并不是不要文档。我们在开发过程中仍然需要进行内部交流， 也需要和客户交流，我们仍旧可能需要制作原型，书写一些主要需求和算法，只要自组织团队认为足够就行了。
Scrum的核心在于迭代，整个过程只有三个角色。产品负责人的职责是利用产品backlog，督促团队优先开发具有价值的功能，并在其基础上继续 开发。产品负责人必须频繁检视产品代开发需求的优先级，以便将最具价值的功能安排在下一个迭代中完成。团队的责任是开发软件功能，他们是自组织团队，团队所有成员对每一次迭代和整个项目共同负责，不单做考核。Scrum Master则需要对Scrum过程负责，向所有项目参与者讲授Scrum方法，负责实施Scrum，确保它既符合企业文化，又能交付预期利益，还需督促 全体成员遵从Scrum规则和实践。
Prodcut Backlog
产品backlog根据用户价值罗列所有即将在产品中开发的功能，通过简洁的展示需要实现的功能，我们可以对项目进行规模上的估算，确定发布计划和迭代计划。
Product backlog应该由Product Owner来制定
怎么拆分故事
很大的故事基本上都能进行拆分，只要确定每个小故事莹然可以交付业务价值就行。注意在这里不要把故事拆分到任务，故事是可以交付的东西，是产品负责人所关心的，而任务是不可交付的东西，产品负责人对它并不关心，任务是在sprint计划会议上拆分的。
Scrum被认为是目前全球最流行与最有效的敏捷项目管理理念与方法之一，在软件业发达地区被众多知名企业广泛采纳。本书是Scrum理论与实践的重要奠基之作，作者是Scrum的缔造者，深受软件行业人员尊重的敏捷大师。本书详细描述如何在复杂技术项目中使用 Scrum，并结合真实的Scrum案例及专家洞识，在简明及高度概括的理论之上更侧重于实践，并不断强调Scrum原则的坚持及实践的灵活性。
此书探索Scrum的每一方面，包括科学原理、伞新的项目角色及责任、ScrumMaster、产品负责人、如何有效管理未知因素和不断变化的产品需求、如何结束混乱、如何计划和报告、及如何扩展项目团队规模等，并着重于如何驱动项目以实现最高的投资回报。
Scrum的核心价值观是：承诺、专注、公开、敬重和勇气。它提倡自我管理、涌现机制、可视性和评估/适应循环的根本原则。
在黄昏里希冀皓月与繁星
在深夜希冀着黎明
在炎夏希冀凉秋
在严冬又希冀新春
这不断的希冀啊，
使我感触到世界的存在，
带给我多量的生命的力。
这样，
我才能跨过——
这黎明黄昏，黄昏黎明，春夏秋冬，秋冬春夏的茫茫的时间的大海啊。
项目复杂程度越高，便越需要将决策权委派至工作前线的独立个体。
Scrum能有效运作的另一个原因在于，它可以就一个问题集思广益。
Scum将小型团队转化为自身命运的管理者。
Scrum团队接受挑战，找寻应对挑战的方法，发挥创意，避开工作障碍，而这一切都无法由中央控制及调度系统预先安排。
如果团队规模合适，能激发各成员的参与积极性，同时团队成员能意识到他们对自身命运的掌控，那么各成员的经验，意见和想法便可以充分利用，而非遭到压制。
产品负责人应引导团队工作以实现企业最大价值。这类工作不仅包括将最高优先等级的产品Backlog转化为功能，还应坚持工程惯例和标准。
未能促使改进的评审会议是成果贫乏且令人沮丧的。
ScrumMaster负责扫除开发团队、产品负责人和客户之间的障碍，确保客户能直接推动开发工作。ScrumMaster的另一个职责是告诉产品负责人，如何利用Scrum使项目投资回报最大化，达成项目目标。
Scrum基于协作需要理解，也即顺畅的交流。若产品负责人只谈商业，团队只谈技术，双方无法交流，也就没有协作。
Scrum的生产力源于：首先选择正确事项，然后高效完成选定事项。
团队从被管理到自我管理的转变过程十分困难，但在生成力和工作愉悦度方面的回报显著。
ScrumMaster的职责不是管理团队，他们应学会自管理，不断调整方法，提高成功机会。
瀑布式开发过程使人际互动和面对面交流最小化，产生隔离。该过程强调人际书面交流，但团队需要广泛的交流，以减少误解和后继错误。成员不仅被办公场所隔离，其工作与互动也因开发过程而隔绝。
而敏捷里面所有的实践，质量是隐含的，不可侵犯的.这就是我们所说的Built Quality In.比如，刚开始写Story, 就要和测试人员定义验收条件；开发Story采用TDD的方式，通过测试来检验功能，类似于砌墙的时候先扯水平线，然后开始铺砖.
整个团队只有一个目标：产生高质量的交付
在此目标之下，以尊重 交流 反馈 勇气 简单为基本做事价值观和原则.
Agile Versus Waterfall: Part One
丰田精益生产方式中一个经常用的隐喻是“湖水和岩石”。大意是指湖水太深，你无法发现阻碍当前生产的主要原因，只有把湖水讲下去，才能发现真正的岩石在哪里。在精益生产中，湖水是指“库存”，而在软件开发中，对应的湖水则是“迭代周期”。
我们举一个例子，当发现“项目严重延期”时，通常已经是交付时间，不过开发人员最近一直加班，也挺辛苦的呀。不过如果你是项目经理或者客户，你知道开发人员的时间都花到哪儿了吗？如果采用迭代式交付，每两周一个迭代，完成一定的特性，你可能第一个迭代就发现问题我们可以抱怨团队开发人员能力不够，不过这关敏捷的什么事儿？本来大家都知道的事情，只不过敏捷让它暴露的更严重更突出罢了，谁还会任由你“掩耳盗铃”呢。
JavaScript Debugging Techniques in IE 6
Top 10 (not so popular) Eclipse Shortcuts
Design Patterns Uncovered: The Flyweight Pattern
When considering this pattern, you will need to think about intrinsic and extrinsic data. Intrinsic data is the data that makes this object instance unique. Meanwhile, extrinsic data is information that can be passed in through arguments. So, if you can make some data extrinsic for cases that you have a large number of objects, the Flyweight pattern may be exactly what you are looking for.
Flyweight模式的几个要点：
1、面向对象很好的解决了抽象性的问题，但是作为一个运行在机器中的程序实体，我们需要考虑对象的代价问题。Flyweight设计模式主要解决面向对象的代价问题，一般不触及面向对象的抽象性问题。
2、Flyweight采用对象共享的做法来降低系统中对象的个数，从而降低细粒度对象给系统带来的内存压力。在具体实现方面，要注意对象的状态处理。
3、对象的数量太大从而导致对象内存开销加大（这个数量要经过评估，而不能凭空臆断）
但创建了一个SOA，自底向上的治理方法关注围绕单独ESB的集成化服务，这些ESB 可以快速装配。该方法因为需要过多的更新和重做而受到非难。
同时，相对的“自顶向下”的治理方法涉及大量严格规划和精确策略执行。这种方法也由于花费过多的时间才能产生结果而不被认可。
企业接受SOA的速度比较慢，大多数接受者倾向于接受自底向上的方法。
随着人们开始实施SOA，自身的技术就不够用了，这时就需要一些治理来辅助
Hariharan最后讲到：“如果企业以一种长期的愿景和蓝图来寻求SOA，那么自顶向下的方法是最佳的选择。如果并没有一项企业级的IT 策略以及长期的愿景，IT 可以选择自底向上的方法来实现和展示SOA的好处。”
scp 本地用户名@IP地址:文件名1 远程用户名@IP地址:文件名2
拷贝文件夹命令如下：scp -r file username@ip:filepath
多加上一个-r参数即可。
Product Backlog: 可以预知的所有任务， 包括功能性的和非功能性的所有任务。已划分有限等级的项目需求清单，标有将其转化为完整产品功能的预估时间。以天为单位，条目在产品Backlog中优先等级越高，预估值越精确。清单随业务和技术条件的变化而改变。
Product BlackLog Item：包括功能和非功能性需求及其他议题。按业务和依赖性的重要程度划分优先级，并做出预估。预估值的精确度取决于BlackLog Item条目的优先等级和细致程度，入选下个Sprint的最高优先等级条目的预估会非常精确。
Sprint:一次跌代开发的时间周期，一般最多以30天为一个周期.在这段时间内，开发团队需要完成一个制定的backlog,并且最终成果是一个增量的，可以交付的产品。
Increment（增量）： 团队在每个Sprint中开发出的产品功能。
Iteration（迭代）：项目中的一个周期。Scrum中，该周期为30个连续日历日，或者一个Sprint.
Done(完成)：“完成”状态需要项目各方认同，且符合组织的标准、惯例、和指导方针。每日Scrum简会或Sprint评审会议上汇报为“完成”的产品，必须符合该协商通过的定义。
Sprint Backlog:一个sprint周期内所需要完成的任务，定义团队在Sprint中的任务清单，在Sprint过程中形成，每项任务信息包括负责人及其在Sprint中任一天时的剩余工作量。
Sprint Backlog任务：团队或其成员为把产品Blacklog条目转化为系统功能所需完成的任务。
ScrumMaster: 负责监督整个Scrum进程，修订计划的一个团队成员。
Time-box: 一个用于开会时间段。比如每个daily scrum meeting的time-box为15分钟。
Sprint planning meeting: 在启动每个sprint前召开。一般为一天时间（8小时）。该会议需要制定的任务是：产品Owner和团队成员将backlog分解成小的功能模块, 决定在即将进行的sprint里需要完成多少小功能模块，确定好这个Product Backlog的任务优先级。另外，该会议还需详细地讨论如何能够按照需求完成这些小功能模块。制定的这些模块的工作量以小时计算。
Daily Scrum meeting：开发团队成员召开，一般为15分钟。每个开发成员需要向ScrumMaster汇报三个项目：今天完成了什么？ 是否遇到了障碍？ 即将要做什么？通过该会议，团队成员可以相互了解项目进度。
Sprint review meeting：在每个Sprint结束后，这个Team将这个Sprint的工作成果演示给Product Owner和其他相关的人员。一般该会议为４小时。
Sprint retrospective meeting：对刚结束的Sprint进行总结。会议的参与人员为团队开发的内部人员。一般该会议为３小时
http://www.thoughtworks-studios.com/mingle-agile-project-management
When a team adopts Scrum or Agile, management too often buys an "Agile Tool", and expects it to drive the team. Unfortunately, people drive Agile, not tools. Tools support the effort, not the other way around.
If you’re wanting to drive Agile adoption, you’ve got to be sure your team trained and share your motivations with them. If management is driving Agile adoption, it’s to address some type of pain. Either they don’t know what your team is doing and they want insight to the development lifecycle, or they need to get a smaller feature set to market more often, or they want to boost quality. Whatever the motivations, they need to share them with the team.
这是《软件开发沉思录》这本书阅读笔记的第二篇，第一篇是软件开发沉思录阅读笔记一是对第六章——对象健身操的阅读笔迹。
什么是迭代经理？
ThoughtWorks的高级架构师Fred George把迭代经理描述成“面向内部的管理角色。迭代经理负责保证故事在团队中流动的顺畅，这牵涉到合理分配任务、在技能需要改变的时候建议更换团队成员。”
怎样成为好的迭代经理？
每天，迭代经理都必须倾听团队的需要并且作出回应。其主要职责就是培养一台润滑良好的“机器”，并依据要求的质量在项目范微内交付功能。
迭代经理应该在技术熟练度和业务知识之间达到一个平衡。敏捷领袖应该“同时对客户和技术都由深刻的理解，这样才能赢得开发团队的尊重。”良好的沟通技巧是必须的。迭代经理的职责之一就是维护开团队与客户，以及与管理阶层之间的关系。
同时，迭代经理必须推动、主张和保障团队成员的权利。
迭代经理不做什么？
与项目经理不同，迭代经理需要在工作第一线，与团队成员一起面对每日的工作活动。
迭代经理与项目
作为次要目标，我期望看到因为迭代经理的工作，团队成员在项目结束的时候变得更为优秀。团队内充满信任，持续提高技能——这是迭代经理的工作。
迭代经理要争取把团队拧成一根绳，让所有的成员能同舟共济。
在过去十年里，众多软件开发者意识到：软件应用程序中最大的复杂度来自于软件要处理的实际问题领域。正因为如此，所谓“领域驱动设计”有两个前提：
换句话说，领域驱动设计将用业务领域术语表述的业务领域的面向对象模型置于软件系统的核心。数据通常保存在关系数据库里，但看待数据的主视角是领域对象，而不是数据库表和存储过程。核心业务逻辑集中保存在领域模型中，而不是散步在用户界面和应用程序的服务层里。
如果遵循领域驱动设计方法，得到的软件系统就会清晰地区分出领域模型和基础设施（及界面）：前者通常较为稳定、生命周期较长；后者通常生命周期较短，并且与具体的技术（例如O/R映射或者WEB框架）相关。这里的挑战在于如何保持两者之间的分野，从而使两者能够各自保持可复用性：一方面，领域模型应该能够在不同的应用程序、不同的服务中使用，或是在技术升级以后继续使用；另一方面，基础设施应该能用于支撑各种领域模型。当然最终的目标是实现基础设施的行业标准化（无论是采用商用软件还是开源软件），从而使应用程序开发者能专注于问题领域。
- 让整个小组参与。
- 在不同层次上进行规划。
- 使用不同度量单位，让对规模和持续时间的估计保持独立。
- 用功能或者日期来体现不确定性。
- 经常重规划。
- 跟踪进度并沟通
- 承认学习的重要性。
- 规划具有适当规模的功能。
- 确定功能优先级。
- 把估计和计划建立在事实上
- 保留一些松弛度。
- 通过前瞻规划协调做个小组。
- 缺乏技术实践:Scrum是一个项目管理框架，在技术方面没给任何建议。Bob建议团队“需要从其他诸如XP的方法中借鉴技术实践。这套技术实践可能包括：TDD、持续集成、验收测试、结对编程、重构。”
- 30天的冲刺周期太长：多数讲师现在建议冲刺周期1-2周，大多数团队采用的是2周。
- Scrum教练有时变成了项目经理:有些Scrum教练把Scrum当作微管理和控制的一种形式。“这不是Scrum固有的问题，而是Scrum发展中遇到的问题。或者这要怪‘master’这个单词了。”
- 对产品Backlog的指导太少：“经过多年实践，我们知道了backlogs有很多分层次的实体，包括史诗、主题、故事等等。我们学会了怎么对它们估计；学会了怎么把高层次的实体拆解成低层次：史诗->主题->故事->任务。”
- Scrum暗中包含反管理：“Scrum过度强调了团队自管理的角色。自组织和自管理的团队本身是好的,但是具有局限性…Scrum的描述并没有给与很好的平衡。”
- 自动化测试：没有高质量的自动化测试，很难以短的迭代周期工作，很难知道故事是否真的做完了。
- 多团队：Scrum和通用的敏捷方法很少谈及怎样扩展，虽然很多实践者有一些想法，但是还没有达成广泛的一致。
Composition versus Inheritance
Programming to an Interface, Not an Implementation
Creational Patterns Considered Obsolete
Inversion of Control Containers
Composition Realized
[Inheritance] can cause problems when you’re trying to reuse a subclass. Should any aspect of the inherited implementation not be appropriate for new problem domains, the parent class must be rewritten or replaced by something more appropriate. This dependency limits flexibility and ultimately reusability.Object composition is defined dynamically at run-time (at startup, config-time in most IoC containers –Chad) through objects acquiring references to other objects. Composition requires objects to respect each others’ interfaces, which in turn requires carefully designed interfaces that don’t stop you from using one object with many others. But there is a payoff. Because objects are accessed solely through their interfaces, we don’t break encapsulation. Any object can be replaced at run-time by another as long as it has the same type. Moreover, because an object’s implementation will be written in terms of object interfaces, there are substantially fewer implementation dependencies (!!! Very important –Chad)
Object composition has another effect on system design. Favoring object composition over class inheritance helps you keep each class encapsulated and focused on one task. Your classes and class hierarchies will remain small and will be less likely to grow into unmanageable monsters. On the other hand, a design based on object composition will have more objects (if fewer classes), and the system’s behavior will depend on their interrelationships instead of being defined in one class (configured and managed by the IoC container –Chad).
看似普通的Tag其实有着丰富的哲学含义
The study found that iterative and agile practices have a significant impact on defect and productivity factors, as indicated by the following points.
- Releasing a system with 20% of the functionality complete is associated with a decrease in the defect rate of 10 defects per month per million lines of code as compared to waiting to release a product until 40% of the functionality is complete, and an increase in productivity of eight more lines of source code per person-day.
- Continuous Integration, the idea of integrating and testing code as it is released to your source code repository, resulted in a decrease in the defect rate of 13 defects per month per million lines of code, and an increase in productivity of 17 lines of source code per person-day.
The first two are deeply embedded in the ideals of agile software development.
- Releasing early and often to project stakeholders, using an iterative lifecycle.
- Continuous integration, with daily builds including regression testing.
- Teams with broad experience delivering multiple projects.
- Careful attention to modular and loosely coupled, componentized architectures.
An (Overlooked?) Use Case for the Strategy Pattern
