Ableton 发布了一份详尽的免费指南，其中包含了他们在开发和维护 Device 时内部使用的各种资源。该指南包含大量的开发建议，是一次从 Ableton 取经的机会。

查看 Max for Live 开发指南（暂时还只有英文版）：https://maxforlive.com/resources/M4L-Production-Guidelines.pdf

《Max for Live 开发指南》的内容主要包含三大块：

• 这基本上就是一个开发百科，里面有很多方便的意见和建议，可以让你的开发做得更好。虽然只是开发指南，但经过多年在 Ableton 和 Cycling 74 内部开发的演变和推敲，很值得一看（设计、实施和维护都比早期有了很大改进）。
• 包含 Ableton 的代码标准，帮助你的开发更接近开发标准。
• maxdiff 可让你通过标准的可读 Git diff 比较不同的 Patch 或 Patch 版本 — 这不仅对 Max for Live 开发人员有用，对 Max 程序的开发人员也非常有用！

谁应该是用这本指南，来自 Ableton 的 Mattijs 分享了他的看法：

关于制作 Max for Live 工具，大部分应当取决于创作者自己的想法。我个人倾向于在随意分享时更自由一些，但当我正式发布工具并承诺维护时，Device 就是一款产品了，这时我就会想帮助未来的自己，在可读性上做的更好。

艺术家们一旦开始制作较大、较复杂的工具时，肯定会用到 Patch 代码指南，但并不是每个人都愿意投资学习 git。在我看来，学习 git 已经脱离了艺术范畴，进入了软件开发领域；另一方面，从本质上讲，一旦开始维护 Max 工具，软件开发就是你要做的事情。

指南中还有其他一些实用的建议，可以让你以后省心不少：比如在哪里放置依赖项、如何保持 Patch 干净整洁，以及消除咔哒和咔哒声，等等….

Peter Krin 还找 Mattijs 要来了一些额外的开发建议：

• 不药存储冻结的 Device，并在解冻 Device 后始终清除复制的依赖关系。重复的依赖关系会导致很多的混乱。
• 避免使用分段跳线
• 在着色和网格大小等方面使用 Max 默认值。这有助于 Patch 保持简洁、一致，从而便于阅读，这对我来说比美观更重要。此外，在清理别人或自己制作的现有 Patch 时，查看每个子 Ptach 并确保所有内容看起来都一样，也有助于掌握 Patch 的作用。
• 在所有指南之间，我对制作优秀 Patch 的看法是，真正的挑战在于如何让 Patch 变得简单。就像基于文本的代码一样，这可以是一种艺术。这可能还需要摒弃一些自负，杀死一些你喜欢的东西，担要知道，当你发现自己花了好几天时间构建的那个庞然大物其实根本没有必要，你需要保持开放的态度，将其完全删除。
• 还有一个开发指南中没有的额外提示：在全局 Max 偏好设置中，Patch 下有一个选项：优先处理 Patch 跳线。在处理较大的 Patch 代码时，尤其是处理距离较近的对象时，启用该选项会有很大帮助。