阅读笔记3：《程序员修炼之道--从小工到专家》

六到八章，从“代码工人”到“问题解决者”
一，编码的伦理：不要以“忙”为借口
第六章开篇即戳破一个普遍的自我欺骗：“我没时间把代码写漂亮，先凑合吧。”作者毫不留情地指出：凑合的代码从来不会“以后再来改”，它只会腐烂成永恒的负担。事实如此，完成“任务“以后我普遍不会再去修改，纠正。
更重要的是不要靠巧合编程。作者描绘了一种令人战栗的日常：代码“好像能跑”，但你不知道它为什么能跑；加一个功能“似乎没出问题”，但你不确定它是否破坏了什么。这种状态被命名为“巧合式编程”——靠侥幸而非确定性前进。
与此相对的是深思熟虑的编程：你知道代码为什么能跑，也知道它会在什么情况下不能跑。作者提出的质问我感悟颇深：你是在努力把程序调试成功，还是仅仅在努力把错误提示调试消失？
算法速度一节展现了独特的务实精神。作者不要求人人都能口算大O复杂度，但要求程序员养成“量级思维”——当数据量翻一百倍，你的程序会慢十倍、百倍、还是千倍？估算不是预测，而是建立直觉的练习。
重构在此处被正名：不是对“写错代码”的补救，而是对“变老代码”的日常养护。重构不应当是一个独立项目，更不应当申请“重构月”。像刷牙一样重构——小步、持续、永远进行。
二、需求的追问：摘下面具，看见问题
第七章从一件日常荒诞切入：用户说“我需要电梯”，但真正要的是“不用爬楼梯”。需求很少存在于表面，它藏在问题的背后。
需求之坑一章最震撼我的，是它对“需求文档迷信”的解构。无论文档写得多厚，它都不是真正的需求——真正的需求是用户拿起软件那一刻的沉默或微笑。文档只是需求的影子，而影子总有扭曲。
看板与用例被作者赋予了一种近乎人类学的视角：别问用户“你要什么功能”，去问“你为什么需要这个功能”“现在没有它你怎么做”“什么是你不得不忍受的麻烦”。需求挖掘不是访谈，是田野调查。
维护的迷思在此处被彻底祛魅。软件行业把“维护”视为下等工种，视为“修旧东西”。作者反问：飞机在空中飞行时，飞行员说“我这不是飞行，只是在维护”？ 真正的软件生命周期里，大部分时间都在“发布后”——那不是苟延残喘的维护期，那是软件真正创造价值的服役期。把“维护”视为二等工作的团队，永远不会做出值得维护的产品。
三、解决问题的起点：定义问题比解决问题更难
第八章是前三分之一到中段的转折点——从“如何写代码”转向“该不该写代码”。
永恒的准备陷阱是项目失败最常见的病因。团队迷信“准备越充分，执行越顺畅”，于是把全部精力投入文档、计划、评审，直到某天发现市场早已转向，而自己的“完美计划”已经过时。作者提出一个反直觉的药方：准备期的终点不是“所有问题都有了答案”，而是“足够开始试错的自信”。
需求文档的悖论在此处被推向极端：文档越细，误解越深。文字是低带宽的媒介，用户读一行代码文档时的脑补，与程序员写这行字时的意图，往往是两个物种。原型法不是偷懒，是对语言局限性的诚实。
本章最珍贵的洞见落在“问题定义”本身：真正困难的是发现究竟是什么问题。大部分项目失败不是因为找不到解决方案，而是解决了一个根本不存在的问题。作者建议反复追问五个“为什么”，直到触及真正的病灶——这是程序员版的苏格拉底式诘问。