指南编辑：技术需要编写死亡程序吗？这篇文章详细说明了一般在什么情况下应该写词码，以及写词码的优缺点，一起看吧！

一个产品明确表示，不使用死亡会有很多好处，不理解为什么技术一定要使用死亡程序。

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

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

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

那什么是写死呢？

一、写死定义

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

常见例子：

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

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

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

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

三、写死的缺点

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

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

四、写死与写活的成本

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

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

五、具体业务场景理解

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

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

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

badcase：

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

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

六、总结

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

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

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

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

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

…

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

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

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

题图来自 Pexels，基于 CC0 协议