北京
有一类建议，几乎每个想进入科技行业的人都听过：多做项目。把作品集堆厚一点，再加一个框架、再调一个接口、再写一份漂亮的说明文档，配上一个在线部署链接。
这套建议本身没什么恶意，但它优化错了方向。作品集项目优化的是"看起来厉害"，真实项目优化的是"真的有用"。这是两种不同的能力，追着前一种跑，会悄悄饿死后一种。
判断一个项目是不是作品集项目，看它缺什么就行：用户。这不是因为它还早，也不是在质疑它的质量或价值，而是结构性的——它存在的目的是证明你能做出东西，而不是因为任何人（包括你自己）真的需要它。所以它永远不会被使用，也就永远不会以真实的方式出问题，你也就永远不必在真实条件下调试它，最终你学不到调试真正要教给你的东西。
一个真实用户，项目就开始说话了
对比一下：为某个你自己遇到的麻烦写点东西。可能是一个修复工作流问题的脚本，也可能是一个只把一件小事做对的工具。只要它有了哪怕一个真实用户——哪怕这个用户就是你自己——项目就开始反过来跟你说话。它会告诉你，你的假设哪里错了。
这个反馈回路才是关键。而作品集形态的项目，恰恰是被设计来绕开它的。什么行得通、什么行不通、设计在哪里撑住了、在哪里没撑住——这些才构成一个健康、持续的反馈回路，也才让一个软件工程师随着时间变得更好。
我试着遵循的构建原则是这样的：先发布小而可用的版本，让进阶架构由真实需求挣来，而不是提前预想出来。
这和很多人的本能相冲，尤其是职业早期。提前规划"正规"架构，感觉才负责任；发布一个明显没做完的东西，感觉太草率。但实践中，没部署过的架构只是猜测，而在系统还没有任何用户时猜测它未来的需求，几乎总会在某个你预料不到的方向上出错。
先发布，再加深
先发布一个小而真实的东西，意味着你面对的是真实约束，而不是想象中的约束。由此长出来的习惯并不光鲜：把东西真正跑起来、处理边界情况、在有人用的时候修它、解释自己为什么这么选。
这些不是干满十年才能获得的资深工程师习惯。它们立刻就能拥有，就在一个小项目上，在你决定目标是"有用"而不是"好看"的那一刻。
作品集项目之所以泛滥，诚实的原因是它们更安全。一个没人用的项目不会公开失败。它可以就那么放着，永远处于"没完成但技术上不算错"的状态。
而为解决真实问题而建的项目，必须真的能用。这更吓人，也正是它能教给你作品集项目教不了的东西的全部原因。
如果你正试图进入科技行业，或者只是想成为更好的工程师，比起五个从没走出"截图里看着不错"阶段的宏大项目，我更愿意看到一个真正能用、并且你能讲清楚其中取舍的小东西。
把它小规模地发出去。让它被使用。让真实需求来告诉你，什么时候该往深处走。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
