谈下程序相关的几个因素, 是否符合需求, 可扩展性, 性能.
是否符合需求
我认为是否符合需求是第一位的, 如果一个程序做的不符合需求, 就没有意义. 由此可见, 需求定义的重要性.
产品研发中, 提出了MVP(最小可行产品)的原则, 是指开发团队通过提供最小化可行产品获取用户反馈，并在这个最小化可行产品上持续快速迭代，直到产品到达一个相对稳定的阶段。
项目开发, 也提倡敏捷开发, 提出用户的需求并不是在一开始就确定的, 而是在开发出一部分功能后, 逐渐有更清晰的想法的. 所以鼓励用户参与开发的过程, 将整个开发分成多个小部分开发.
可扩展性
可扩展性, 是由设计决定的. 在对系统做可扩展性设计时, 需要区分需求, 哪些是易变的, 哪些是不易变的, 将易变的留出空间来, 就是可扩展性设计.
同时, 软件工程也很大的影响了可扩展性的实现.
可扩展性在前期, 显得不那么"重要", 但是需求不断膨胀的情况下, 用多少人力多少时间去实现一个新功能, 就是很重要的指标. 这时"可扩展性"尤其重要.
可扩展性不好的应用, 不光添加新功能实现起来慢, 还有可能导致扩展时出现错误, 如改动一个设置, 需要同时修改另外5个地方, 这样开发人员很容易漏掉其中1~2个地方, 导致调整出错.
性能
在小项目中, 性能显得不那么"重要". 在用户数量不大时, 且数据总量不大的情况下, 基本性能就可满足用户需求. 但是在个别场景, 性能需要进行额外优化.
但是大项目中, 受到大数量的用户影响, 数据总量巨大的情形下, 不优化的前提下, 很多操作性能都变得很地下, 导致无法满足用户需求. 这就需要对架构重新规划, 光优化部分功能, 可能都无法满足用户的需求.
总结
所有的这些无非就一个目的, "不断地(可扩展)满足用户需求(性能)". 这个过程, 不是一蹴而就的, 要一步一步来. 首先要评估当前需求, 即需要满足多少用户多少数据量的场景, 再进行可扩展性和性能的设计. 当用户暴涨之后, 需要再度评估系统的容量, 进行设计.