你应该要知道：在绩效管理下，你愈是认真负责，愈是做到符合专业伦理的要求，你反而看起来绩效愈差。而你大概会有 87% 的比例，会遇到这种绩效管理。

举个例子，假如你是警察，你决定要认真抓小偷，于是上个月在你的管区破获了五十起窃盗案，这个月因为你的努力，破获的案件增长到一百件— 这代表什么呢？这代表看起来你的管区治安变差了，而你应该要为治安变差负责，你才是应该被检讨的对象。于是你知道，警察好像应该要想办法破案，但实际上，你的绩效并不是来自破案，而是吃案。

如果你花了半年时间，抽丝剥茧理清了复杂的商业逻辑，建立了清爽明确的抽象层，并且预先额外设想了其他的使用情境，最后开发了一套易于扩充的软体架构，让一个大学刚毕业的新人，都可以在你的架构上不到一个星期就可以开发出新功能。这代表什么呢？这代表你的绩效很差— 你的管理者只会看到，你花了半年才做了一件事清，一个新人刚来，却只需要花上一个星期就可以完成一件事，那还要你来做什么呢？

至于可以轻松开发出新功能的新人，他会怎么看呢？可以这么快开发出新功能，当然是因为他自己的功能啊！跟你有什么关系呢？真的要了解你到底做了什么，其实只有一个办法，就是要阅读你的程式码，但，放心好了，不会有人会去读的。

你要做的事情就是：管理者设定了什么绩效，你就想办法达成什么绩效。如果管理者设定的指标是你修好了多少 bug，那么你就要想办法一开始就在你的程式中制造许多 bug，免得日后需要修 bug 的时候没有 bug 可以修。如果管理者的目标是加速开发，你就应该要不计后果加速开发新功能，明知道是加速迈向毁灭，你也要加速开发。

事实上，身为软体工程师，你也根本不用考虑后续维护的问题。如果你在一家公司写了一大堆完全不考虑耦合关系、程式逻辑纠缠不清、命名混乱、使用大量anti-pattern、到处都是怪气味、效能极差而且宛若天书的程式码，而你开始为了继续维护这样的技术负债感到痛苦的时候，其实只代表一件事情：你已经在这家公司呆得太久，而且还没有升上去当主管。

这个时候你就会知道加速开发的好。你完成了这么多项功能，于是在你想要换工作得时候，你可以写出洋洋洒洒的履历表— 反之，你会把你写了几条单元测试、达成多高的覆盖率这种数字放进履历表里头吗？把力气放在测试这种无助于发展事业的事情上，完全就是在浪费你的时间。

你也同时应该感谢— 不晓得是谁想出来软体产业园区这种德政，原本制造业的产业园区是让上中下游供应链可以集中在一起，降低运输成本，但软体这一行又没有供应链这种事情，成立园区只是让相互竞争的软体公司其中在一起，唯一降低的就是人员流动的成本，换工作都不用搬家。多好啊你看。

如果你有机会高升，开始担任主管（你绩效这么好，怎么可以不选你当主管呢？），你就会知道，当初写下的那些无法维护的legacy code，其实更有助于你担任主管的管理工作。

担任主管最重要的工作，不是别的，就是一边把持住自己的位子一边想办法继续往上爬，所以主管绝对不可以让部属表现得比自己更优秀，而你当初写的程式码，就是部属事业道路上最好的绊脚石。你除了可以一边抱怨为什么新功能开发愈来愈慢，一边说嘴当年你只花了多短的时间就写了多少程式码，果然只有你有资格担任大家的主管。

而到了这个时候，你还会发现，程式码到底是什么品质，已经跟你的绩效无关了。怎样尽可能的接触老板，参与更多会议，让老板三不五时看到你，才是你现在的绩效。

