需求碎片化时代，从编程到设计的心灵鸡汤【上】

这门课把「需求碎片化」当成一个真实的工程问题来处理，而不是一句口号。它要回答的是：当需求不断被拆散、被重新组合，我们写代码时依赖的「函数」和「类」这两种基本形式，各自在什么位置、能撑住什么、会在哪里失效。课程没有从语法讲起，而是把视角拉到「软件形式」的演变上——从函数到类，再到两者如何被组合，最后落到一个叫 EIT 造型的具体创新模式上。如果你平时写代码只想着「功能实现」，很少反问「这个结构再过三个月还改得动吗」，那这门课正好补上这一块。

适合什么基础，先看哪几块

你需要已经会写基本的函数和类，理解封装、继承、多态这些概念，但不用是架构师。更适合的是这样一类人：项目里需求频繁变动，每次改动都牵一发动全身；或者你从函数式转到面向对象，总觉得别扭，说不清别扭在哪。课程前两节「需求与软件碎片化潮流」「软件形式」是地基，建议先看。它们把「碎片化」从业务层面的流行词，翻译成代码结构里的具体矛盾——比如一个需求被拆成多个小函数后，调用关系变得像蜘蛛网；而用类封装后，又容易陷入继承树越来越深的困境。第三节「软件形式的演进：函数—类」是全书的关键转折，它不把函数和类对立起来，而是看它们各自擅长处理什么形态的碎片。如果你时间紧，至少把这三节吃透，再往后看「组合」和「EIT 造型」才不会觉得飘。

学完能独立做什么

学完这门课，你应当能对着一堆「散装需求」画出一张结构草图：哪些需求适合用函数链串联，哪些适合用类来承载状态，哪些需要把两者组合成更高级的造型。具体来说，你能独立分析一个中小型模块的代码组织方式，判断它是否过度依赖函数嵌套、或者被类的继承层次绑架；你能用课程里讲的「组合」思路，把几个既有类重新拼装，而不是推翻重写；你还能试着用 EIT 造型去设计一个可扩展的接口——EIT 的核心是「接口—实现—模板」三层结构，它让变化点被隔离在特定层，这在插件式功能、策略切换、或者需要频繁增加新类型的场景里特别有用。学完后，你至少能对同事说清楚：「这里为什么不用类，而用函数组合？」而不是凭感觉拍脑袋。

资料怎么配合练习

这套资料里没有可运行的完整项目，更像是一套带着你推演的设计笔记。所以练习方式不是「敲完跑起来」，而是「跟着改」。建议你看完一节，就打开自己手头一个真实的小模块，试着按课程里的思路重新组织一遍：比如把原来一个超大函数拆成几个小函数，看看拆完后的调用顺序是否清晰；或者把几个共享状态的行为收进一个类，再观察这个类是否真的降低了耦合。重点放在第三节「函数到类」的过渡和第六节「EIT 造型」上——前者让你理解为什么要换形式，后者给你一个具体的造型模板。你可以用一张纸画出 EIT 的三层关系，然后拿一个现有接口去套，看套不套得进去，套不进去就说明接口设计有问题。这样练完，你得到的不只是「看过」，而是真正能迁移到下一次需求变更时的判断力。