公司有一个项目，我负责项目的Erp模块，而队友负责图片识别这块，由Erp模块向图片识别模块发送指令，图片识别这块再进行相关运算，最后把结果返回给Erp模块。系统之间的数据结构基本上都是我跟队友开了好几个会商量好的，因为项目比较简单，所以很快项目就到了收尾阶段。
但好事多磨，之前跟我一组的队友因为某种原因项目还没结束就离开了公司。因为我的项目还有一些东西需要完善，于是公司的研发总监决定跟我把剩下的部分一起完成。
但谁知道，研发总监进入我组后，我的代码却因为研发总监的各种要求，最后被改得面目全非！
其实作为一个程序员，尤其是一个项目已经到了尾声的时候，程序员最难以接受的就是需要将代码从头改到尾，改到违背当初设计这个程序框架的初衷。而我，正在经历这样的事情！
简单说一下事情的经过吧！
我们公司的研发部门其实分成几个小组，每个小组有个项目组长。我的直接上级是我所在项目组的组长，但是由于之前跟我配合开发的队友走了，临时找不到人接替他的工作，于是研发总监决定亲自上场！
其实项目到了最后，只需要对接一下数据，确保客户端和服务端的数据结构是一致的就可以了。之所以要改，是因为我们的研发总监认为，有好几个接口的数据请求结构以及数据返回结构都差不多，于是就想把这几个类似的接口合并起来。
项目因为开始是我设计的框架，之前不是没有考虑过这个问题。虽然这几个数据接口的结构类似，但是分属于不同的功能。为了以后方便拓展和维护，于是我就将接口分开来写，本身我这么做，其实也怕别人说的，但是考虑到拓展性，我还是将它们分开了。
但是，既然这个问题被研发经理提出来了，我只能跟研发经理解释，说这么做是为了方便拓展。
但是我们研发经理说这个项目本身就很小，未来估计没有拓展的必要了。总之，意思就是要我按他的意思改。
于是，几个数据接口就被改成了一个接口，分别返回不同的数据结构。请求数据的接口也变成了一个，其中由一个变量来表示需要什么数据。
看似很简单的变动，其实我在Erp模块那里需要改的东西还不少。我以为仅仅是我多考虑了一步，他觉得没必要多考虑这一步，所以要求我改代码。但是，接下来发生的事情，让我对他的看法产生了变化。
本来，在我写的程序中，有一部分数据需要保存在数据库中。虽然数据不多，但是使用和修改的频率挺高。可是，他可能觉得他的程序在访问数据时还要和数据库通讯，觉得麻烦，于是要求我在指定的文件夹内按照数据库ID创建多个数据文件。这样一来，他只需要使用ID去检索对应的文件，然后对文件进行读写，最后再返回给Erp模块，我再去更新数据库。
我告诉他，万一他那边写完数据，我在接收时出现问题可能会出现数据错乱或者数据冗余。但是他给我的回答却是让我不要担心，这种做法他以前经常做，从来没有出现过问题。
没办法，我只能听从他的安排，在代码中增加了相关功能。
可是，因为文件的读写和创建我们两边都有可能做，我这边会先将数据保存到数据库再取数据ID创建文件，所以我这边除了我上面所担心的事情外，基本上也没什么问题。但是他在创建文件的时候，因为不跟数据库交互，所以创建文件时还没有ID。于是，他竟然要求我在数据库还没数据的时候把ID给他。
我自然不同意，表示数据库的ID都是自增的，我怎么可能给他ID呢！结果，他告诉我，可以用查询语句查最大ID。
我告诉他，这样的话，异步保存数据时可能会出现ID冲突的问题。结果，他还是那句话，之前他也经常这么干，从来没有出现问题！
就这么着，我之前写的代码在他的一再要求下，不断地重构，重构到最后我脑袋都被转晕了。各种违反程序设计的理念在他那里竟然被说得非常合理！总之，让我看不出来这个人已经有了将近二十年的编程经验了！
因为之前项目都是小组讨论，一般都能达成共识。而想法的冲突不是没有，但是很少见。像这种想法碰撞时，处处都能擦出火花的场景，真的很少见！
现在再看看我的代码，处处藏着风险。我只能以我多年经验，把这些风险降到最低。但是，明眼人一看，这种代码在某些环境下是肯定会出问题的！
联想到我们公司最近的经营状况，我突然豁然开朗，有些软件公司活不下去，可能真的不怪老板没有用心经营！
虽然这个项目很小，但是以往经我手我设计的程序框架从来都没有出现过大问题。再看看被修改得体无完肤的代码，我根本不想承认这些代码是出自我手！
我才来公司不久，本来对我小组的感觉非常好，但是有这么一个研发总监，真是一言难尽！如果说以后还想继续在这个公司做下去，和他少沟通，或许对我的编程水平会有所帮助！