当然，总有一天技术负债会大到你的部门什么东西都做不出来，你的公司什么服务都拿不出来卖，但是这一点都不会影响你找新工作，你瞧，现在，你的履历表上面，可写着你当过主管呢！拿着这份履历表，你更有机会去别的地方，空降担任更高阶的主管。

技术负债从来就不是什么问题。谁说你制造了技术负债之后，你就得要自己还债？怎样欠债不还，才是工程师最伟大的艺术。

在你的人生中，你不需要要为其他人而活，也不是为了程式码这种死物而活，你真正应该要负责的对象只有你自己；而你知道人是经济而自私的动物，既然你的本性就是贪婪，你就应该成就贪婪。管理者想要这种工程师文化，你就提供这种工程师文化。

你要舍弃专业才能成就事业，你应该要把握当下的绩效，而不要为了可能不存在的悲剧结果恓恓惶惶，你每天都应该充满正能量，还有什么可以比利己主义带来更多正能量？凯因斯不就曾经说过：「In the long run, we are all dead」？

身为软体工程师，你应该放心大胆地创造技术负债。这么做唯一的风险，就只有在你换工作的时候，也会接手一大笔前人留下来的技术负债。不过，这种事情反正也早就已经发生了。

原文链接：https://p5d12000.medium.com/%E5%B7%A5%E7%A8%8B%E5%B8%AB%E6%87%89%E8%A9%B2%E6%94%BE%E5%BF%83%E5%A4%A7%E8%86%BD%E5%9C%B0%E5%89%B5%E9%80%A0%E6%8A%80%E8%A1%93%E8%B2%A0%E5%82%B5-a8022d85810

1. 一个英语思维的问题

英语中对一个东西的所有权看得非常重，不管是抽象的还是具体的，特别注重区分是你的还是我的。英语常常从一个东西的所有权出发来表达各种各样的意思，从 have、give、get 延申出来的广泛用意就可以看出来，举个例子：

you have my word.  我向你保证

保证，I promise！但是口语中正式承诺时更多是用上述例句，通过这种归属权的划分，句子后面要表达的意思也一目了然了。

再比如：

Do you have my pencil?  你拿了我的铅笔吗？

同前一个例子，通过这种对所有权的状态描述，所要表达的意思也不言自明。

还有一些例子，大家自行体会

May i have your name?
They'll have a party for their 10th wedding anniversary?
You can have this back when 5 pages are done.
where do you have your lunch?

从所有权的角度看完成时

来一个简单的现在完成时的句子例子：

I have finished my homework.

如果我们从所有权的角度来理解完成时，这里的 have 可以理解为「拥有」：对于「做完了作业」这件事情，我已经得到了所有权，也就是「完成」了。所以语法书上会说现在完成时是：描述过去发生对现在造成影响的动作，或从过去开始一直持续到现在的动作，其实也就是用来强调所有权。

现在完成时（Present Perfect）
I have finished my homework.

过去完成时（Past Perfect）
By the time we arrived, the movie had already started.

将来完成时（Future Perfect）
By 2025, scientists will have found a cure for that disease.

过去完成时用had，则是想强调在过去的时候就已经 have 了所有权，所以要用 have 的过去式。

至于完成进行时，不过是在上述思维的前提下叠加了进行时态的作用，大同小异：

现在完成进行时（Present Perfect Continuous）
She has been studying for three hours.

过去完成进行时（Past Perfect Continuous）
He had been working at that company for five years before he quit.

将来完成进行时（Future Perfect Continuous）
She will have been working here for ten years by the end of this month.

我和朋友分享这一发现，对方的评论把我的认知拔高了一个层次

（题外话，动词过去式为什么要加ed，因为是过去完成的动作，已经end）

还记得很久之前刷过一条 tweet，推主在他的 IDE 里安装了 GitHub Copilot，在写周报的过程中，Copilot 帮他自动补全了周报，当时觉得挺有趣的，也截图记录了这条 tweet。

