Skiena 把全书组织成两个部分：前半部分讲算法设计的技术（数据结构、排序、图算法、动态规划、回溯），后半部分是一个按问题类型组织的算法目录。这个结构本身就体现了方法论——前半部分教你识别和解决问题，后半部分让你查找已有的解法。
问题建模最关键，也最容易出错
工程师面对一个业务需求，通常的反应是"我应该用什么算法"。Skiena 的方法论要求先回答一个不同的问题："这是什么类型的问题？"
排序？搜索？图遍历？最短路径？字符串匹配？优化？约束满足？
同一个业务需求可以被建模成不同类型的问题。"找出最相似的用户"可以是最近邻搜索、可以是聚类、也可以是图上的社区发现。建模方式不同，候选算法完全不同，解的质量和计算成本也完全不同。
建模能力不来自读教科书。它来自见过足够多的 war stories——知道别人在类似情况下是怎么建模的，踩过什么坑，最后选了什么方案。这就是 Skiena 把 war stories 放在书的核心位置的原因。
计算复杂度是选型的护栏
建模完成后，下一步是确认这个问题的已知计算复杂度。
如果问题在 P 中——存在多项式时间算法——重点在选一个常数因子最小、空间效率最高、对实际数据分布最友好的。
如果问题是 NP-hard——不存在已知的多项式时间精确算法——决策方向完全不同。不是"怎么优化得更快"，而是"放宽什么约束可以让问题变得可解"。近似算法保证最优解的某个比例；启发式算法不保证但通常效果不错；参数化算法在某些参数小的情况下可以精确求解。
识别 NP-hard 是止损。不识别就会在"再优化一下"的循环里消耗数周。
算法目录是查找工具
Skiena 的算法目录按问题类型组织，每个类型下列出：问题的标准定义、可用的算法及其复杂度、实际使用中的注意事项、推荐的实现和库。
使用方式不是从头读到尾。而是：确定了问题类型之后翻到对应章节，看有几个候选，比较它们在当前约束下的优劣。
这个目录的价值在于：它减少了"不知道有这个算法"的盲区。很多工程师不是不会用某个算法，是不知道它的存在。目录让你的搜索空间更完整。
实测高于理论分析
选定候选算法后，Skiena 的方法要求用实际数据实测——不是只看大 O 就做决定。
理论分析给的是渐近行为——n 趋向无穷时的增长率。工程中的 n 是具体的。n=1000 和 n=10^8 对算法选择的影响可能是颠覆性的。
影响实际性能的因素理论分析通常不覆盖：缓存行为、分支预测、内存分配模式、并行度。两个同为 O(n log n) 的排序算法，在实际数据上的速度可能差三倍。
先写暴力解法作为基线，再实现优化算法，用相同数据对比。基线不只用于测性能，也用于验证正确性——如果优化版本的输出和暴力版本不一致，说明优化引入了 bug。