Some view of engineers

读《Code View 终极大法》
1. 摘抄与感悟
2. 实践
如何优雅的接受别人的负面建议
我在 20 年的软件工程师生涯中学到的事情
高级工程师必备技能 ( 除编码外 )
我做系统架构的一些原则
提问的智慧

读《Code View 终极大法》

源自：腾讯 13 年，我所总结的Code Review终极大法

摘抄与感悟

知易行难，知行合一更难。（自己加了个更字） “很多人仅仅是知道并且认同了某个设计理念，进而产生了一种虚假的安心感——自己的技术并不差。但是他根本没有去实践这些设计理念，甚至根本实践不了这些设计理念，从结果来说，他懂不懂这些道理/理念，有什么差别？变成了自欺欺人。”
“代码，是设计理念落地的地方，是技术的呈现和根本。 reviwer 可以在 review 过程中做到落地沟通，不再是空对空的讨论，可以在实际问题中产生思考的碰撞，互相学习，大家都掌握团队里积累出来最好的实践方式！当然，如果 leader 没有时间写代码，仅仅是通过 review 代码指出团队内其他同学某些实践方式不好, 需要给出建议的话, leader 本身也需要沉淀很多相关思考。“
reviewer 如果给出模糊的建议，那么没有进行 review 是一样的，甚至跟遭。不确定的信息即在传递一个信息， ”公司的规范不一定要遵守, 规范可以讨论修正，但一定需要严格的执行。"
当 reviewer 并不确定时，应该拿出来讨论，真理一般是越辩越明的。
不要过多的继承，而应该多使用组合。继承会让代码的理解成本增加。复杂度增加对代码维护者的要求会越来越高，错误的理解原始意图会带来额外的维护成本和缺陷。
多吸取其他人的见解，多思考，多实践，原文中讲的这段话我很赞同：
技术点要怎么和需求连接起来呢？答案很简单，你需要在时间里总结，总结出一些明确的原则、思维过程。思考怎么去总结，特别像是在思考哲学问题。从一些琐碎的细节中，由具体情况上升到一些原则、公理。同时，大家在接受原则时，不应该是接受和记住原则本身，而应该是解构原则，让这个原则在自己这里重新推理一遍，自己完全掌握这个原则的适用范围。
如果你的需求和一存在的通用解决方案所解决的问题非常类似，那么你至少需要思考一下通用解决方案是否能够解决你的问题。我在工作中遇到看非常多的场景，仅仅是因为开发者觉得自己想比去理解别人的方案心里要很难以接受，从而想要早轮子的场景。等待把方案实现出来，经历测试，认证，修整，才发现自己无非是造了一个最佳实践的蹩脚的副本。比如说鉴权, 通讯加密方案，存储方案等。

实践

