开发不是运营
- 次阅读
我是一个软件后台开发工程师。最近有个需求，大致是公司要变更企微主体，因为销售的员工会用企微办公，需要在公司的内部系统批量做这部分员工的企微切换。
事情就是这么个事情，活到了技术这里，怎么搞呢？我给出的方案 A是，直接在内部系统做一个变更员工信息的功能，支持管理员直接修改员工的企微信息，这样哪个员工需要变更可以随时操作。当然，还有另外一个方案B，就是功能不做修改，通过改底层数据库里面的员工信息来实现。
原来这个内部员工系统是我负责的，最近公司扩张招了挺多人，就把这块的业务分出去其他同事负责了。我给了他们这两个方案，叫他们自己考虑选哪个。结果我主推的方案 A不愿意做，直接选择的是手动改数据库。
虽然不是我做，但是我听到他们的选择后还是挺失望的，失望的是找不到人和我一类。如果是明确的只需要改一次，那确实没必要做一个功能，但实际情况不是，就这个关联企微的就调整过很多次了。虽然不是高频使用，如果系统支持这个功能，那后续怎么使用就是对应的操作员来处理了，如果不支持，每次有变更的时候来找研发手动改数据，这个味道就变了。
编程里面有个叫概念，叫代码的“坏味道”。如果业务上有问题每次都需要找开发来定位解决，在我看来就是系统或者公司运作层面的“坏味道”。有些人会觉得系统就是要时不时出现点问题，然后可以在老板面前多露脸。或者让其他人时不时就要来找你，提升你的存在感和重要性。当然，也有些人就是看一个需求做一个需求，没有规划或者设计的概念在里面。
我不觉得，在我看来，作为一个开发，首先应该要有软件设计的意识，软件设计就是应对需求的变更，设计做的好，无论外部怎么变化，系统已经规划好这个能力来支持了，设计得不好，要加个需求就是拆拆补补，这样不行那也不行。有点追求的人就应该想想怎么设计得好。其次，你只是开发，工作内容是开发一个好用的系统，而不是每次出来解决业务问题，那是运营的职责。如果每次有问题都来找开发，是不是能感觉到坏的味道。
当然做研发有些时候会受制于上游的需求，但是实际的开发实现和系统设计并不受影响，只看开发者的能力水平，好的系统应该是让人感觉不到异常的存在的，这个功能就是应该要有，这个按钮就是应该在这里，不会有其他突兀的问题或者不舒服的感觉，这里看起来不太对，那里看起来怪怪的。只能说明这个做的垃圾。
所以我在公司的追求也是一样。我开发的系统，接口和文档我设计好后，和我对接的人就不应该再来找我，如果因为要来找我，那说明我做的还不够好。我做的系统上线了还需要时时跟进来定位问题，那这系统做的不行。
什么叫好的系统，就是用它的人感觉不到它的存在。
就像身体，健康情况下你是不会感知身体是好还是不好的，只有在生病的时候，你才知道健康的重要性。
做一个健健康康蹦蹦跳跳的人。