好玩的网站列表

1. 注重实效方法论

1.1 高效习惯

• 不要害怕发生问题，不要推卸责任
• 对于一个事情是否能做到，提供各种选择，而不是借口
• 不要留着破窗户(低劣的设计，错误决策，糟糕代码)，将出问题的代码放入注释是个不错的选择。
• 参与正在发生的成功要更容易些，让他们瞥见未来，他们就会聚集在你的周围。

1.2 知识资产

管理知识资产和管理金融资产非常相似：

• 严肃的投资者定期投资 —— 作为习惯
• 多元化是长期成功的关键
• 聪明的投资者在保守的投资和高风险、高回报的投资之间平衡其资产
• 投资者设法低买高卖，以获取最大回报
• 应当周期性重新评估和平衡资产

1.3 交流

• 知道想说什么，有大纲
• 了解听众
• 让文档美观
• 让听众参与

2. 注重实效的途径

2.1 重复

DRY - Don’t repeat yourself!

在不同的地方写相同的东西那在修改的时候就不能忘记每一处的修改，这是很crazy的做法了

2.2 重复的发生

2.2.1 强加的重复 - 似乎是环境要求

2.2.2 无意的重复 - 没有意识到

• 注意数据之间的相互重复，如果有某个量值是可以通过其他数据计算得出的，那么就应该用计算得出的值
• 而由于性能原因，做cache引起的重复，需要将影响局部化，不要将其暴露给外界
• 像Java这样的面向对象的语言应当总是使用访问器函数来读写对象的属性

2.2.3 无耐性的重复 - 偷懒

2.2.4 开发者之间的重复 - 同一团队的几个人重复了同样的信息

• Make it easy to reuse

2.3 正交性

表示一种互不依赖，解耦性。指几个子系统之间互不依赖，例如数据库代码与用户界面代码应该为正交的

Eliminate effects between unrelatd things

使基础知识和应用分离，每个主要的基础设施组件(数据库、通信接口、中间件层)有自己的子团队

2.4 设计

做一个正交系统，关键指标！

• 模块化
• 基于组件
• 分层

系统应该是由一组相互协作的模块组成，每个模块都实现不依赖于其他模块的功能。

通过分层使得每层都只使用在其下面的层次提供的抽象，在改动底层实现，而又不影响其他代码方面，就会有极大的灵活性了。

对于正交性组件的测试方法 -> 如果我显著改变某个特定功能背后的需求，有多少模块会受到影响呢？ 需要是一个！

2.5 编码

• 让代码保持解耦
  • 不会没必要的想其他模块暴露任何借口
• 避免使用全局数据
• 避免使用相似的函数

There are no final decisions

2.6 原型与便签

原型不需要总是以代码为基础，要看需求。比如为工作流和应用逻辑这样的动态事物制作原型，便签就非常好。用户界面的原型可以使白板上的图形，或者是永辉图程序或者界面构建器绘制的无功能的模型。

原型设计的目的就是为了去回答一些问题的，一些不在意的方面就可以不去管它。

2.6.1 什么时候使用原型

• 应制作原型的事物
  • 架构
  • 已有系统中的新功能
  • 外部数据的结构或内容
  • 第三方工具或组件
  • 性能问题
  • 用户界面设计

2.6.2 怎样使用原型

可以忽略一些细节

• 正确性
  • 可以使用虚设的数据
• 完整性
  • 原型也许只能在非常有限的意义上工作，也许只有一项预先选择的输入数据和菜单项
• 健壮性
  • 错误检查可能会非常不完整，或者完全没有
• 风格
  • 可能没有多少注释或者文档

2.6.3 如何制作架构原型

• 在架构原型中寻求解答的一些问题
  • 主要组件的责任是否得到了良好的定义？ 是否适当？
  • 主要组件之间的协作是否得到良好的定义？
  • 耦合是否得以最小化？
  • 是否能确定重复的潜在来源？
  • 接口定义和各项约束是否可接受？
  • 每个模块在执行过程中是否能访问到其所需的数据？ 是否能在需要时进行访问？

---

转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 stone2paul@gmail.com