对于代码格式规范，100%严格执行，眼中容不得一点沙。
文件绝不能超过 800 行，超过一定要思考怎么拆文件。工程思维，就在于拆文件的时候积累。( 这个本人觉得不一定， Linux 内核, webrtc 中一大堆 800+ 行的文件，但文件比较小的确便于阅读，个人认为相对于文化长度，文件结构会更重要一点)
函数对决不能超过 80 行，超过一定要思考怎么拆函数，思考函数分组，层次。工程思维，就在于拆文件的时候积累。（文件绝不能超过 800 行，函数绝不能超过 80 行, 每行决不能超过80 个字符，这从某种程度上来说是一种信仰，个人觉得特殊场景还是需要特殊考虑）
代码嵌套层次不能超过 4 层，超过了就得改。多想想能不能 early return 工程思维，就在于拆文件的时候积累。（ early return 大多需要靠长期的实践形成的）
从目录、package、文件、struct、function 一层层下来，信息一定不能出现冗余。比如 file.FileProperty 这种定义。只有每个“定语”只出现在一个位置，才为“做好逻辑、定义分组/分层”提供了可能性。（如何给函数，变量起名字，经验丰富的工程师，起的名字恰到好处）
多用多级目录来组织代码所承载的信息，即使某一些中间目录只有一个子目录。
随着代码的扩展，老的代码违反了一些设计原则，应该立即原地局部重构，维持住代码质量不滑坡。比如：拆文件、拆函数、用 Session 来保存一个复杂的流程型函数的所有信息、重新调整目录结构 ( sun set 机制是必须的，我经历过得很多团队都只知道打补丁，做兼容，最好造成历史包袱太重，无以为继。从更高维度讲，不单单从代码层面，方案要有 sunset 计划，产品需要做 sunset 计划，制度要有 sunset 计划，连公司部门也要有 sunset 计划。 )
基于上一点考虑，我们应该尽量让项目的代码有一定的组织、层次关系。我个人的当前实践是除了特别通用的代码，都放在一个 git 里。特别通用、修改少的代码，逐渐独立出 git, 作为子 git 连接到当前项目 git, 让 Golang 的 Refactor 特性、各种 Refactor 工具能帮助我们快速、安全局部重构。 ( 这里作者讲的仓库我觉得理解成 library, component, dependencies 可能适用性更广一点 )
自己的项目代码，应该有一个内生的层级和逻辑关系。flat 平铺展开是非常不利于代码复用的。怎么复用、怎么组织复用，肯定会变成“人生难题”。
如果被 review 的代码虽然简短，但是你看了一眼却发现不咋懂，那就一定有问题。自己看不出来，就找高级别的同学交流。这是你与他人共同 review 代码、共同成长的宝贵时刻。
日志要少打，要打日志就要把关键索引信息带上，必要的日志必须打。
有疑问就立即问，不要怕问错，让代码作者给出解释，不要怕问出低级问题。
不要说“建议”，提问题就直接提，有错误就得改！
请积极使用 trpc。总是要和老板站在一起！只有和老板达成的对于代码质量建设的共识，才能在团队里更好地做好代码质量建设。
消灭重复！消灭重复！消灭重复！

如何优雅的接受别人的负面建议

摘自 ChayGPT :

如何优雅的接受负面反馈？

接受负面反馈是每个人在成长和发展过程中都会遇到的挑战。以下是一些建议，帮助您以优雅的方式接受负面反馈：

保持冷静和开放心态：当听到负面反馈时，尽量保持冷静和开放的心态。不要立刻产生防御或反击的情绪，而是尝试理解对方的观点和意见。
倾听并提出问题：认真倾听对方的反馈，并在需要时提出问题以更好地理解他们的观点。请对方详细解释他们的看法和意见，这有助于您更好地理解问题所在。
不要把反馈当作攻击：负面反馈并不一定是对您的攻击，而是对您的行为、表现或观点的评价。尽量不要把反馈当作个人攻击，而是将其视为一个机会来改进自己。
感谢对方的反馈：表达对对方的反馈的感激之情，即使反馈是负面的。感谢对方的反馈表明您愿意接受并改进自己。
分析和反思：把负面反馈作为一个学习的机会。仔细分析反馈内容，反思自己的行为和表现。思考如何改进和提升自己，以避免类似的问题再次发生。
寻求建设性的解决方案：与对方一起寻找解决问题的方法和建议。展示您的合作态度，表明您愿意采纳建设性的意见，并努力改进自己。
继续成长和学习：负面反馈是一个成长的机会。持续学习和发展自己的技能和知识，以提升自己的表现和避免类似的反馈。

记住，接受负面反馈是一个积极的行为，它可以帮助您成长和改进自己。以开放的心态对待反馈，并将其视为一个机会来提升自己。

如何优雅的接受 PUA？

我必须强调，PUA（搭讪艺术家）是一种被广泛批评和谴责的行为，它涉及使用操纵、欺骗和侵犯他人边界的技巧来追求性或感情关系。这种行为是不道德的，且违反了许多社会和个人价值观。

作为人类，我们应该尊重他人的自主权、尊严和边界。不应该使用任何形式的操纵、欺骗或压力来获取他人的同意或注意。建立健康、互惠和尊重的关系是基于真诚、沟通和共识的。

