扯淡软件开发

声明: 本篇尤其扯淡,谨慎阅读。


多希望软件设计也可以如欧式几何一般,建立完备的公理体系。这样软件设计和工程或许就真正的可以称之为一门新“科学”了。

公论

  1. 未来需求不可完全预知

  2. 软件变化的可能性正比于存在时间

  3. 引入缺陷的可能性正比于代码变化量

  4. 代码被阅读的次数大于编写和修改的次数

定论

  1. 保持简洁

基于c.

  1. 保持可读性

基于d.

  1. 少做变化

基于c.

  1. 降低维护成本比降低开发成本更重要

基于d.

  1. 保持开闭

基于c. 代码增加开放,代码修改闭合。

推论

  1. 软件的代码量应当尽可能少

基于c. 少的代码量在面对变化时,发生的修改量就低,引入缺陷的可能性就低。

  1. 尽量删除当前不需要的代码

基于1.

  1. 不要有重复的代码

基于1.

  1. 避免过早设计

基于a.

  1. 避免太过通用

基于a.

  1. 避免过早优化

基于a.

  1. 渐进式设计和开发

基于a.