要学习的语言。
厌倦了C、C++或Java?试试CLOS、Dylan、Eiffel、Objective-C、Prolog、Smalltalk或TOM。它们每一种都有不同的能力和不同的“风味”。用其中的一种或多种语言在家里开发一个小项目。WISDOM离合诗。
What do you want them to learn？
What is their interest in what you've got to say?
How sophisticated are they?
How much detail do they want?
Whom do you want to own the information?
How can you motivate them to listen to you?怎样维持正交性。
- 设计独立、良好定义的组件。
- 使你的代码保持解藕。
- 避免使用全局数据。
- 重构相似的函数。
- 应制作原型的事物。
- 架构
- 已有系统中的新功能
- 外部数据的结构或内容
- 第三方工具或组件
- 性能问题
- 用户界面设计
- 架构问题。
- 责任是否得到了良好定义？
- 协作是否得到了良好定义？
- 耦合是否得以最小化？
- 你能否确定潜在的重复？
- 接口定义和各项约束是否可接受？
- 模块能否在需要时访问所需数据？
- 调试检查清单。
- 正在报告的问题是底层bug的直接结果，还是只是症状？
- bug真的在编译器里？在OS里？或者是在你的代码里？
- 如果你向同事详细解释这个问题，你会说什么？
- 如果可疑代码通过了单元测试，测试是否足够完整？如果你用该数据运行单元测试，会发生什么？
- 造成这个bug的条件是否存在于系统中的其他任何地方？
- 函数的得墨忒耳法则：
某个对象的方法应该只调用属于以下情形的方法：
- 它自身
- 传入的任何参数
- 它创建的对象
- 组件对象
- 怎样深思熟虑地编程：
- 总是意识到你在做什么。
- 不要盲目地编程。
- 按照计划行事。
- 依靠可靠的事物。
- 为你的假定建立文档。
- 不要只是测试你的代码，还要测试你的假定。
- 为你的工作划分优先级。
- 不要做历史的奴隶。
- 何时进行重构：
- 你发现了对DRY原则的违反。
- 你发现事物可以更为正交。
- 你的知识扩展了。
- 需求演变了。
- 你需要改善性能。
- 劈开戈尔迪斯结：
在解决不可能解决的问题时，问问你自己：
- 有更容易的方法吗？
- 我是在解决正确的问题吗？
- 这件事情为什么是一个问题？
- 是什么使它如此难以解决？
- 它必须以这种方式完成吗？
- 它真的必须完成吗？
- 测试的各个方面：
- 单元测试
- 集成测试
- 验证和校验
- 资源耗尽、错误及恢复
- 性能测试
- 可用性测试
- 对测试自身进行测试