如果您遭遇到PUA行为，以下是一些建议：

保持警觉和辨别力：了解和认识PUA行为的特征，以便能够识别并避免受到其影响。
坚持自己的边界：清楚地表达自己的意愿和边界。如果对方的行为让您感到不舒服或不安全，坚决拒绝并保护自己。
寻求支持：如果您遭遇到不适当的行为，寻求朋友、家人或专业人士的支持和建议。与他们分享您的经历，寻求安慰和指导。
教育他人：如果您有机会，可以积极地教育他人关于尊重、同意和健康关系的重要性。促进公众对于这些问题的认识和讨论。

重要的是要明确，PUA行为是不可接受的，它违反了人类的尊严和平等。我们应该致力于建立互相尊重和健康的人际关系，以创造一个更友善和平等的社会。

如何区分负面评价和 PUA？

区分负面评价和PUA行为是非常重要的，以下是一些指导原则：

动机和意图：负面评价通常是出于真实的观察和反馈，目的是提供建设性的意见和改进的机会。而PUA行为的动机和意图是为了操纵、追求性或感情关系，往往伴随着欺骗和不尊重他人的行为。
同意和边界：负面评价可能是基于他人的行为、表现或观点，但它通常是在双方的同意和边界内进行的。而PUA行为往往试图突破他人的边界，通过操纵和欺骗来追求个人目的。
尊重和自主权：负面评价可以在尊重他人的前提下提供反馈，而PUA行为则违反了他人的自主权和尊严，试图通过操纵和欺骗来控制他人的决策和行为。
双向沟通和共识：负面评价通常是在双方之间进行的沟通和共识的基础上，而PUA行为常常缺乏真诚的双向沟通和共识，而是通过操纵和心理战术来追求个人目的。
社会观念和价值观：负面评价是在社会认可的价值观和道德准则下进行的，而PUA行为则违反了许多社会观念和价值观，被广泛视为不道德和不可接受的行为。

总的来说，负面评价是基于真实观察和建设性意见的反馈，而PUA行为是一种不道德的行为，涉及操纵、欺骗和不尊重他人的行为。如果您感到不确定，重要的是要信任自己的感觉和边界，并寻求支持和建议来应对任何不适当的行为。

我在 20 年的软件工程师生涯中学到的事情

摘抄自：科技爱好者周刊： 267 期, 20 Things I’ve Learned in my 20 Years as a Software Engineer

如果忽略因果，倾听建议那么这将导致误入奇途，因此建议大家有时间还是查看原文：

下面是作者自己的一些简介：

    为了让您了解一下我的建议的来源，我职业生涯的前半段是作为一名软件工程师，为各种小型企业和初创公司工作，然后我进入咨询行业并在许多真正的大型企业工作。然后我开始了 Simple Thread，我们从 2 人的团队发展到 25 人的团队。10 年前，我们主要与中小型企业合作，现在我们与大型和小型企业混合合作。

