随笔一：什么是软件工程

变成与软件工程之间三个关键差一点：时间、规模、权衡。

• 关注时间的流失和可能的需求变更
• 关注规模和效率
• 做出更多复杂且高风险的决策（这是由于对时间和增长的不精确估计导致的）

如果在软件的预期生命周期内，无论是处于技术理由还是业务理由，你都有能力对任何有价值的变化作出反应，那么你的项目是可持续的。

团队组织、项目构成以及软件项目的政策和实践都决定着软件工程的复杂性。

在软件工程中，我们经常被迫在不同方向之间进行权衡，时常伴随着高风险以及价值度量指标的不完善。

可持续性要求对所需变更的影响进行持续的规划和管理。

软件工程需要保持长期的可维护性。

海勒穆定律：

　　当一个API有足够多的用户时，在约定中你所承诺的已不重要，所有在你系统里面被观察到的行为都会被一些用户所依赖。

案例：哈希排序

　　大部分人都知道哈希表不能保证元素的排列顺序，但只有少数人知道其中所用的默认周特定的哈希表其实永远会使用一定固定的排序。

　　这里案例可以说明了“可工作”和“正确性”的区别。

 

阻碍规模化的政策

　　如果一个老的插件已经被很多人使用了，团队希望使用一个新的插件替换它，这里涉及到很多使用老插件的团队，这种情况下想要替换是很苦难的，很难推动每个使用方及时准确的替换，那我们可以换一种思路：团队不必把迁移工作推给相关依赖的团队，而是利用规模化的能力在团队内部解决这个问题。

　　有一个特定的专家组执行大规模变更，要比要求每个团队自己来做这种变更会更具有可扩展性。

 

促进规模化的政策

　　专业知识和共享的交流轮胎在组织规模化上提供了巨大的价值。

左移思想

　　在开发人员工作流的早期发现问题通常会降低成本。

• 安全性不能推迟到开发过程结束才检测
• 在开发早期提供强调质量、可靠性和捕获异常的缺陷比发布之后成本低很多。

权衡和成本

　　任何话题都要有一个决策者，当决策错误时需要有明确的升级路径，目标是“达成共识”、而不是“一致同意”。

 

决策投入

　　决策时有一下两种情况：

• 所涉及的全部工程量都是可测量或者至少可以估计的
• 有些工程量很微妙，或者我们不知道如何衡量

　　第一种情况，我们没有理由做不好

　　第二种情况，我们依靠经验、领导才能、先例来协商这些问题。

 

数据驱动决策

　　我们基于某个时刻的可用数据做决策，并且期待这些数据是良好的且只有较少的假设，但实际上这些数据也仅仅是当前可用的数据而已。

　　以证据为导向，但也要意识到，无法度量的东西可能仍然有价值。