欢迎关注公众号
微信公众号：数据分析指北
数据分析指北 - 附录三 软件的成本，数据分析的成本
历史回看：
数据分析指北 - 前言(03)
数据分析指北 - 基础(基础数据操作之三，从完备到 基础操作 select)
数据分析指北 - 附录一 数据分析工具漫谈
*Photo by rawpixel on Unsplash*
软件的成本，数据分析的成本
大体上来说，在市场上销售的软件产品和其他产品并没有本质的不同，总成本是由设计成本，生产成本，维护成本，营销成本四大类组合而成的。只不过在软件行业中，或者在所有需要软件的行业中，软件的成本组成有着较大的差异。
拿一个非软件行业的产品 -- 电视机来举例，有人喜欢买大米电视，有人喜欢买锁尼电视，花同样的钱，他们买到的产品是不一样的。（以下只是虚无缥缈的举例，并无实际数据支撑）也许大米电视的硬件性能更好，原料成本，生产成本更高，但假如大米电视的故障率要比锁尼电视的故障率高的话，那么大米电视的维护成本也会高一些，如果锁尼在外观，屏幕，声音系统较大米电视好，那么锁尼电视在设计成本上会高一些。而营销成本则取决于产品的定位以及市场，营销人员的具体操作了，略过不提。
软件成本也很类似，对于不同的软件，成本的组成也是不一样的。对于复杂程度不高的（类）一次性软件，比如，软件公司如果要向某某机构兜售只有新闻等简单功能的网站，那么总成本有很大一部分需要分配在营销上，其他方面就可以相对减少；对于一个需求变动比较大的软件，那么设计成本，生产成本和维护成本就要占据大头，其中软件的内在设计是最最重要的，如果设计的好，那么生产成本和维护成本都可以显著降低，如果设计的的不好，那么，生产成本和维护成本就会急剧上升，而且对于越大的，设计越不好的项目，生产成本和维护成本会上升的更快。
软件的错误在表现形式上可以分为两类，一类是 bug -- 指显著表现出来的程序错误，另一类是缺陷，大部分情况下，它是隐藏状态，只有在特定的情况下，缺陷才会被触发，变成bug。可以说，缺陷是未发现的bug，或bug是已经发现了的缺陷。假如一个软件由三个部分构成，因为设计或编码生产的问题，这三个部分的固有缺陷都是2个，看上去不太多对吗？但实际上，如果缺陷被触发，那么程序表现出来的异常可能有4*4*4-1种组合（对吗？=P），这也是为什么有时会觉得，只是新增了一个模块，怎么一下子出现了这么多莫名其妙的异常。
也正是因为这种乘数效应，所以程序中大到模块，小到函数，都鼓励写成高内聚，低耦合的方式，并在"尽可能简单，而不过于简单"的总体思路下进行设计。锻炼良好的判断力和品味应该是每一个程序设计者所追求的。
软件行业中的很多活动其实可以理解为，它们都是围绕着降低成本来运行的。比如，敏捷开发是近些年很流行（且被滥用）的概念，它的主导思想是以用户尽量独立的"小需求"为核心，采用迭代，循序渐进的方法进行软件开发，它其实就是把总成本划分成了若干"小需求"成本，每个"小需求"成本中，又使用迭代开发这种方式来降低开发成本，提升开发质量以降低维护成本；还有TDD，BDD等开发模式，也是在开发成本和维护成本上下功夫；再比如软件文档，命名规范等都是为了减少维护成本而适当增加开发成本，用以达到降低总成本的目的。
当你自己需要做一款软件，或是分析数据时，成本也是你重点考虑的内容，如果这个任务是一次性使用的，那么你应该有一套方案，如果这个任务是要经常做的，或者这个任务会不停的变动内容，那么你需要另外不同的方案。
如果你在一个任务不停变动（需求在不停变动）的时候选择了一个一次性的解决方案，那么你这套解决方案在后期的维护成本可能会非常巨大，甚至导致这个解决方案完全无法使用，需要全部推倒重来。而在整个过程中，除了一些金钱成本之外，你浪费了你最重要的时间成本。What A Sad/Bad Thing。
数据分析，机器学习在工程上来看，和软件开发并无二致，而且是一种特定类型 -- 需求和行动变动的都比较频繁的软件开发。所以，以上的软件成本理论，完全可以应用在数据分析以及机器学习上，对于个人来说，除去一些微不足道的金钱成本之外，唯一需要考虑的就是自己最宝贵的时间，自己的时间怎么在这些方面分配，是一个需要持续思考和改进的问题啊。
回头聊
反馈，转发或赞赏？
网友评论