截图的这个时候我已经自用 Copilot 快一年了。还记得我刚开始试用 Copilot 就被征服，那一年多的时间里经常向同事安利 Copilot ，那时候很多人对 AI 的认知还停留在上一个时代，我向别人安利的时候经常不知道要怎么说服他们使用。我手把手向他们展示了很多功能，他们都表示说有点鸡肋、不太需要。有一次我跟一个同事安利的时候，脑子里浮现了上面的截图，我说：“这个东西可以甚至帮你写周报！”，大家哈哈大笑，从此这个 idea 就印在了我的脑海里。

有一天刷推特，看到有很多人在推荐这个网站：聊天简化器，网站本身没有什么技术含量，就是套了一个壳，请求一下 OpenAI 的 API。但是那时候 AI 的风刚起，虽然知道原理，但是这种有点 magic 的功能还是非常有新鲜感的。2023-02-09 上班时间，我用这个网站模板修改了一下，改了一下 Prompt 就马上上线了。那时候还请倪爽老师帮忙推荐了一下。

那天晚上睡觉后在床上躺着翻来覆去左思右想，我强烈感觉这东西肯定能火，于是 2023-02-10 凌晨一点，我爬起来在 V2EX 上发了一个帖子

于是，惊人的流量开始涌进，当时发了几条微博记录了一下

网站部署在 Vercel ，Vercel 的统计功能超出一定范围后要收费，2023年5月份 统计的总 UV 是 73w 左右，现在每天还有 1000 左右的访问，UV 应该超过 100w 了。

GitHub 数据

还上过好几次 Trending

学到了什么

保持好奇心，多接触新鲜事物。人的大脑像一个静止的水池，需要经常汰换新鲜水源才能保持活力。

业务域名最好用一级域名，量起来后想申请谷歌广告可以省一大堆麻烦。

重学英语第一步

只在中国应试教育体系下学过英语的人，重学英语的第一步就是要忘掉老师教给你的几乎所有学习方法。应试教育的第一目的是帮助你取得纸面上的分数，为了达到这个目的，老师会教给你很多所谓的高分技巧，让你学习很多只为了提高分数的知识(比如背单词、抠语法、刷题)。在这个过程中，你学习的方向会慢慢偏离，越到后期，你离真正提高英语水平的目的就会越来越远。

口语的作用

语言的作用，用四个字可以总结：交换信息，只要你在使用语言交流时起到了这个作用，那么你的这次交流就是成功的！理解到这一点，对于语言学习的 祛魅 非常重要，开口说英语时不必害怕、恐惧、羞耻自己的中式口音和中式思维，也不用嘲笑别人的印度、日本、韩国口音，只要能交换信息，就是 好猫。

Andy Weir 的书 《挽救计划》 中讲主角 Ryland 和外星人 Rocky 初次见面后是如何学会用对方的“语言”交流的：

当——当——当——当。

“怎么了？”我看着他说。

他指着还在我手里的字符“λ”，然后又指向我，然后又指向“λ”，指向我。他几乎要疯了。

“哦，抱歉。”我说着摆正数字说，“三。”他挥起爵士手，我也回以爵士手。

哈，既然我们用到了这个手势……

我静静站了一会儿，这样他就明白对话中的停顿。然后我挥起爵士手说：“是。”

我重复手势说：“是。”

他也向我重复这个手势说：“♫♩。”

我在笔记本电脑上找出并记录下频率。

“那么，我们的词汇表里有了‘是’。”我说。

当——当——当。

我看过去，他一看引起了我的注意，就又挥起爵士手说：“♫♩。”跟上次一样的和声。

“是，”我说，“这个词我们搞定了。”

他伸出手指举了一会儿，然后攥了两个拳头并互相撞了一下，“♪♪。”

……什么？

“哦。”我说。我是一名教师，刚刚学会“是”的人我会教他什么呢？“那是‘不’。”

至少我希望如此。

我攥起拳头撞了一下。“不。”“♫♩。”他说。我在电脑上确认了一下，他刚刚说了“是”。

