简要前提

前一阵子工作中需要对一个已经开发过一部分功能的工具继续进行修改，途中踩到了很多坑，抛去技术层面的坑来说，从设计角度就应该有一些思考来规避这些坑，可能就是关于产品中一些细节没有考虑到位
也渐渐理解了之前看过的程序员吐槽大会中《人人都是产品经理》的一点含义，从程序员角度出发也需要对一些设计有较好的考量才能事半功倍
接下来就来描述一下从工具和设计本身出发我遇到的一些坑以及是如何解决的
1.陷入他人的设计框架中，不敢打破
因为是接手他人的项目，在代码中总是畏手畏脚，不太敢动之前的内容，导致出现了很多bug，以及很多无用模块造成代码阅读困难，其中最为主要的就是通信交互的报文设计，没有考虑到实际生产时的场景，对于报文的设计应该考虑到与通信方式的匹配程度，例如串口通信就应该考虑好校验和数据缓存区的问题，就需要对于设计上考虑好报文大小以及校验码校验问题以保证数据稳定性，一开始按照他人的设计，虽然在实验室环境下没有出现问题，但是实际上线后，发现在其他老旧机器上运行起来十分吃力，后面对通信双方都进行了重构，除了保证了通信的稳定性和准确性之外，还加入了重传、人为确认等手段
2.文件查找替换不方便，设计自动替换功能
在旧版的工具中，对于需要用到的数据文件需要用户自己从文件系统中查找，这样子容易出现错误，用户有可能点击错误造成数据浪费，优化的方式是利用现有的查询接口对服务器上数据进行查询，在查询到可用数据为0后，到本地指定文件夹内根据配置文件填写的路径配合字符串检索方式自动替换到下一个序号的文件，这样子极大的减少了人为的错误，因为这个文件替换功能本身是具有一定的不简明，所以人为查找出错的概率很大，虽然减少了用户的自由度，但是对该功能进行自动化替换更为合适，因为你不能保证每个用户和你一样熟悉这个工具的时候，就尽量少把主动权交到他们手中，避免造成意料之外的情况
3.多台机器如何并发
一开始我有看到技术文档中写明了对于交互过程中，有依靠id进行区别，因为服务端的程序不是由我写的，所以我只要考虑客户端每人都有不一样的id去与服务端进行交互就可以了，但是后面发现因为大家都具有同等地位的话，有可能造成数据浪费的情况，例如两台机器进行请求，第一台正在请求中，恰好请求的是最后一个数据，后者则有可能会上传一个新的数据集进行干扰，所以后面的考虑是设计一台机器为主机，具有上传功能，其余的从机只能进行请求的查询，这样子就能保证数据文件一直是按顺序使用下去的，不会有其他机器干扰上传的这个动作，分清楚不同的功能是否具有并发的可能再去设计程序，才能使得工具上线问题不会层出不穷
4.网络波动造成接口异常
对于异常的处理其实是很多设计中需要特别考虑的地方，如果一些异常类型都没列全的话，后面调试起来想找到问题所在也会变得十分困难，这个问题就是我在初步设计的时候没有考虑好的一个问题，后面上线后别人和我翻译出现跳号问题，我拿了log分析了半天依旧没有找到原因，就是因为我对于异常的分类还不够具体，只是知道问题可能出现在了某个环节，但是具体出现在哪我依旧无法准确定位。最后的解决办法是对于程序的部分接口不能完全信任，尤其是这种网络通讯的接口。更加应该有严格的验证机制和人为监测加入，最后功能被改成了重复查询+人为依据数据显示进行判断，虽然这种方式看起也不是很方便，但是至少从工具方面出发出现跳号需要经过双重验证都出错的情况才会发生，减少了出错的概率

软件产品除了代码稳定性和功能可用性，其实更加应该考虑的是从设计出发、从用户出发、从简洁出发，同时也要考虑到用户使用时可能出现的各种情况，对异常情况做好最详细的分类，才能保证软件使用起来不是一头雾水