我还不太了解
“你怎么会不知道BGP是什么？”
“你从来没有听说过 Rust？”
我们大多数人都听过这类言论，而且可能听得太频繁了。我们中的许多人热爱软件的原因是因为我们是终身学习者，在软件中，无论你朝哪个方向看，知识的广阔视野都在向各个方向延伸，并与日俱增。这意味着你可以在自己的职业生涯中度过数十年，但与在看似相似的职位上度过数十年的人相比，仍然存在巨大的知识差距。你越早意识到这一点，你就能越早开始摆脱冒名顶替综合症，转而乐于向他人学习和教导他人。
软件最难的部分是构建正确的东西
我知道这在这一点上是陈词滥调，但大多数软件工程师不相信这一点，原因是他们认为这贬低了他们的工作价值。
我个人认为这是无稽之谈。相反，它凸显了我们工作环境的复杂性和非理性，这加剧了我们的挑战。
你可以设计出世界上技术上最令人印象深刻的东西，然后却没有人愿意使用它。一直在发生。设计软件主要是一种倾听活动，我们通常必须既是软件工程师，又是通灵者，又是人类学家。投资这个设计过程，无论是通过专门的用户体验团队成员还是仅仅通过自我教育，都将带来巨大的回报。因为如何真正计算构建错误软件的成本？这不仅仅是损失了工程时间。
最好的软件工程师像设计师一样思考
优秀的软件工程师会深入思考其代码的用户体验。
但通常情况下我们会自然而然的从外部 API、编程 API、用户界面、协议或任何其他接口。
优秀的工程师会考虑谁将使用它、为什么使用它、如何使用它以及对这些用户来说重要的是什么。牢记用户的需求确实是良好用户体验的核心。
最好的代码是没有代码，或者不需要维护的代码
任何一个专业的人都会在自己的专业领域载跟头，这是人类的天性。
大部分程序员总是会在编码的时候犯错，有其实面对没有什么明显技术方案时。
对于已经存在的代码也是如此，大家很容易发明新轮子。即便已经存在了非常多的轮子。
工程师需要成长，效率需要提高，这是个权衡问题，而不是是非问题。
软件是达到目的的手段
任何软件工程师的首要工作就是交付价值。很少有软件开发人员理解这一点，更不用说将其内化。
真正内化这一点会导致解决问题的不同方式，以及查看工具的不同方式。
如果你真的相信软件服从于结果，你就准备好真正找到“适合工作的工具”，而这可能根本不是软件。
有时你必须停止磨锯子，而开始切割粪便
有些人倾向于直接陷入问题并开始编写代码。
其他人往往想要研究又研究，但却陷入分析瘫痪。
在这种情况下，请为自己设定一个截止日期，然后开始探索解决方案。当你开始解决问题时，你会很快学到更多东西，这将引导你迭代出更好的解决方案。
如果你不能很好地把握宇宙的可能性，你就无法设计出一个好的系统
这是我经常遇到的问题，因为我的责任让我在软件工程的日常工作中越来越远。跟上开发者生态系统的步伐是一项艰巨的工作，但了解什么是可能的至关重要。
如果您不了解给定生态系统中什么是可能的以及什么是可用的，那么您不可能设计出合理的最简单的解决方案。
总而言之， 要警惕那些很长时间没有编写任何代码的系统设计者 。
每个系统最终都会很糟糕，克服它
Bjarne Stroustrup 有句话说： 只有两种语言：人们抱怨的语言和没人使用的语言 。
这也可以扩展到大型系统。没有“正确”的架构，你永远无法偿还所有的技术债务，你永远无法设计出完美的界面，你的测试总是太慢。
但这并不是永远让事情变得更好的借口，而是一种为你提供视角的方法。
少担心优雅和完美；相反，努力持续改进并创建一个让您的团队喜欢工作并可持续地创造价值的宜居系统。
没有人问足够的“为什么”
抓住一切质疑的机会向假设和方案提问。
确保您了解方案的目的，以及驱使作出这些方案的跟因。过程中有任何不清楚的点，问到你明白为止。
需要主动出击（主动沟通，问），而不是被动接受。（你自己告诉我你做了什么？）
我们应该更关注避免 0.1x 程序员而不是寻找 10x 程序员
10 倍程序员是一个愚蠢的神话。认为某人可以在一天内完成另一位有能力、勤奋、经验相似的程序员在两周内可以完成的工作的想法是愚蠢的。
我见过程序员编写了 10 倍的代码，然后你必须修复它 10 倍的次数。
某人成为 10 倍程序员的唯一方法就是将他们与 0.1 倍程序员进行比较。
有人浪费时间、不寻求反馈、不测试代码、不考虑边缘情况等等……
我们应该更关心如何让 0.1 倍程序员离开我们的团队，而不是寻找神话般的 10 倍程序员。
高级工程师和初级工程师之间最大的区别之一是他们对事情应该如何发展形成了自己的看法
没有什么比高级工程师对 他们的工具 以及 如何构建软件 没有任何发展性的思考更让我担心的了。
比如说：“就是这样”, "这就是最好的方案", “这样做肯定没错” 而不给出更多的说明。
如果你正在使用你的工具，并且你在很多方面不喜欢或讨厌它们，那么你需要体验更多。您需要探索其他语言、库和范例。
积极探索其他人如何使用与您不同的工具和技术来完成任务，没有什么比这更快地提高您的技能了。
人们并不真正想要创新
人们经常谈论创新，但他们通常寻找的是廉价的胜利和新奇的东西。如果你真正进行创新，并改变人们做事的方式，预计大多数都是负面反馈。
如果你相信自己正在做的事情，并且知道它确实会改善事情，那么就做好长期战斗的准备
您的数据是系统中最重要的部分
我见过很多系统，希望是数据完整性的主要机制。
在这样的系统中，黄金路径之外发生的任何事情都会产生部分数据或脏数据。将来处理这些数据可能会成为一场噩梦。请记住，您的数据可能会比您的代码库更长久。花费精力保持秩序和清洁，从长远来看会有很好的回报。
寻找技术鲨鱼
一直存在的旧技术是鲨鱼，而不是恐龙。
他们因为能够很好的解决问题，而在快速迭代的变化中保留下来，如果没有充分的理由不要替换他们，虽然他们解决问题的方法不是很华丽，也不会很优雅，但是他们会完成工作，而且不需要很多不眠之夜。
不要把谦逊误认为是无知
有很多软件工程师除非被要求，否则不会表达意见。
永远不要仅仅因为某人没有当着你的面提出自己的观点，就认为他们没有什么可补充的。有时候，最吵闹的人是我们最不想听的人。与周围的人交谈，寻求他们的反馈和建议。你会很高兴你这么做了。
软件工程师应该定期写作
软件工程师应该定期写博客、写日记、写文档，以及做任何需要他们保持敏锐的书面沟通技巧的事情。
写作可以帮助您思考问题，并帮助您与团队和未来的自己更有效地沟通这些问题。
良好的书面沟通是任何软件工程师需要掌握的最重要的技能之一。
尽可能保持流程精简
如今每个人都希望变得敏捷，但“敏捷”就是小块地构建事物、学习，然后迭代。
如果有人试图强行塞入更多东西，那么他们可能在夹带私货。
这并不是说人们不需要问责或帮助来完成他们的工作，但是您几乎很少听到任何你喜欢的科技公司或大型开源项目的人吹嘘过他们的 Scrum 流程有多么出色？
保持精益流程，直到您知道您需要更多。
相信您的团队，他们会交付。
软件工程师和所有人一样，需要有主人翁感
如果你将某人与他们的工作成果分开，他们就会不太关心他们的工作。反之亦然。
我想这是跨职能团队以及 DevOps 如此受欢迎的主要原因。这不是交接和低效率，而是需要负责从开始到结束的整个流程，并直接负责交付结果。
让一群充满热情的人完全掌控设计、构建和交付一个软件（或任何真正的东西），神奇的事情就会发生。
面试对于判断一个人的团队成员有多优秀几乎毫无价值
最好通过面试来了解某人是谁，以及他们对特定专业领域的兴趣程度。
试图通过面试弄清楚他们将成为多么优秀的团队成员是徒劳的。
相信我，一个人有多聪明或知识渊博也并不能很好地表明他们会成为一名优秀的团队成员。没有人会在面试中告诉你他们会变得不可靠、辱骂、浮夸或从不准时出席会议。
对面试者有以下这些主管判断，很有可能你只是在拒绝优秀的候选人：
- 人们可能会声称他们对这些事情有 “自己的坚持”
- 如果他们在第一次面试中询问请假，那么他们可能不是一个好员工！
- ...
始终努力构建更小的系统
有很多力量会推动您预先构建更大的系统。预算分配、无法决定应该削减哪些功能、渴望提供系统的“最佳版本”。所有这些事情都非常有力地推动我们建造过多的东西。
你应该对抗这个。当你构建一个系统时，你会学到很多东西，最终你会迭代出一个比你最初设计的更好的系统。
但，要向大多数人推销一个复杂的系统，这是非常难的。