等等，这意味着那个音不是“不”？是另一个“是”？这回我可蒙了。

“不是吗？”我问。“不。”他用波江语说。

“所以是‘是’？”

“不，是。”

“是吗？”

“不，不。”

“是，是吗？”

“不！”他朝我攥起一个拳头，显得很沮丧。

这种跨物种的鸡同鸭讲还是算了，我伸出一根手指。

他松开拳头，也伸出手指。

我在表格文件输入频率，暂时标记为“不”。

错就错吧，随后再弄清楚。

我举起符号“+”说：“四。”

他伸出一只手的三根手指和另一只手的一根手指说：“♩♩。”

我记录下频率。

接下来的几个小时，我们把共享词汇表扩展到了几千个单词。语言类似于一种呈指数级增长的体系。你认识的单词越多，就越容易描述新单词。

我想 Ryland 在学习对方的语言时肯定也有英式思维，说对方的语言时也有英式口音，但是他们可以顺畅地交换信息，这就足够了！理解并认识到这一点对构筑你开口说英语的自信非常有帮助。英语是工具不是目的，不用理会旁人的眼光和讥笑，你只不过在使用这个工具时不太熟练，为什么要不自信？为什么要害怕别人笑你？所以开口讲英语时也不用害怕语法错误、发音错误、句式混乱等，你能顺畅地交换信息就足矣，一切回归实用主义。

口语学习的本质

我有一个可能不太恰当的比方，我把学习语言的过程比喻为构建字典的过程，用程序员的话来说，就是构建 Map 的过程，这个 Map 的 key 是场景，value 是你大脑对这个场景处理后产生的想说的话，这里说的场景包括你听到的声音、可理解的内容、表情、语气、场合、甚至是天气等一切五官感应到的综合的东西。想想刚出生的婴儿到成长到七八岁，ta 是不是在不知不觉中观察大人并慢慢构建母语 Map ？你在学习第二语言的过程，就是从头构建新字典的过程。

所以很明显最好的构建新字典的方法就是有一个可以覆盖你吃喝拉撒的母语圈子，当然这个条件对于很多人都很苛刻，我们只能退而求其次，利用其它方法尽量提高场景的丰富度，让这个字典构建地更快更牢固。

口语学习的一些分享

上面说语言只要能交换信息就可以了，但是如果在一些比较正式的场合，会对你交换信息的效率和质量有要求，比如在工作中，你总不可能在面对面时掏出手机来同声传译，或者结结巴巴地组织信息，下面我就分享一些学习口语的技巧和资源。

不要只背单词

这一点非常基础又非常重要，有很多深受应试教育荼毒的人，一说到学英语就拿着个背单词 App 开始背，如果你认同我上面说的构建新字典的说法，你就明白单单一个单词的场景丰富度实在是太低了，你只学会了孤立地看待这个单词，下次遇到要使用这个单词的场景，你根本就无法把当前场景和这个单词联系起来，因为你只构建了单词的 Key，没有构建场景的 Key。学习过程中如果遇到不会的单词，可以在这个网站 YouGlish 查询，这个网站会在 YouTube 全网搜索，然后定位到使用这个单词的视频片段，这样这个单词的场景丰富度就能提高不少。

一些学习资源

English Pod，是一套非常经典有用的学习英语的教材。两个主持人播放一段对话文本，然后就此文本中出现的各种经典、常用、有用的单词或词组进行讨论，一期十分钟左右， 对英语听力和口语有非常大的帮助。我用 OpenAI 生成了 所有对话的文本，实在听不懂的可以看文本。这套资源非常适合四级水平的人从头学习英语，主持人标准常速的美音很快就能给你大量的可理解输入。

开言英语 App，这个是字节旗下的英语学习 App，感觉他们的课程内容是下了血本的，所有课程都是外教录的，价格也会贵一点。

