已发邮件，麻烦帮忙推一下！希望有机会共事：）

@mansurx 我这里向日葵和 anydesk 的体验非常糟糕，深圳电信

我前不久也卖了一个 v500，50 包邮的。看来我比较幸运

@lazydog 美国的鞋子尺码一班有对应的脚长和脚宽，自己量一下就 OK 了。在天猫上买鞋很多都不标明宽度，因为我的脚属于比较宽的，经常导致长度合适，但是宽度太挤。。

中铁快运

看起来很漂亮，这种服务最重要的是稳定吧？不知道是怎么计划的？

要求不高是多少啊？

挽尊＼（〇_ｏ）／

没有 UI 图啊？我体验这种项目主要是看他够不够好看😊

我用的 edge 浏览器，感觉还行

@ipwx 我现在对“业务代码”的理解，在于开发人员是否总是站在一个比较低的层面，仅仅为了实现需求而写的代码，虽然实现了功能，但是代码质量或者说工程质量可能是很挫的。

与之对应的是，开发人员站在更高的层面，自上而下的设计代码，有更强的抽象能力，有更好的伸缩性。

看了上面这些网友的回复，我觉得对于一个普通的开发人员，整天忙于迭代功能的情况下，很难跳出来，做到后者。

@loading 提到的探月工程和前面说的操作系统，这些复杂的大型项目，如果只靠这些站在低层面看问题的人，我觉得会出很多问题。

看了大家的回复，我对写“业务代码”有了新的理解：

高质量的业务代码是高级架构 /抽象 /框架技术的基础。
对于一个团队的产品，或者对于一个工程师来说都是这样。

而给别人带来一种“写业务代码很 low ”的印象，一部分是因为大部分工程师的水平太普通，一方面可能是缺乏提升自己的意愿；一方面也可能是所处的客观环境，需求更新过快，整天都忙着实现功能去了。

当然也有一部分是因为有些评论者，他们离业务场景比较远，总是站在一种技术至上的角度，认为时下流行的、大厂使用的就是最好的。

很同意一位网友的回复：

**“技术只是工具，业务才是目的。”**

@yangzhezjgs 业务代码写久了确实提升不大了

@lincanbin
@ipwx

微软这种写操作系统的也算是业务代码？？我觉得写操作系统的需要很强的抽象能力。

@casillasyi
@Jonz
@EKkoGG

看了你们的回应，我知道了除了只实现业务功能之外，还可以搞搞框架，和轮子什么的。

但是感觉小厂的开发人员配置比较紧张的话，也很难有时间做这些吧？

@DOLLOR 楼主的意思是百度百科有必要不定期的检测并更新外部饮用信息的有效性。

@zhenjiachen 真好啊

初级的可以去锻炼下吗？