开发口中的“写死”是什么意思？(开发都是数据产品程序)

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

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

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

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

那什么是写死呢？

一、写死定义

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

常见例子：

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

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

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

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

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

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

五、具体业务场景理解

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

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

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

badcase：

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

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

六、总结

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

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

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

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

…

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

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

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

题图来自 Pexels，基于 CC0 协议