编辑导语：技术一定要写死程序吗？本文就一般什么情况下需要写死代码以及写死代码有什么优缺点做了详细阐述，一起来看看吧！

有个产品说：明明不写死会有很多好处，不明白为什么技术一定要写死程序。好家伙，程序员听了都要被气哭。

程序员并不知道要把什么功能写活，写死才是常态。如果所有的功能都要写成动态的，就不是业务程序，而是像在开发什么新的编程语言了。

一般产品未写明时，态度好的开发还会来问一下：这里要写死吗？如果开发不问的话，大概率就按照产品的需求来写，也就是怎么方便怎么来了。

所以某个功能需要写活，一定要说清楚，不然后面免不了一场撕逼大战的。再说如果开发预判了你的需求，提前写活了后端逻辑和前端页面，万一你没有修改的需求就是浪费人力了。你可能还会怪开发代码写得慢，这就会造成项目延误等后果。

那什么是写死呢？

一、写死定义

形容某个产品功能，被开发小哥哥直接用代码死死钉成某个样子，以不变应万变，日常使用中你我都不可以通过配置来变化内容。也可以说是让开发小哥哥直接写在代码里，不是从数据库读取数据或者从接口拉取数据，只限定一个固定常量，不接受变量。

常见例子：

“我希望老天爷能让开发小哥哥写死我的颜值up值”

“我希望老天爷能开发小哥哥写死我的体重，无论我吃多少都不会改变该值”

二、一般什么情况下需要写死代码呢？

• 写死虽然会有很多坑，但写死成本非常低啊，既不用改数据库也不用构建接口，所以对业务/产品需求大概率不会发生变化的，采用写死方案更优
• 技术和技术之间约定好的东西，可以写死，因为这是大家约定好的，开发肯定也不希望频繁改动或者因为太灵活的配置导致各种问题

三、写死的缺点

• 写死意味着除非发下一个版本，否则这个数据不可更改。
• 产品功能和规则的变化可能是随时的，原本的限制可能会变成日后的需求。
• 很多时候就是为了省事，很多逻辑
  都被「写死」在了代码里，想改的时候通常来不及，这也是很多产品大锅的来源。

所以在程序实现的时候，程序员问是否要写死，其实是探求这里是否会变化。如果不变，那就写死。有写死，那么就会有写活，其实写死和不写死二者并不是互斥的，有的时候是要一起配合的，既要本地写死，也要云端可控。

四、写死与写活的成本

• 不需要写活的程序默认写死，这才是常态。写活程序的成本要远远大于写死程序的成本，有时甚至数倍不止。
• 不写死的话意味着这个地方的数据是可以变化的，一般我们都会在服务器端进行配置，由客户端来进行拉取对应的参数再去使用。
• 把程序写活就是很多逻辑都要做成可控的，这个时候的工作量就无形之中拉长了时间，增加了时间的成本。

看到一个反讽为什么要写死的生活案例：铁轨的宽度为什么是固定宽度，如果可以拓宽一点的话，火车车厢就可以变宽了，这样可以多一列座位，这得提高多少运力呀，春运也不用那么挤了呀。这么一想，是不是发现写死并没有那么不好，这就是约定好的写死，为各方面节省了成本。

五、具体业务场景理解

关于写死，可以看一下下面的goodcase和badcase，可以帮助我们更好的理解“写死”这个术语。goodcase

往往App的底部tab栏，基本都是固定功能，每次都要展似的，这些都是default默认数据，如果没有者这份写死的数据，客户端运行起来，底部就会没有任何信息，要等网络数据回来才显示，或者无网络时，就像bug一样没有任何展示。

所以default默认数据主要解决用户体验问题，无网络或初次启动时，给用户隐喻这个App已经在正常运行。当然，也有一些App是写死和写活兼容的，即本地存一份写死数据，等数据拉取到数据回来再展示写活的数据，也能保证用户体验。

badcase：

某平台着急上线某个运营活动时，由于前端H5开发人员刚好在忙其他优先级更高的需求，所以这个活动交给了客户端开发。该活动是全场商品5折，客户端同学为了方便，则对所有商品设置了固定折扣5折，并不是通过接口从服务器获取的，而是直接本地写死的。但开发为了方便测试不多花钱，把折扣设置成了1折，测试完成后，没改过来，导致线上也是1折，上线后发现亏大发了。

最后采取的解决办法：修改客户端代码，将折扣修改并完成测试后提交应用市场审核，为了覆盖已发布的版本，只能开启强制更新策略，对用户体验非常不友好。

六、总结

需求方一定要充分明确需求的目的，才能充分判定某业务是否要写死，写死和写活的优劣势都很明显，在权衡中做出正确的选择很重要。

比如你要做修改用户个人主页背景图的功能：

写死：用户只能从预设的10张图片中选择，而不能自己上传字个人图片到App中使用，开发完成就没有其他的问题了。

写活：用户可以选择自己喜欢的图片做背景图，那么开发时就必须考虑以下问题：

• 图片格式要限定还是可以任意格式，要支持动图吗
• 图片的尺寸要限定还是任意，任意尺寸的图片还得做相应的裁剪处理，否则可能会出现变形/图片未铺满等体验不好的情况
• 图片上传后还得在后台建立一个数据库的功能，下次启动还得自动读取用户最后设置的背景图
• 图片上传后，还得建立审核系统，否则用户上传不合规图片会导致App下架

…

程序写死是个大大减少开发工作量的方法，但是很不利于后期App的更新和拓展，比如后面基于商业化变现，还想针对背景图做付费或者活动获取等运营模式。

需求业务是不断变化的，当前业务在考虑长远发展的同时考开发工作量，基于这些做出性价比最高的选择，你就能清楚什么情况应该写死/写活了。

本文由 @西瓜姐姐 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自 Pexels，基于 CC0 协议