读《构建之法》之前，我一直觉得写代码就是个技术活。代码写得漂亮，bug修得利索，就是好程序员。但这本书让我发现，写代码和做软件是两回事。
书里讲了个例子：你给客户做个记账软件，吭哧吭哧把功能全实现了，界面也调得很精美。结果客户用了一个月，说：“挺好，但我要的是能让我老婆也看到账本的。”你就懵了——当初需求没提这个啊。这不是段子，是我真实遇到过的事。那时我还有点委屈，觉得是用户说不清楚。读完邹老师的书我才明白，不是用户的问题，是我的问题。我把自己当成“代码实现者”，而不是“问题解决者”。书里有个词叫“秋千图”，讲的是需求和实现之间的差距。用户说想要个秋千，你给他造了个完美的秋千架，结果人家是想晃两下找找童年感觉。这事儿在开发里太常见了。用户说要个报表功能，其实是想在领导问起来时能立刻打开看；说要个搜索框，其实是想从几百条记录里快速定位那一条。我以前总琢磨怎么把搜索做快，后来才明白，用户真正想要的是“不用搜就能看到”。团队合作那章也让我想了很多。以前觉得团队合作就是各写各的模块，写完一拼。结果总出问题——你调我接口，我等你数据，加班到半夜互相甩锅。书里讲了个概念叫“木桶效应”，团队效率不取决于最快的人，取决于最慢的那块板。我组里有个同事写代码特别慢，我们背后老吐槽他。后来发现他是在给每段代码写详细的注释和测试。有次项目交接，他那个模块别人接过去看得明明白白，我那个模块只有自己能看懂，请假都不敢请。那之后我才知道，快的代码和可持续的代码，是两回事。还有测试。说实话我以前觉得测试挺low的，那是测试组的事。我写完代码能跑通就算完工。书里说了一句话我印象很深：“代码写完的那一刻，是bug最少的时候，之后只会越来越多。”因为代码要维护、要加功能、要改需求，每一次改动都可能把原来的逻辑破坏掉。现在我也会给自己写的代码写单元测试，不是为了显得专业，是为了三个月后的自己少掉头发。最触动我的是最后一章讲创新。以前觉得创新就是灵光一现，突然想到个好点子。书里举了手机输入法的例子：九宫格、全键盘、手写、语音，每种输入法都有人用，也都有人骂。不是它不好，是场景不同。你在公交车上站着，和在家躺沙发上，需要的输入法是不一样的。创新不是造个完美的东西，是在合适的场景解决合适的问题。这个认知对我挺重要的，它让我不那么焦虑了。不是非要做出个颠覆性的东西才叫创新，把手头的问题想得更透、做得更细，也是创新。
读这本书最大的感受是，它让我从一个“写代码的人”慢慢变成了“做产品的人”。代码只是工具，解决问题才是目的。现在我写代码前会多问几句：用户到底想要什么？这个功能真的有必要吗？几个月后别人来维护这段代码，能看懂吗？这些问题没有标准答案，但问出来之后，写出来的东西确实不一样了。不是为了让自己显得厉害，是为了让用的人真的觉得好用。这大概就是工程思维吧。不是追求完美，是追求适用；不是彰显自己，是成就他人。
