我司一个外包人员让我开眼了

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

已注册用户请登录

这是一个创建于 355 天前的主题，其中的信息可能已经有所发展或是发生改变。

一个驻场外包，入职半年，技术挺好，但考虑问题不全外加毫无代码规范，上线过几次，均出问题，代码别人看不懂，制定了开发规范一直不遵守，沟通交流有障碍，无法正常交流，且拒绝别人修改他写的代码，就要自己改，另外人也不干净，散发一股味道，组里所有人均对他有意见，因为年龄已经 37 了，领导心软给了一次次机会，最后不得不退了这个人，然而退场当天，他一言不发，坐在工位不动，最后硬是让保安把他工牌强行收走，给架出去了，之后的两周，一直骚扰公司同事和上级领导，让给机会，表达想回来的心情，更逗的来了，过了一个多月，今天收到简历，又有他，是另一家公司推荐的，我真的第一次见这种人，感觉是不是有些心理问题。

代码

工牌

规范

工位

127 条回复 • 2024-04-15 15:52:49 +08:00

1 2

❮

❯

101

adoal

354 天前

这不叫技术好。只是喜欢、好奇而已，甚至可能只是自以为喜欢、好奇。“好”是看结果而不是动机的。

给你举一个技术好的例子：

## Linus 亲手帮英特尔优化 LAM 代码

去年年底英特尔将 LAM （ Linear Address Masking：线性地址掩码）功能提交到 Linux 6.2 的合并窗口，但该功能受到 Linus 的批评并拒绝合并。在经历了一段时间的代码改进后，Linus 终于同意将 LAM 代码合并到 Linux 6.4 窗口。

但 Linus 似乎仍对英特尔工程师提交的代码不太满意，在合并了 LAM 代码后，先是写了一个使 access_ok () 独立于 LAM 的新补丁，而后又亲手写了多个补丁对 LAM 代码进行了优化。

在最新提交的 LAM 优化补丁中，Linus 解释了自己的动机：

> 我对此版本中的 LAM （“线性地址掩码”）的 “access_ok ()” 的完成方式感到很不爽，而且它实际上也有一些小 Bug ，所以我动手清理了代码。

改动主要集中在以下几方面：

* 使用 __user 指针的符号位而不是屏蔽地址，并根据 TASK_SIZE 范围检查它。 get/put_user () 端做了这部分，但是 'access_ok ()' 做了天真的 “掩码和范围检查”，它不仅生成多余的代码，还意味着 __access_ok 本身的任务做得不好，copy_from_user_nmi () 没有得到正确的检查。
* 将所有 64 位代码仅移动到 64 位版本的头文件中，这样就不会污染共享的 x86 代码，也不会误导用户 LAM 可以在 32 位环境中工作。
* 修复地址掩码中的 Bug （这不重要，只是完全删除了错误的代码）。
* 几个简单的清理，并添加了关于 access_ok () 规则的注释。

Linus 重新编写了约一百行代码来清理 LAM ，这意味着如果测试没问题，就可以在 Linux 6.4 中顺利启用 LAM 功能。不过这次 Linus 竟然亲自动手为英特尔工程师修改 “有瑕疵的代码”，这种情况相当少见。