对抗软件复杂度的战争

二、本质复杂度和偶然复杂度

三、复杂度的爆炸

四、错误的应对方式

五、正确的技术战略

六、微观层面的复杂度控制

function emailsForCustomers(customers, goods, bests) {  var emails = [];  for(var i = 0; i < customers.length; i++) {    var customer = customers[i];    var email = emailForCustomer(customer, goods, bests);    emails.push(email);  }}
function biggestPurchasePerCustomer(customers) {  var purchases = [];  for(var i = 0; i < customers.length; i++) {    var customer = customers[i];    var purchase = biggestPurchase(customer);    purchases.push(purchase);  }}

对于这种到处可见的逻辑，即遍历集合的每个元素，对其中每个元素做一些处理，返回一个新元素，最后装成一个新的集合，可以被抽象成一个 map 函数。在这个例子中，我假设 JavaScript 支持 map 函数，那么上面的代码可以写成：

function emailsForCustomers(customers, goods, bests) {  return map(customers, function(customer) {    return emailForCustomer(customer, goods, bests);  });}
function biggestPurchasePerCustomer(customers) {  return map(customers, function(customer) {    return biggestPurchase(customer);  });}

抛开语言语法的因素不谈，这段代码除了这个 map 函数，剩下的就是函数名了，而函数名只要是命名得当的，那它其实就是本质复杂度，就是业务逻辑。行业先辈，大家耳熟能详的 Martin Fowler、Kent Beck、Robert C. Martin，无不在他们的书籍中强调命名的重要性，都是希望代码能够清晰地沟通意图，而这里最核心的意图应当是与问题域匹配的。

七、软件道德观

八、系统架构对复杂度的影响

我曾经的大老板郭东白曾在一次 QCon 的演讲中讨论优秀架构师的特质，除了大家都很好理解的有眼光、善于思考、能感召等几个特质外，还特别强调了“有良知”，他说：

1. Why choose Domain-Driven Design?  这篇文章清晰地解释了本质复杂度和领域驱动设计的关系。
2. 《人月神话》-「没有银弹」一篇阐述了本质复杂度和偶然复杂度的概念。
3. 《The Lean Product Playbook》- 本书的第2章清晰地解释了 Problem Space 和 Solution Space。
4. Wardley Map  - 分析技术战略的绝佳工具，合理地选取商业产品可以帮助降低系统复杂度。
5. Grokking Simplicity  - 在微观层面，使用函数式的思维降低软件复杂度。
6. Design Docs at Google
7. Conway’s Law

8. 警惕复杂度困局：关于软件复杂度的思考