轻听英语 App、每日英语听力 App，这里面有很多整理好的各种听力资源，各层级的都有，缺点是内容经过审核，有些诸如美剧的某集会消失。

italki App 和Cambly App，这两个 App 上有付费外教，可以在这里约课练口语。

我推荐一个italki的老师 Faith ，Faith 老师有几个优点，一是便宜，一节课一小时才 5 美金，作为对比，欧美的老师一节课通常是 20-40 美金左右，第一节课我就跟 Faith 说，你的课太便宜了，你可以适当把价格调高点，她说她发现只要调高一点点，订课的人立马就会少一大截。二是时区一样，菲律宾时间与北京时间相同，意味着约课成功率很高，而不用像欧美一样有时差。三是 Faith 本身就在菲律宾的政府给政府雇员做英语老师，经验丰富。四是她时间充裕，基本每天下午五点后都有空，一般想练的时候随时可以练。当然也有缺点，Faith 不是纯正的美音或英音，但是还好，算是口音很轻的菲律宾人了，真的听不懂的可以在约课的时候选用 Skype 做交流软件，Skype 有实时字幕功能。

最后再推荐一个王炸级别的练口语 App: Pi，Pi 是一个 AI 助手，有语音通话功能，Pi 的语气、语调、智能程度都非常接近人类，可以随时发起对话，非常便利。注意在 iOS 中只能在非国区下载。

书籍：《英语思维是这样炼成的》《1368个单词就够了》《1368个单词就够了实用篇》，这三本书对于掌握英语思维有非常大的帮助。

自媒体Up：SS学英语，SS的付费课对英语思维的养成也非常有帮助。

投入产出比极不对称

有句调侃：“一杯茶一根烟，一道 LeetCode 刷一天”。LeetCode 的学习曲线非常陡峭，前期需要花费大量时间去熟悉常见的解题套路，熟悉完后要花大量的时间刷题练习，有时遇到一些题，就算找遍了所有相关的教程或者讲解视频也不能够理解，因为每个人对于强逻辑的东西都会按自己的方式去构筑逻辑链，别人的想法只是在指明一条正确的路，但是却没有告诉你如果你走错路了要怎样走出来(现在有 AI 了好很多)。这个刷题过程会耗费非常多的时间和意志力，而你获得的只不过是对你工作和生活都毫无帮助的奇技淫巧罢了。你有这些时间，干点什么不好？

没有帮助

上面说到 LeetCode 对工作和生活都没有帮助，可能有些人有不同的意见，事实上 LeetCode 涉及的那些经典算法你在现实的 CRUD 工作中基本不会用到，你觉得应该要用到了反而可能是你思路出现了问题，业务代码需要引入这个级别的复杂度吗？当然那些经典算法对于构筑程序员的计算机思维还是非常重要的，只不过不用使用 LeetCode 这种方式来学习。实际工作中需要掌握的编码能力根本不是能从 LeetCode 中学到的，关于如何写好代码，可以看看我的一篇blog 控制复杂度的艺术：如何写出好代码 和 piglei 的 入行 14 年，我还是觉得编程很难。

沦为筛选工具的 LeetCode

有没有觉得上面的两个缺点似曾相识？是的，这也是应试教育的显著缺点。网上有一个听起来很俏皮的观点：「学数学没啥用，买菜难道还用得上微积分？」，或者「学英语没啥用，买菜难道还用得上英语？」，初高中逻辑思维不严密的时候还觉得挺有道理，实则应试教育关心的不是你学的知识有没有用，规则制定者只是把这些知识当成了筛选工具，谁在特定阶段对特定知识掌握得最好谁就获得了对这个社会最好教育资源的掌控权。LeetCode 现在也基本成为了面试过程中的筛选工具，你 LeetCode 刷了一千题，对你在实际工作中的 CRUD 或者切图有什么用？但是你只要在面试过程中的刷题环节表现好，你就获得了一些工作资源的掌控权。

