从一次交付到产品化.
把一个客户的方案变成产品,难的不是抽象,而是判断哪些特殊性值得保留。
扫码在手机上阅读。朗读正文内容,不包含页面工具和目录。
问 AI
复制正文和提示词,让 AI 生成摘要与要点。复制正文和提示词,让 AI 提取结构和心智模型。复制正文和提示词,让 AI 以问答方式帮助理解。
一个样本不足以归纳.
第一个客户教会你的,是「这件事可以这么做」。它没有告诉你「这件事必须这么做」。这两者的差别,要到第二第三个客户身上才看得出来。
所以在第三个客户之前,允许代码里存在明显的特例。它们丑,但它们诚实——它们如实记录了你还不知道的东西。
分辨特殊性的两种来源.
有些特殊性来自行业:制造业的排产逻辑就是比零售复杂,这不会因为换一家公司而改变。
另一些特殊性来自历史:某个字段之所以叫这个名字,是因为十年前的一次系统迁移。前者要保留,后者要在下一个客户那里果断丢掉。
配置项不是万灵药.
当你分不清该不该抽象时,很容易把它做成一个配置项,让客户自己选。这看起来很灵活,实际上是把判断的责任推给了不该承担它的人。
每加一个配置项,产品就多一条需要测试的分支、多一页需要维护的文档。真正的产品化是做减法:想清楚哪一种做法是对的,然后只提供那一种。
— 讨论
GitHub评论.
评论由 GitHub Discussions 承载。请围绕文章内容交流,并保持克制、友善。
评论暂时没有加载出来。可以稍后刷新重试,或直接到 GitHub Discussions 参与讨论。