一  必要性

某终端产品在同一线程内处理远程升级消息和普通配置消息。终端必须在指定时间内处理局端发来的消息并应答，而升级消息大约有数千甚至上万条。工程师担心会发生这样的事情：在终端忙于处理升级消息的同时，局端下发普通配置消息，很可能无法及时响应而导致超时(timeout)。如此看来，似乎需要再创建一个线程专门处理软件升级消息。
     但是，真的有这个必要性吗？终端升级后必然要重启以便新版本生效；而下发的配置信息并不存盘，重启后丢失(再次上线后由局端自动下发)。既然配置信息在升级重启后生效(重启前生效则升级意义不大)，那么最好在重启后离线或在线配置。此外，考虑到安全性，远程升级的同时应该不会下发普通配置消息。
     综上，升级同时配置的场景可以不予考虑。

二  可操作性

某司两大园区均有通勤班车。但某些线路下班班车只停靠A区，这些线路的B区员工需要先乘坐摆渡车至A区再改乘下班班车。
     经过问卷调研，班车管理处决定将两区下班发车时间(相同)提前，但摆渡车发车时间不变。考虑到天气和路况因素，特别声明：若摆渡车未到达A区，则A区班车须等摆渡车到达后发车。
     不幸的是，管理处并未解释这条特别声明在现实中如何操作。A区班车如何得知摆渡车均已到齐——狼烟？旗语？信鸽？消息树？对讲机？……好像都不靠谱。
     于是不出所料，A区班车只遵守规定的发车时间，哪管摆渡车是否到齐。而博主则每天狼狈地赶摆渡奔波两区……

三  人性化

左图为A产品页面光功率参数显示，右图为B产品页面光功率参数显示：

其中，B产品按照电信规范单位显示，而A产品对其进行了单位转换。

个人理解，电信规范所定义的0.1uW、1/256°C是为了保持一定精度，因为上报的参数均为整型数值，单位越小精度越高。但对于界面显示，应按常规认知加以转换。很明显，对于使用者和维护者而言，53.4(°C)比13674(1/256度)更加“人性化”。因此，建议显示如下：

几个关于设计的小问题