不能创造价值的行为

「内卷」这个词刚流行的时候，我第一个想到的就是刷题这种行为，内卷「指一类文化模式达到了某种最终的形态以后，既没有办法稳定下来，也没有办法转变为新的形态，而只能不断地在内部变得更加复杂的现象」，根据上面的表述，刷题既对实际工作没有帮助，又只是面试过程中的筛选工具，但很多人却还是在这个过程中耗费大量时间，让面试刷题的达标门槛变得越来越高，大家花了这么多的时间精力，却没有创造任何有用的价值，这值得吗？面试者付出大量时间精力，招聘方招了一群只会刷题的候选人，受益人只有每个月收会员费的 LeetCode。好不容易逃离出应试教育的深坑，如果可以选，还是把自己的时间多花在能创造价值的事情上吧。

后记

文章有感而发是因为最近经常能看到说刷了八百一千题却找不到工作的帖子，我无法想象这些人刷了这么多题要耗费多少时间精力，行业领军的大公司要用这种方式筛选候选人，也说明这行真的是红海了，这些时间精力还不如拿去创造真正有用的价值。AI 浪潮下，LeetCode 就算是作为筛选工具的作用也是开始式微，希望 LeetCode 早日退出历史舞台。

为什么要写好代码

每个稍具几年工作经验的软件工程师应该都不会有什么疑问，你在入行的这几年里，一定经手过这样一些项目，它们里面有看不懂的变量、看不懂的函数、看不懂的逻辑、奇怪的注释、纷繁复杂的嵌套等，让每一个接手项目的人都有很重的心理负担，每天上班前都要做很多心理建设。每次接手这个项目的新需求或者改动旧代码对你而言都是一件痛苦无比且风险极高的事，这是不注重代码质量的团队所必须承受的混乱的代价。

什么是好代码

我们先来界定一下什么是好代码。必须得承认的是，评判代码的好坏是一件非常主观的事情，每个人都可以有他自己的见解。我对好代码的标准可以用一句话概括，就是在可接受的范围内，复杂度越低越好。此外，好代码有一种共性，正如我标题所说，它们是一种艺术，跟绘画、电影、音乐一样，是一种代表美的事物，你在阅读它们时能够体会到它们的美感，能够感受到一种愉悦。你的审美能力越好，感受的强度也就越高。

如何写出好代码

这篇文章无意像其它列清单式的文章一样列出所有写出好代码的要点，我将通过一些经典的案例来让你感受这门控制复杂度的艺术。它们包含三个方面，命名、函数、注释。并不是说这门艺术只包含这三个方面，只是以我做 Code Review 的经验来说，做好这三个方面可以解决 90% 的问题。

命名

There are only two hard things in Computer Science: cache invalidation and naming things.

– Phil Karlton

计算机科学只存在两个难题：缓存失效和命名。当我在大二第一次听到这句名言的时候，我还以为它是在对写程序的过程中命名难的问题进行调侃，显然，我那时候还没有意识到命名对于写好代码的严肃性。

命名最难的地方在于需要良好的描述技巧和共有的文化背景。命名涉及的方面很多，比如变量名、函数名、类名、模块名、微服务名、项目名等，它们的名称在确立下来之时，就应该回答了大部分的问题。它该告诉你，它为什么会存在、它做什么事、应该怎么用。如果名称还需要额外的解释(注释)，那它就不是一个名副其实的命名，你应该想想如何换个好命名。不要不舍得把时间花在命名上，它很重要。

例1 名副其实

Bad Case:

int d; // 消逝的时间，以日记

Good Case:

int daysSinceCreation;
int sundayNumbersInYears;
int fileAgeInDays;

类似于「d」这种毫无意义的变量，不如具体地描述变量本身，不要怕变量名称太长，长比短好。但也要注意不要在命名中出现废话，Variable 一词永远不应当出现在变量名中，Table 一词永远不应当出现在表名中。用 String 类型来表示名称时就叫「name」而不是类似于「nameString」的冗余废话。

