这是《软件开发沉思录》这本书阅读笔记的第二篇，第一篇是软件开发沉思录阅读笔记一是对第六章——对象健身操的阅读笔迹。
第七章——迭代经理是什么角色
什么是迭代经理？
ThoughtWorks的高级架构师Fred George把迭代经理描述成“面向内部的管理角色。迭代经理负责保证故事在团队中流动的顺畅，这牵涉到合理分配任务、在技能需要改变的时候建议更换团队成员。”
怎样成为好的迭代经理？
每天，迭代经理都必须倾听团队的需要并且作出回应。其主要职责就是培养一台润滑良好的“机器”，并依据要求的质量在项目范微内交付功能。
迭代经理应该在技术熟练度和业务知识之间达到一个平衡。敏捷领袖应该“同时对客户和技术都由深刻的理解，这样才能赢得开发团队的尊重。”良好的沟通技巧是必须的。迭代经理的职责之一就是维护开团队与客户，以及与管理阶层之间的关系。
同时，迭代经理必须推动、主张和保障团队成员的权利。
迭代经理不做什么？
与项目经理不同，迭代经理需要在工作第一线，与团队成员一起面对每日的工作活动。
迭代经理与项目
作为次要目标，我期望看到因为迭代经理的工作，团队成员在项目结束的时候变得更为优秀。团队内充满信任，持续提高技能——这是迭代经理的工作。
迭代经理要争取把团队拧成一根绳，让所有的成员能同舟共济。
第十章——领域标注
在过去十年里，众多软件开发者意识到：软件应用程序中最大的复杂度来自于软件要处理的实际问题领域。正因为如此，所谓“领域驱动设计”有两个前提：
- 大部分软件项目关注的焦点是业务领域和领域逻辑；
- 复杂的领域设计应该基于模型来进行。
换句话说，领域驱动设计将用业务领域术语表述的业务领域的面向对象模型置于软件系统的核心。数据通常保存在关系数据库里，但看待数据的主视角是领域对象，而不是数据库表和存储过程。核心业务逻辑集中保存在领域模型中，而不是散步在用户界面和应用程序的服务层里。
如果遵循领域驱动设计方法，得到的软件系统就会清晰地区分出领域模型和基础设施（及界面）：前者通常较为稳定、生命周期较长；后者通常生命周期较短，并且与具体的技术（例如O/R映射或者WEB框架）相关。这里的挑战在于如何保持两者之间的分野，从而使两者能够各自保持可复用性：一方面，领域模型应该能够在不同的应用程序、不同的服务中使用，或是在技术升级以后继续使用；另一方面，基础设施应该能用于支撑各种领域模型。当然最终的目标是实现基础设施的行业标准化（无论是采用商用软件还是开源软件），从而使应用程序开发者能专注于问题领域。
敏捷
敏捷估计和规划的12条指导原则
- 让整个小组参与。
- 在不同层次上进行规划。
- 使用不同度量单位，让对规模和持续时间的估计保持独立。
- 用功能或者日期来体现不确定性。
- 经常重规划。
- 跟踪进度并沟通
- 承认学习的重要性。
- 规划具有适当规模的功能。
- 确定功能优先级。
- 把估计和计划建立在事实上
- 保留一些松弛度。
- 通过前瞻规划协调做个小组。
Bob大叔关于Scrum和敏捷的7条缺陷
- 缺乏技术实践:Scrum是一个项目管理框架，在技术方面没给任何建议。Bob建议团队“需要从其他诸如XP的方法中借鉴技术实践。这套技术实践可能包括：TDD、持续集成、验收测试、结对编程、重构。”
- 30天的冲刺周期太长：多数讲师现在建议冲刺周期1-2周，大多数团队采用的是2周。
- Scrum教练有时变成了项目经理:有些Scrum教练把Scrum当作微管理和控制的一种形式。“这不是Scrum固有的问题，而是Scrum发展中遇到的问题。或者这要怪‘master’这个单词了。”
- 对产品Backlog的指导太少：“经过多年实践，我们知道了backlogs有很多分层次的实体，包括史诗、主题、故事等等。我们学会了怎么对它们估计；学会了怎么把高层次的实体拆解成低层次：史诗->主题->故事->任务。”
- Scrum暗中包含反管理：“Scrum过度强调了团队自管理的角色。自组织和自管理的团队本身是好的,但是具有局限性…Scrum的描述并没有给与很好的平衡。”
- 自动化测试：没有高质量的自动化测试，很难以短的迭代周期工作，很难知道故事是否真的做完了。
- 多团队：Scrum和通用的敏捷方法很少谈及怎样扩展，虽然很多实践者有一些想法，但是还没有达成广泛的一致。
Agile Methodology Mashups
- Pair Programming
- Daily Scrum/Standing Meeting
- Kanban/Burn Down Charts
- Test First Development
敏捷开发中高质量 Java 代码开发实践
OOD & OOP
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).
其他
Tags,无序,分类和家族相似
看似普通的Tag其实有着丰富的哲学含义
