关于功能制作过程中的扩展性设计问题

  大家好，我是阿赵。
  最近我在做一个游戏，需要内置多种语言切换，所以需要做工具提取游戏里面的简体中文文本做翻译。在某一天，我突然发现了游戏里面增加了两三千个需要翻译的文本。按道理来说，游戏已经上线了，新作的功能也不可能突然新增这么多语言文本才对。
  于是我打开提取出来的文本看了一下，结果惊呆了，增加的两三千个文本，居然是“某某试炼关卡第1关”一直到“某某试炼关卡第2000关”。于是我就找到制作该试炼关卡功能的前端问原因。原来这些关卡的名字，是策划配置在Excel表里面的。一开始的时候，这个功能只有几十关，策划不想找规律，就直接和前端程序说，每一个关卡的名字都配在表里面。结果后来策划发现几十关不够，一下增加了两千多关。对于策划来说，这个关卡名字在Excel表里面只是拖一下列就解决的问题，所以策划并没有感觉到配两千多个关卡名字有什么困难。但最终，却导致了提取文本翻译的时候出现了问题。其实也不算什么问题，只是增加了很多明文字符串的容量，还有翻译是按数量收钱的，无端端花了一些钱而已了。
  对于上面的情况，解决办法很简单，直接用一个format字符串“某某试炼关卡第{0}关”，然后传入关卡的序号就行了。这样提取的翻译文本只有一条。这么简单的解决办法没有使用，而是到最后暴力的强制填表解决，这是为什么呢？
  原因有2个：
1、策划懒
  策划在制作功能的时候，可能自己都没有想清楚关卡的名字需要怎样去规划，就简单粗暴的叫程序员留给他配置表字段，等他想好的时候再配。
2、程序员懒
  程序员在制作功能的时候，是看着策划文档来做的。策划既然这样要求，似乎照着做也没什么问题，不想思考多一步假如以后有变化时怎么办。
  发现了这个问题之后，我在前端程序员的群里面说了一句话。有些人做功能，做完之后怎样扩展都是很顺利的；而有些人做功能，后续只要稍微扩展一下，就要各种推翻重做。这就是水平的差距了。
  如果在设计一个功能的时候懒，觉得可以暂时应付了明面上的需求就算了，其实是给自己或者其他同事埋下了坑。在做一个功能的时候，我们需要思考的东西除了明面上的需求以外，其实还需要思考一些额外的东西，比如当功能增加数量、增加类型之后，我们怎样去实现？假如需要对应的数据结构可能有多种，我们又怎样去适配？假如有可能某些情况下数据会是空的，我们又怎样去处理？这时候能体现出技术的地方就很多了。
  也许有些朋友会认为，既然策划的需求是这样，他都告诉我们情况只有这么一种两种，我们还有必要多此一举的为他思考扩展性吗？
  和我一起工作过的同事朋友们，或多或少都会听过我一句名言：“不要相信策划”。为什么这么说呢？我并不是歧视策划同事，而是在很多情况下，他们根本没有决定权。
  作为执行策划，他对功能的需求有自己的理解，但在整体的方向上他不能决定的，他们写出来的需求文档，有可能是照抄别的游戏的，别的游戏变化的时候，他的需求自然也就变化。也有可能这个需求是主策划要求做的，当主策划觉得功能不合适的时候，随时也是会有改的可能。
  作为主策划，很多时候也没有决定权。当一个功能做完之后，如果老板觉得不满意，或者发行方觉得不合适，随时也是需要改的。
  在这种情况下，策划说什么都不能算数，他所说的话，只代表当前这个时间段的需求。如果我们相信了策划的话，完全没有给功能在设计上留有后路，以后面临着修改的时候，程序员再理直气壮的说：当时就是策划说要这么做的，现在要改，就要推翻重做了。程序员们也可以思考一下，当“需要推翻重做”这句话经常在自己的口里面说出来的时候，是不是需要反思一下，自己在做功能的时候，有没有偷懒了。
  不过从消极的角度考虑，其实推翻重做也不是什么大问题，毕竟大部份的游戏公司都是无条件强制加班的，如果不是经常需要推翻重做，哪里有这么多事情做需要整天加班呢？总不好意思明目张胆在公司玩游戏睡觉吧？经常需要重做，天天加班时都能有充足的工作量，说不定老板还会觉得你勤奋。