本篇接上一篇《开发实践思考（二）》，继续将之前散落的思考点汇总，每篇10个。
1. 撰写工作总结
在撰写工作总结时，要从平常事务性工作中提炼出工作的含义，先说这些事情的意义以及目的，然后从同个目的的众多事情中，选取三四件重要的事情简要概况下，最后说明下做这些事情达到的结果。
例如，最近删除了一些冗余文件，包括有A功能文件、B配置文件等。这个动作本身是清理不再使用的文件，往上提炼，可总结为清理冗余代码，优化编译速度和项目结构之类的描述。从具体琐碎的事务性描述（做了什么）上升为（做这些的目的和意义）。
职场工作是以结果为导向。任何工作活动，都要有结果，要清晰地知道目标和目的，一切以实现目标结果为导向。
为实现公司、部门层面的目的，可以不用局限于岗位属性，技术人员可以站在商务角度考虑问题，产品也可以了解一些技术原理，这些方式、技术、工具、能力，都只是手段，重要的是目标是什么，是否达到了预期目标？
目标和目的的区别：
目的是做事的原因、动机、最终效果，较为抽象、概括，比如，挑战自我，自我提升。
目标是做事的具体结果，较为具体，比如，登上珠穆朗玛峰，学习项目管理。
一般来说，目的是坐标，目标是方向，先定目的，再定目标。
2. 清理代码时，不要清理非相关的代码
当你准备删除一个文件，但其他地方虽有引用该文件，但已无代码使用。这种场景，建议先通知其他引用文件的维护人员，通知他们先删除对应的引用，等他们删除后，再删除文件，这样，按照先删除依赖，再删除文件自身的方式，安全高效地进行删除操作。
3.每个技术方案都有优缺点，一旦选择，那优缺点都要接收
4. 错误提示语设计
错误提示遵循总分设计。先说总的结论，再说详细信息。
错误信息既要给用户看，也要给开发人员看。给用户看的要一针见血，说主要错误情况。给开发人员看的，要能根据错误信息追溯到哪个模块的哪个请求出错。要达到这样的目的，可按照如下方式来设计：
比如，一项查资金的功能，可以设计为“查资金失败，失败原因：XXX(YYY)”。
其中的，XXX为接口返回的错误描述信息，YYY为错误码。
如果某项业务是由多条指令配合实现，在执行过程中，为能从错误信息中明确区分是哪条指令出错，可增加一些更具体的错误原因。例如：“查询失败，失败原因：查XX指令，YYY(ZZZ)”。其中，XX为特定指令的功能性描述，YYY和ZZZ为接口返回的错误信息和错误码。
较好的错误信息不回暴露后台内部实现细节，如果有些接口实现的不好，前端可和产品讨论模糊提示的方式，避免更为具体的信息。
以上的错误信息设计格式，有较好的可读性和语义，看到错误信息能够快速追溯是哪条指令出错以及错误信息是什么。
5.避免工具人思维
在接收到需求时，不能仅仅停留在完成这件事情上，要主动问一句做这件事是要解决什么问题，达到什么目的。如果仅仅是完成这件事情，而不知道做这件事的目的，那就成为工具人了。
有没有可能达到同样的目的，有更好的方式呢？
有没有可能目前这件事情对它要达到的目的没有帮助，可以事先分析，避免做无用功的？
6. 限制功能强大的接口
如果一个业务接口入参很多，支持的业务也很多，直接暴露调用方，调用方需要知道各种业务的接口入参说明，一来容易用错，二来增加不同业务的耦合。
针对功能强大的接口，如果后台无法提供细粒度功能的接口，前端可以针对接口业务进行分类，按业务大类对该接口进行二次封装，简化不同业务大类的接口入参，每类业务的入参只和该类业务相关，不同业务也有了较好的隔离，外部也不易用错。
7. 备注Bug的注意事项
在开发过程中，对某个Bug进行修改后提交测试，测试验证不通过打回来，再进行修改，后续提交要按照时间线流程提交，而不是修改前一次的提交备注信息。
这样操作，保证Bug单上的修改变动记录与实际代码相吻合。
8. 错误处理流程
一项业务操作中，通常会关联多个步骤，前一个步骤（A）的输出是后一个步骤（B）的输入
这里犯过错误，没判断A步骤的正确性，将输出给步骤B，由B来判断A输入的正确性。从B的返回结果上，没有区分是输入A的错误，还是B自身的错误，提示混乱。
这里犯的问题是混淆了不同业务流程的错误处理，将多种错误情况都放在最后来统一判断和使用，这是不严谨的做法，思考上的偷懒。
严谨的做法是，每一个步骤的错误提示都单独处理和提示，如果后一个步骤依赖前一个步骤的输入，那后一个步骤出错时，只能代表这个步骤本身出错，不能推导前一个步骤的输入有错。
小结：一个函数出错，只能代表这个函数所表示的操作出错。即使该错误码设计时区分了不同类型的错误，针对入参的显示错误，应该由产生该入参的函数的使用者来判断，而不能由使用该入参的函数来判断。
9. 承认自己的能力局限性
要对自己的能力要有清醒的认识，承认某些事情做不了，不是什么丢脸的事情，这比贸然接下，然后埋头钻研，最后达不到预期结果的情况要好。
10. 转移接口返回的字段不能引起二义性
在接口返回多个相关的概念时，不要自作主张给他们另起名字，造成内容和提示的不一致。
比如，接口返回字段叫"合同编号"，界面展示为"合同序号"。一字之差，即使内涵是一样的，但表现上的差异，很容易让人造成误解，要尽量避免这种不一致。
有时候，可以为了更加清晰地说明而进行补充，是可以的。比如接口返回的数值是以港元为单位，显示为"价格"时，可能会造成误解，这个价格的单位是人民币呢？还是港币呢？为了消除这种误解，可以写成"价格（港元）"，这样，可以更加准确表现接口返回值的含义。
再比如，接口返回的比例数值已换算为百分比数值，展示时可写为"利率(%)"，这样，也可减少误解的产生。