软件开发为什么很难
问题的分类 最初在1999年被Dave Snowden开发出来的**Cynefin框架**尝试把世界上的问题划分到了5个域中（大类）： 简单（Simple）问题，该域中的因果关系非常明显，解决这些问题的方法是 感知-分类-响应（Sense-Categorise-Respond），有对应的最佳实践 复合（Complicated）问题，该域中的因果关系需要分析，或者需要一些其他形式的调查和/或专业知识的应用，解决这些问题的方法是感知-分析-响应（Sense-Analyze-Respond），有对应的好的实践 复杂（Complex）问题，该域中的因果关系仅能够从回顾中发现，解决这些问题的方法是探索-感知-响应（Probe-Sense-Respond），我们能够感知涌现实践（emergent practice） 混乱（Chaotic）问题，该域中没有系统级别的因果关系，方法是行动-感知-响应（Act-Sense-Respond），我们能够发现新颖实践（novel practice） 失序（Disorder）问题，该域中没有因果关系，不可感知，其中的问题也无法被解决 显然，软件开发过程更多地是一个复杂（Complex）问题。在一个产品被开发出来之前，不确定性非常高，团队（包括业务人员和技术人员）对产品的知识也是最少的，而且需要大量的学习和尝试才可以明确下一步可能的方向。不幸的是，很多时候我们需要在一开始（不确定性最高的时候）就为项目做计划。这种从传统行业中非常适合的方法在软件开发领域不再适用，这也是敏捷开发、精益等方法论在软件开发中更加适合的原因。 来源：http://alistair.cockburn.us/Disciplined+Learning 正因为软件开发事实上是一个学习的过程，我们学习到的新知识反过来会帮助我们对问题的定义，从而带来变化。这里的变化可能来自两个方向： 功能性 非功能性 功能性的变化指随着对业务的深入理解、或者已有业务规则为了匹配市场而产生的变化。比如支付方式由传统的货到付款变成了网银付款，又变成了微信支付、支付宝扫码等等。一个原始的电商平台仅仅提供基本的购物服务，但是后来可以根据已有数据产生推荐商品，从来带来更大的流量。这些变化需要体现在已有的代码中，而对代码的修改往往是牵一发而动全身。 非功能性的变化是指随着业务的发展，用户规模的增加，数据量的变化，安全认知的变化等产生的新的需求。比如100个用户的时候无需考虑性能问题，但是100万用户的时候，性能就变成了必须重视的问题。天气预报应用的数据安全性和网络银行的数据安全性要求也大不相同。 而在业务提出一个需求的时候，往往只是一个简化过的版本。 非功能性复杂性 来源：https://d13yacurqjgara.cloudfront.net/users/749341/screenshots/2228676/uielements_day021_dribbbleinvites.jpg 这是一个经过设计师精确设计的界面，在它被设计出来之前，用户事实上无法准确的描述出它。设计过程中经历了很多的诸如： 线框图 颜色的确定 交互的动画 信息层次 往复多次之后，界面确定了。在没有仔细思考使用场景的时候，开发会误以为这个功能非常简单。但是如果你是一个有经验的开发者，很快会想到的一些问题是： 在宽屏下如何展示 在平板上如何展示 在手机上如何展示 即使仅仅支持桌面版，跨浏览器要考虑吗？支持哪些版本？ 有些UI效果在低版本的浏览器上不工作，需要Shim技术 除此之外，依然有大量的其他细节需要考虑： 性能要求是什么样的？ 安全性要考虑吗？ 在网络环境不好的时候，要不要fallback到基础视图？ 既然涉及发送邀请函，送达率如何保证 与外部邮件服务提供商集成时的工作量 等等。这些隐含的信息需要被充分挖掘出来，然后开发者才能做一个合理的评估，而且这还只是开始。一旦进入开发阶段，很多之前没有考虑到的细节开始涌现：字体的选用，字号，字体颜色，元素间的间距等等，如何测试邮件是否发送成功，多个角色之间的conversation又会消耗很多时间。 需求的变化方向 作为程序员，有一天你被要求写一段代码，这段代码需要完成一件很简单的事： 打印"Hello, world"5次 很容易嘛，你想，然后顺手就写下了下面这几行代码： print("Hello, world") print("Hello, world") print("Hello, world") print("Hello, world") print("Hello, world") 不过，拷贝粘贴看起来有点低端，你做了一个微小的改动： for(var i = 0; i < 5; i++) { print("Hello, world") } 看起来还不错，老板的需求又变成了打印"Goodbye, world"5次。既然是打印不同的消息，那何不把消息作为参数呢？...