例2 做有意义的区分

Bad Case:

public static void copyChars(char a1[], char a2[]) {
for (int i = 0; i < a1.length; i++) {
 		a2[i] = a1[i];
	}
}

public static void copyChars(char source[], char destination[]) {
for (int i = 0; i < a1.length; i++) {
 		destination[i] = source[i];
	}
}

如果参数名改成 source 和 destination 就会好很多。

例3 添加有意义的语境

Bad Case:
    
monster1_attack = 20
monster1_defense = 10
monster1_health = 100

Good Case:
    
class Monster:
    def __init__(self, attack, defense, health):
        self.attack = attack
        self.defense = defense
        self.health = health

这是一个游戏中怪物属性的设计，当我们要对零散的变量进行操作时不如思考如何让他们聚合在一个有意义的语境里。

函数

例1 只做一件事

一个函数只应该做一件事。想象一下你正在准备一个晚餐，你需要做的事情有很多，包括准备材料，烹饪，设定餐桌，清洁和洗碗。如果你是一个函数，试图一次性做所有这些事情，那就可能会导致混乱和低效。

相反，如果你将每一个任务都视为一个独立的“函数”，把这些抽象层级抽离出来，就能更好地处理。比如，你可能会有以下的函数：

1. `准备食材()`
2. `烹饪()`
3. `设定餐桌()`
4. `吃饭()`
5. `清理餐桌()`
6. `洗碗()`

在这个例子中，每个函数都只负责一个任务，职责清晰。如果其中的某个步骤出现问题，比如烹饪过程中煮糊了饭，你就只需要修改“烹饪”这个函数，而不用改动其他部分。这使得问题的定位和修复变得更简单，也能提高整体的效率和生产力。

例2 函数参数

函数参数应该越少越好，参数多的函数不仅阅读困难，在写单元测试时也常常制造麻烦。一元参数应该尽量使用返回值，如果函数要对输入参数进行操作，好的做法是用返回值来接收修改结果，而不是直接修改输入参数。如果参数实在太多，应该使用对象来传入。

注释

关于注释，其实只有一条准则，这条准则对第一次听的人来说可能会有点难以理解，那就是尽量不写注释。

想象一下你什么时候会想写注释？这里逻辑太复杂了、这里做法太奇怪了不合常规、这个函数太难懂了等等，简而言之，就是你写的代码有问题，你应该尽量避免这种情况，而不是用注释来偷懒。注释越多的代码越烂。我甚至听过一些极端的技术团队禁止代码里出现注释。

团队 Code Review 的一些经验

我经历过几乎是开源代码级别严苛的 Code Review，每次无论是大是小的任何分支合并都要拉其它人 Code Review，团队严禁对自己发起的 PR 进行合并。每个新人都要读一遍《Clean Code》并进行心得分享，团队有一个共享文档维护沉淀的 Code Review 经验，每个月开一次会对近期 Code Review 产生的疑问进行讨论。可想而知这样会导致每次开发周期都会变得特别长，但是开发团队能争取到这样的话语空间，对技术人本身来说是受益无穷的，终于有机会可以对书本上的最佳实践进行实践了。

也许是受自己的经历影响，我觉得那种事后拉着组员一起 Review 的行为基本没用，业务重压之下，这种形式的 Review 不会持久、不会有效、有问题不会排期修改，再说了，很多问题如果一开始没有暴露出来，写好了再改是非常难的，毕竟：

later equals never

前面说过，代码审美是一个非常主观的东西，没有最好的代码。团队 Review 里，由于这样那样的原因，人与人之间总会有冲突存在，通常来说，我们需要在团队的共识中得到小范围的最优解。

最后

