token是写死的吗_为什么要把程序写死？

好家伙，我直接好家伙。程序员听了都要被气哭。

程序员根本不知道要把什么功能写活。

不需要写活的程序默认写死，这才是常态。写活程序的成本要远远大于写死程序的成本，有时甚至数倍不止。

所有的功能都要写成动态的，你确定你这是业务程序，不是在开发什么新的编程语言？

比如，有一个需求，半夜11:50发送一封邮件给某个用户。

如果只是我个人使用，那我直接写死在代码里面就好，反正我自己用着，时间收件人随手一改就解决了，有什么需要变更的直接在代码里面改就好。两小时功能就能把功能全部实现。

但是如果是那种，特别坑爹的甲方呢？

甲方:不行，你这个给我设置成可以修改时间。

好嘞，程序员哐哧哐哧，把代码改成可以变更的时间，还要加一个用户修改和查看时间的界面，这方面还涉及前端交互的问题。就这么两天过去了。

甲方:不行，我要能修改收件人。

程序员继续哐哧哐哧修改，改了修改和缓存收件人的功能。

甲方:一个收件人不够用，要能群发。

程序员哐哧哐哧。

甲方:这玩意不好用啊，收件人能从手机里面读取么？能分享么？

程序员，卒。

总之就是好家伙，球球了，程序员也不知道什么要写活啊。

我就是按照需求写的，你自己都不知道什么是需要变动的需求，那我怎么知道？

就算我提前猜到了，提前写活了后端逻辑和前端页面，万一你没有修改的需求怎么办？

万一你还怪我代码写的慢怎么办？这么简单的需求写了三天，我怎么解释？我预判了你的事儿b，没想到你今天居然不事儿b了，搞得我们都有点下不来台？

可能有些经验老道的程序员能够一眼看出甲方的扯皮本质:

"哼，老衲早就夜观天象知道你这b又要加功能，这些功能老夫早就007肝好了。"

甲方:不行，运行速度太慢了。

经验老道的程序员:尼玛，那你倒是少提点需求，买好一点的服务器啊！