产品术语 | 开发口中的“写死”是什么意思？

西瓜姐姐 2023-08-04 12:12:33

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

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

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

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

那什么是写死呢？

一、写死定义

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

常见例子：

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

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

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

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

三、写死的缺点

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

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

四、写死与写活的成本

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

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

五、具体业务场景理解

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

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

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

badcase：

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

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