写好代码是一件非常困难的事情，其实上面的一些准则和经验都是些非常简单易解的知识，但是要做到并且完全遵守非常困难，毕竟人最大的痛苦在于无法跨越知道和做到的鸿沟。如果你是团队分工的一部分，那么能不能写出好代码几乎取决于团队制定的守则，如果没有团队给你争取排期、制定 Code Review 规范、成员的代码意识，那么你一定会要花费足够的心力来维护你的代码洁癖，久而久之，难免滑向懒惰的深渊。

代码永远在变化，每次代码的修改，都可能在系统引起熵增，没有最好的代码，只有更好的代码。对好代码的追求应该永远在路上。

什么是 Star？

首先我们先来界定一下 Star 的含义，GitHub 是一个技术社区，正常来说用户在社区的行为都会符合社区的调性，即默认给项目点赞是因为此项目有技术含量，实则不然。 一个项目的 Star 可以有很多含义，除了是为技术点赞，也可以是因为想收藏此项目、此项目帮助到了我、觉得好玩有趣、想要关注此项目的后续更新、被求赞了、刷赞等等。 我还记得多年前有个大V博主拉黑了所有给骂他的评论点赞的人，结果有大量粉丝误伤，后面有些粉丝说，点赞一些不好的言论，是想把这条评论顶上去让出口成脏的人被更多人 看到，被更多人骂。从这个例子可以看出，其实用户点赞的出发点是丰富多样的，也许这就是微博现在长按点赞会弹出一个列表让你选择点赞趋向的理由吧。

技术本质

我们不得不承认的是，很多程序员的世界观很狭隘，喜欢用自己的技术视角去衡量万事万物，殊不知很多事情的本质不是技术，技术只是用来达成目的的手段罢了。

前阵子我在推特看到这样一条推，翻译如下：

左：嘿，约翰，希望你一切都好。我对计算机科学（特别是软件工程）非常热衷，想要在这个领域追求职业生涯。 但我不禁有些担心由于人工智能（ChatGPT4等）的发展，编程工作的未来可用性。我知道很难预测未来10-15年的情况， 但我主要担心自己可能白费力气。我担心人工智能会让我的未来工作过时，甚至在我得到它之前就过时了。你对此有什么想法吗？

右：如果你具备全面的“产品技能”并使用最适合工作的最佳工具，今天可能是手工编码，但未来可能是由人工智能指导，那么你很可能会做得很好。

左：我明白了……你所说的“产品技能”，是指硬技能和软技能吗？

右：软件只是帮助人们完成某些事情的工具——许多程序员从未理解过这一点。把注意力集中在交付的价值上，不要过度关注工具的具体细节。

左：哇，我从来没有从那个角度来看待它。我会牢记这一点。谢谢你的时间，非常感激。

希望你能再品味一下上面这句话：Software is just a tool to help accomplish something for people

真的没有技术含量吗？

换个角度再来看这个问题，其实那些你看起来没有技术含量的项目，它们真的没有技术含量吗？ GitHub 有一位非常活跃的开发者 yihong， 他的很多项目在我看来都不是特别有技术含量，比如他的这个项目 GitHubPoster，就是去各种网站或 APP 逆向数据，生成 一张类似 GitHub 提交记录的图片，这个项目我也轻轻松松地提了一个 PR。

后来我慢慢意识到，我觉得不难是因为我有较为丰富的网站逆向经验，你觉得自然而然的东西，很可能对大部分人来说都是一个较高的门槛。大学我刷知乎的时候看到一个知乎er，他做了一个 可以搜索百度网盘资源的公众号，在公众号里回复内容就可以搜索到相关资源，当时我觉得好厉害好震惊，但当我接触逆向后很久，又回过头来想起这件事，发现这个东西其实就是一个简单的爬虫， 后端调一下已有的数据接口就完事了。

其实这种信息偏差，或者说信息优势，在你观察一个你不熟悉的领域时是经常会有的，所以有没有技术含量其实是一个相对的概念、主观的判断。