“多做一些项目，把作品集堆厚一点。”这句话在技术圈被反复传了太多年。再加一个框架，再接一个API，再配一份排版精致的README，末尾挂上部署链接。

但我想说，这套建议大概率是错的。至少，它优化错了方向。

打开网易新闻 查看精彩图片

作品集项目优化的是“看起来厉害”，真实项目优化的是“真的有用”。在我看来，这是两种完全不同的能力，而追着前一种跑，会悄悄饿死后一种。

作品集项目缺的从来不是技术

你通常能一眼认出作品集项目，看它没有什么就行：没有用户。

这不是因为它还早，也不是在质疑它的质量或价值，而是结构性的。这个项目存在的意义是证明“你能做出东西”，而不是因为任何人——包括你自己——真的需要它。所以它永远不会被使用，也就永远不会以真实的方式坏掉，于是你永远不必在真实条件下调试它，也就永远学不到调试真正要教给你的那件事。

拿它和“为自己某个具体烦恼而写的东西”比一比。

可能是一个修掉工作流问题的脚本，也可能是一个只把一件小事做对的工具。只要它有了哪怕一个真实用户——哪怕这个用户就是你自己——项目就开始反过来跟你说话。它会告诉你，你的假设哪里错了。这个反馈回路才是全部意义所在，而作品集形态的项目，恰恰是被设计来绕开它的。

什么行得通，什么行不通，设计在哪里扛住了、在哪里没扛住——这些才构成一个健康、持续的反馈回路，也才让一个软件工程师随着时间真正变强。

先发布小的，架构让真实需求来挣

我尽量遵循的一条原则是：先发布那个小而可用的版本，让进阶架构由真实需求“挣”出来，而不是提前预支。

这和很多人的本能相反，尤其是职业早期。提前规划出“正规”架构，感觉上很负责任；发布一个明显还没做完的东西，感觉上很草率。但实践中，没被部署过的架构只是猜测，而在一个系统还没有任何用户时猜测它未来的需求，几乎总会在某个你预料不到的方向上出错。

先发布一个小而真实的东西，意味着：

  • 你被迫面对真实约束，而不是想象中的约束
  • 你拿到的是使用数据，不是脑内推演
  • 你练的是判断力，而不是堆砌能力

这不是说不要规划。它的意思是，在你做出那个无聊的、具体的、真正能跑的版本之前，先忍住别去做那个通用、可无限扩展的版本。

“先发布，再加深”这个顺序会带出一批习惯，它们并不光鲜：

  • 把范围砍到只剩一件事
  • 接受第一版就是丑的
  • 让真实使用来决定下一步

这些不是干满十年才配拥有的高级工程师习惯。它们立刻就能用上，就在一个小项目上，在你决定目标是“有用”而不是“好看”的那一刻。

安全，才是作品集项目泛滥的真正原因

作品集项目之所以到处都是，老实说是因为它们更安全。一个没人用的项目不会当众失败。它可以就那么搁着，未完成但在技术上不算错，一直搁下去。

而一个为解决真实问题而建的项目，必须真的能跑。这更吓人，也正是它能教给你作品集给不了的东西的全部原因。

如果你正想进入技术行业，或者只是想成为一个更好的工程师，比起五个从没走出“截图里看着不错”阶段的宏大项目，我更愿意看到一个真正能用、并且你能讲清它取舍的小东西。

把它做小，发布出去。让它被使用。让真实需求来告诉你，什么时候该往深处走。