引子：宏观与微观本是哲学上的两个术语，但我印象中最早听这两个词是从了解经济学开始的。经济学被分为宏观经济学和微观经济学两大分支，本文类比经济学的研究方法思考宏观与微观的本质，及其在软件领域的意义。

1. 宏观与微观的概念理解

  从字面意思来看，宏是大、微是小的意思，观就是看、观察的意思。因此，宏观和微观说的是两种截然不同的认识事物的角度或方法。以下是我的个人理解。
宏观：从大处着眼，侧重整体地、综合地去看问题，在时空上考虑大尺度、大范围、长周期的事项安排及可能的问题与处理策略，从统计上算总账。
微观：从小处着眼，侧重分拆了、细分地去看问题，在时空上考虑小尺度、小范围、短周期的事项安排及可能的问题与处理策略，从统计上算细账。
  依据上述理解，下面谈谈软件领域的问题，及解决问题的思维模式。就像微观经济学是宏观经济学的基础一样，微观软件学也是宏观软件学的基础，因此我们先微后宏。

2. 软件领域的微观问题与微观思维

  分类是认识的基本方法，而分类的第一步是罗列，然后根据某种标准对罗列出的对象进行分门别类整理。这里我们不妨将软件领域常见的问题列出来：

• 算法，
• 数据结构，
• 编程语言特性，
• 编码规范，
• 设计模式，
• 框架/中间件，
• 系统架构，
• 设计风格，
• 开发模式，
• 分工协作，
• 项目管理，等等。

  依据对宏观微观的理解，不难看出上述问题从“算法”到“设计模式”应属微观问题，因为这些问题是对整个软件系统进行拆分后，从不同的侧面去分析研究的。拆分后的好处是可以聚焦深入研究，毕竟人的精力是有限的，人的才能也是有差异的，正所谓术业有专攻，拆分后不论从个人发展还是从行业发展来说都可以高效地获得更加深入的研究成果。
  在处理微观问题时，要遵从微观的方法，那就是尽可能聚焦精力，为问题划定尽量小的范围，做更少而不是是更多的事，要细算、精算。例如当设计一个功能模块时，要仔细考虑这个模块的职责到底是什么，要遵循职责单一的原则。再如，在评测一段代码的性能时，要细算其在整个应用生命周期被调用的次数，占用的CPU时间片、内存磁盘、网络带宽等指标。

3. 软件领域的宏观问题与宏观思维

  前面我们所罗列的软件领域的问题中，从“框架/中间件”到“项目管理”应该属宏观问题，因为这些问题更多是侧重从整体的角度去看待软件生产的过程。例如框架或中间件通常会影响整个软件系统的技术选型甚至架构，而系统架构从名称上就能看出是针对系统整体而言的，而开发模式、项目管理等更是要从全局综合考虑技术、人员、团队文化等方方面面因素。
  在处理宏观问题时，要遵循的基本原则是从整体和全局的角度出发，综合考虑会影响软件交付及最终的部署运营的各种制约因素，从中平衡以博取最大的收益率。另外，按照前面对宏观的理解，在考量收益率时，不仅要从当下出发，还要尽量超前设计，考虑中长期收益。在进行指标统计时，要侧重算总账，例如系统用户总量，整体QPS，磁盘空间占用量，带宽需求等，以及这些指标在可预见的未来的增量。

4. 宏观与微观的关系

  虽然宏观和微观两种思维方式所侧重的研究对象和方法截然不同，但从人的认识规律来说，微观认识通常是宏观认识的基础。就像微观经济学是宏观经济学的基础一样，“微观软件学”也是“宏观软件学”的基础，正因如此我们是先学习编程语言、算法数据结构等专业知识，然后才去学习系统架构、开发模式、项目管理等技能的。
  另外，宏观与微观是两种互为补充的认识方法。世间万物总是极其复杂的，要想深入理解并掌握其发展规律，采取宏观与微观相结合的方法是很有必要的。

5. 拓展思考

  本文虽是谈软件领域的问题，但回归到宏观与微观两个词的本身来说，很容易上升到哲学的思考高度来。既然是哲学概念，一旦掌握其适用范围总是很广泛的，这里不妨稍作拓展，考虑下面几个问题。

• 时间规划
  讲时间管理或规划的理论有很多，但如果我们套用宏观和微观的哲学思想，我们可以简单地把时间规划分为两方面的事：一是微观规划，即短期内、具体事务或项目的规划；二是宏观规划，即长期的、日常例行的、组织或个人发展方面的时间规划。
• 能力评估
  能力评估可以是针对个人或团队的，这里以招聘为例。面试官决定是否要录用一个人时，其依据是什么呢？还是借用宏观与微观的思维方式，既要看候选人具体某个或某几个方面的技能是否满足团队的需要，同时还要考虑其综合素质是否与团队匹配、加入后对团队整体的影响如何等全局问题。
• 战略与战术
  战略与战术的关系跟宏观与微观的关系似乎有点类似，通常处理战略问题要采用宏观思维，而战术则更多采用微观思维。