从写代码到解决实际问题

从写代码到解决实际问题

很多人入门编程的时候，以为学会写代码就等于“会干活”。我刚开始学的时候也是这样：照着教程把“Hello World”敲出来，再把冒泡排序背得滚瓜烂熟，心里觉得“我已经是个程序员了”。结果一接触真实项目，连需求都没听清，就开始埋头写函数，最后代码跑得通，业务却跑偏了。后来我才慢慢明白，写代码只是手段，解决问题才是目的。从“写得好”到“用得上”，中间隔着一道不短的路。

写代码很容易，写对问题很难

刚工作那会儿，我接过一个“提升页面加载速度”的需求。第一反应是：压缩图片、合并请求、加缓存。我吭哧吭哧写了一堆优化脚本，性能监控面板确实变绿了。可运营同事过来说：“用户还是抱怨卡。”我跑去一看，发现大部分用户用的是低端安卓机，网络也不稳定，我那套“高级优化”根本没落到他们的场景里。写代码没毛病，但问题抓错了。就像医生只顾着开好药，却没问病人是不是对药过敏。技术再漂亮，解决的不是真问题，就是白忙活。

把问题拆小，比把代码写长更重要

后来做内部工具，团队总抱怨审批流程慢。一上来就想重写整套系统，我本能地画架构图、设计接口，准备大干一场。幸亏被前辈拦住：“你先搞清楚，慢在哪一步？”我跟着走了一遍流程，发现八成时间卡在“等主管下班签字”。问题根本不是系统性能，而是流程节奏。于是先做了一个“移动端预填+短信提醒”的小功能，上线一周，审批时长直接砍掉一半。有时候，解决问题的最优解根本不是写代码，而是一封邮件、一个提醒、一次规则调整。可如果不把问题拆透，很容易陷入“我要写个更牛的轮子”的自我感动里。

场景比技术更重要

再比如做数据导出功能，技术上无非就是查库、生成文件、提供下载。但我见过一个失败案例：导出的文件字段全、格式准，可业务人员拿到后还要手工整理两小时。原因很简单：系统按数据库结构导出，业务却按报表口径用。后来加了配置层，让业务自己勾选需要的字段、排序和单位，开发时间多花了两天，使用效率却提升了数倍。技术是中性的，场景决定了它的价值。脱离场景谈实现，很容易写出“正确的废话”。

让代码能改、能退，才是真正的交付

还有一个体会：解决问题不是“一次性交差”。曾经为了赶上线，我写了一段高度耦合的逻辑，注释都没留。结果两个月后业务规则一变，改一处崩三处，大家都不敢动。后来我学乖了：先写能跑通的简单版本，再逐步加清晰的边界和自动化测试。更重要的是，把“回退方案”当成需求的一部分。解决问题不是比谁更聪明，而是比谁更稳。稳，不来自炫技，而来自对问题的敬畏和对变化的预留。

写到最后，往往是沟通在写代码

越往后做项目，越觉得写代码的时间在缩短，而讨论、澄清、验证的时间在拉长。一次需求会，五个角色各自理解不一样，最后做出来的东西谁也用不着。后来我们强制“先写用例再写代码”：用自然语言把正常流程、异常流程、边界情况说清楚，达成共识再动手。写代码只是把共识翻译成机器能执行的形式。如果前面的共识是错的，代码越快，错得越离谱。解决问题，本质上是在一群人之间建立共同理解，技术只是承载这种理解的工具。

从写代码到解决实际问题，最难的并不是学不会某种语言或框架，而是放下“我要用最新技术”的执念，回到问题本身：谁在什么场景下，遇到什么困难，期望什么结果。学会问蠢问题，学会看脏数据，学会接受“不写代码也是解法”。当你能把复杂问题翻译成可执行步骤，并让结果可测量、可回退、可迭代，代码才会有力量。

写程序的人很多，能解决问题的人不多。区别不在于谁敲键盘更快，而在于谁更愿意弯下腰，看清脚下的路，再决定用哪一行代码去铺平它。