莫得感情的摘录工具
搭建软件:
- 过早优化乃万恶之源，请勿低估这句话。
- 你几乎不需要从零开始构建项目。有很多库和依赖帮你做好了这些事情，所以请管住你造轮子的双手。
- 先定位问题后寻求解决方案。现实中忽略第一步直接跳到解决方案上的案例可不少见。
- 勿求完美。首当其冲的是使程序能运行，而后是要精简。软件发布享有最高优先权。
- 糟糕的程序员念念不忘他的代码。优秀的程序员挂念的要是数据结构，以及人际关系。- Linus Torvalds
- 代码注释是用来解释「你为什么要这样做」的，而不是「你正在做什么」。不要在你的注释里长篇大论。
- 有具体含义的错误日志，可以节省大量调试问题的时间。在错误信息里提供所有相关的信息，而不要敷衍一下「Error occurred in Function X!」。还有，不要在日志里打印任何敏感和隐私信息。
- 100% 行 / 分支 （测试）覆盖率并不意味着你的代码没有 bug 了。为功能需求去写测试用例，而不要为了「行或分支」。
- 当你在修复一个 bug，就事先编写对应的测试用例，这样的话将来这个 bug 将不再出现。Bugs 爆发通常源于错误的假设，为这些错误的假设编写测试用例，可以使应用变得更加健壮。
- 当有人阅读你的代码是，他们脑袋里只能同时去理解不超过 7 个事物。没错，我们人类的大脑的短期记忆里，一次只能处理 不超过 7 件事情。也难怪有些代码 linter 工具规定了代码参数不能超过 7 个。
- 不要有人要你做什么你就去做什么，要你怎么做你就怎么做，要明白为什么，如果你没被说服，那就挑战现状。
- 解决问题是每一位程序员要具备的最重要的技能，没有之一。你的项目里有许许多多的问题，不是所有的问题都能够被解决，甚至能达到 20% 的比例。记住，「保剑锋从磨砺出」。
职业规划:
- 可以效力于你不喜欢的事业，但绝不要做你讨厌的事。
- 当你在职业生涯早期，优先考虑学习和机会，而不是薪酬、福利等。在学习率产出高的活动或工作中投入更多的时间。学习复利，你必须早点开始，才能收获它的好处。
- 你在工作中的纯粹动机应该是为团队和项目增加价值，而不是为了给任何人留下更高的薪酬或晋升的印象。如果处理好前者，后者水到渠成。
- 花点时间在简历上，并随时更新。建议有一个描述和记录你的项目和经历的投入的个人网站。
- 你解决的问题越模糊，你的角色越高。适应不确定性和模糊性。
- 每半年自省一下这几个问题: 要是你的回答都是否定的，那么务必考虑跳槽或者换团队。如果你呆在公司超过 2～3 年了，然后你的回答都是确定的，那么你还是应该考虑跳槽或者至少要面对它。你不寻找，就绝不会知道你缺失什么。
- 我有学到新的知识，拓宽了专业领域了吗?
- 在组织中我创造了影响力吗?
- 以我的技能和经验，我的工资水平够吗?
- 细心观察的话，你会发现编程和写作很相似。编程语言就类似人类的语言，编程就要像在写作或者写诗。每个人都可以成为作家，但是需要花不少时间去成为一名好的作家。
- 定期和你的上级进行一对一的交流和反馈。不要等到年度评审时得到突然惊喜或惊吓。
- 如果你的上级没有对你的失误负责，甚者不去责怪你，那么在他手下做事情可能有一些风险可得小心了。
- 多年的工作经验只是个数字。有时你会发现年轻程序员的技术要比老程序员强。别误会我的意思，经验交给你的不仅仅是技术，是的，工作经验很重要，但这不是唯一的因素。
设计系统:
- 最好的系统设计往往就是最简单的那个。Keep it simple, stupid! (KISS 原则)
- 「设计模式」和「最佳实践」并不能包治百病。一名优秀的工程师熟知最佳实践，而一名经验老道的工程师知道何时打破最佳实践。
- 理解抽象概念。代码中引入了不必要的复杂性，通常是由于缺乏抽象概念。
- 一个系统的健壮程度，取决其最薄弱的点。要时刻关注其瓶颈。
- 偏离初期设计原则越远，离整体失控就越近。尽量减少跳跃式更新，这在技术与非技术领域同样适用。
- 不存在完美无暇的解决方案，只有折中。 列出优点和缺点，同时参考你的要求，以便做出正确的权衡。
- 往项目里引入任何技术，风险便随之而来。要有计划地衡量风险并且降低风险。「没有救生衣就别往海里跳」。
- 避免提前抽象，解决你遇到的现有的问题，仅此而已。只有在你再次遇到相似的问题，并且你看到有一种模式可以解救时，这时候你就该考虑围绕它构建抽象
- “构建软件设计有两种方式：一种方式是简单到没有明显缺陷，另一种方式是复杂到没有明显缺陷。 第一种方法要困难得多。 简单很难。” - 托尼·霍尔。
- 不要太偏向于语言或框架，如果你喜欢某种语言，就不要一直崇拜它，不要开始到处使用它。 如果你讨厌它，也不要一直抱怨它。 每种语言或框架都是为特定用例设计的。 作为工程师，您的工作是为用例选择正确的工具。
- 如果在耗费时间弄清楚某些东西是如何工作的时候，你却忘记了为什么会运行的部分，那么代码中想必还有很多不必要的抽象和复杂性需要被清理。
- 复杂性一旦积累了下来，就很难消灭掉。不要把修改代码时引入的那一丁点复杂习性不当回事儿。如若每位开发人员都这么想，那么复杂性必将指数型增长。
- 如果你决定去重写组件或服务，请三思而后行。往往阅读代码比写代码更难，这也难怪软件开发中经常会听到「我要重写它」。
- 挑战你的前辈提出来的设计建议，你会发现，有时候你的设计更优。采用有理有据的论点加以客观比较。只要不是做一个刚愎自用把事情推向极端的蠢蛋。
- 大多数情况下，静态类型语言比动态类型语言更好，即使静态类型系统会带来更高的开销。这也就是为什么 TypeScript 是 最受喜爱的语言 之一。
安全意识:
- 每个开发人员都应该知道如何编写安全代码。用糟糕的设计/抽象编写代码是可以的，但用安全漏洞编写代码绝对不行。
- 在快速格式化或验证某些 JSON/XML/YAML 数据时，不要使用在线格式化程序或验证程序。特别是当你处理一些机密的生产数据时，对任何在线工具都是严格禁止的。请改用任何本地编辑器或命令行工具。不要冒险将公司数据泄露到某个随机站点。(推荐工具: CyberChef )
- 永远不要在代码存储库中推送任何敏感信息。在提交和推送之前，请始终仔细检查您的代码没有电子邮件地址、电话号码、密码、身份验证令牌、私钥等。
- 始终验证和清理用户输入。永远不要假设或期望用户以正确的格式发送某些输入。在验证时，总是更喜欢白名单而不是黑名单。
Pull Requests:
- 猜猜看！你也可以在 pull request 评论中给予赞扬。我们在代码审查的时候总是乐于把重点放在不好的地方，一点小小的感激之情可以让你的同伴脸上露出微笑。下次试试吧。
- 每天都要阅读 pull request 并理解其他开发人员的评论，以便从不同的角度了解特性和编码标准。
- 代码格式化和其他标准应该是自动化的。使用代码格式化程序和 linter 构建项目开发流水线，以便整个代码库保持一致和整洁。请停止在评论中关于 tab 和 空格缩进的争论！
- 创建短的 pull request。如果您正在处理多个功能，请将它们分隔为多个PRs。并给评审员足够的时间进行评审，不要在部署前一小时创建PR。🙄
- Git commit 信息应到描述到位，这要的花你就可以轻松的从成百上千次提交中找到具体的记录。请停止写这样的 message： “修复了一个 bug”, “性能优化”, “模块 X 的修改” 等。
学习能力:
- 作为一名程序员，你应该从根本上享受学习和探索的乐趣。如果你不喜欢他们，你应该认真考虑其他职业选择。
- 你不需要学习市场上的每一项技术。随时了解最新趋势，但在需要时学习并使用它们。
- 从刚出来的实习生身上有很多可以学习的。不要单单向高级角色的人身上学习，从而局限自己的眼界。
- 阅读你正在使用的开源项目的源代码，这可以使你理解得更充分，并且学到整洁代码实践和代码组织。
- 学习一些技术的最佳方式就是自己动手，造一个高度简化的版本。 (github.com/danistefano…) 这里不是指造轮子。
- 几天内可以请轻轻松松学习一门语言。但是需要不少年月去理解它的生态系统。
- 探索不同的语言以理解不同的范式。了解不同的编程范例可以帮助你为正要做的用例选择正确的语言。
- 学习 git。除了 git pull 和 git conmmit 这些，还要理解所有更高级的概念。无论你使用什么技术栈，git 都要视为必会。
- 鉴于大多数开发人员的工作都集中在web/网络编程上。了解网络系统中的底层协议很有帮助：HTTP、HTTPS、SSL/TLS、DNS、SMTP、IPv4、IPv6等。
- 拥有良好的 CSS 专业知识将使你看起来像一个向导！🧙♂️ 如果你是一个全栈的web 开发人员，花几天时间掌握CSS可以节省“我不知道我在做什么”的时间。
- 与健壮的系统架构相比，抓人眼球的 UI 设计很容易给人留下深刻印象（显然不是指领域专家）。因此，当你在进行概念验证时，拥有良好的设计技能是很有用的。（只是不要滥用它，用 HTML 硬编码所有内容😛)
生产效率:
- 创建细粒度子任务以跟踪进度，尤其是在处理大型任务时。检查某件事是否完成的幸福感是难以言表的，这反过来也会激励你保持正轨。
- 不要试图同时处理多个任务。专注于一项任务，尽量减少上下文切换。上下文切换的成本比您预期的要高。
- 改进和自定义您的工作流（IDE、调试工具、生产力工具、CI/CD），以便更快地迭代。迭代越快，失败越快。失败得越快，学习得越快。
- 花点时间，把日常工作自动化。如果你做了两次以上的事情，就写一个工具，第三次后就自动完成。另外，也不要浪费数小时/数天的时间来自动化一项只需几分钟的简单任务。找到正确的平衡点！
- 通过设定规则，组织工作邮件（个人邮件也是如此），这些小举措可以有助于在需要的时候快速找到重要文档或者重要交流。
- 即便 vi 编辑器不是你的默认编辑器，这里也建议针对性的学习一下基础的 vi 键位。绝大多数的文本编辑器中都支持绑定 VI 的键位设置。
- 在 IT 产业中，文档技能被严重低估了。学会如何写设计文档，如何修改计划书等。开始使用笔记工具去组织记录任何事情。个人目标，专业目标，随想，读书笔记，还有各种清单等等。 (推荐工具: Notion)
- 任务时间评估时，总是给自己留一定缓冲时间。你永远不知道在一个未经探索的山洞里会遇到什么怪物。
- 有科学证明，适当的听些乐器音乐，低保证音乐或者安静的声音，比听带歌词的音乐效率更高。
自我管理:
- 端正坐姿 立刻马上!
- 有多项业余爱好总归是好的。作为程序员你大可不必把心思
24 * 7小时都花在代码上。 - 善待他人！保持平静! 尤为重要的是, 谦逊!
- 牢记作息时间要规律。切勿燃烧自己。
- 多花点心思在好的工作站设备上。想象你大部分时间都在办公桌上（尤其上在那漫长的上班日）。花点钱在高质量的产品上还是值得的。
- 了解不同的认知偏差 ，这有助于提高个人和技能的决策能力。
- 投资要趁早。了解一下复利的威力，相信你会大为惊叹的。同时，不要过度储蓄，当你不享受当下的时候，储蓄一切又有什么意义呢。就这样，没有更多的财务建议。 🙊
人际交往:
- 人际交往技能与你的技能一样重要。培训指导，公开演讲，带项目等等。开发人员不要因循守旧而成为社交木头的代名词。
- 人类的悲喜并不相通。别寄希望别人会对你感兴趣的任何事物一样的感兴趣。不同的人对不同的动机有不同的反应。
- 不要拿同事（其实是所有的人）不知道的事情，去评判他。
- 学会自我营销。你可能在很多方面都很熟练，但是如果你没有在正确的平台上展示这些技能，没有人会欣赏你。
- 乐于助人会使你强大。传授与分享你所学的知识。传授或者写下你学习到的知识的这个过程，可以有助于你加深对知识的理解。
- 知之为知之，不知为不知。 说谎会招致更多更空虚的期望。
- 在你的团队中，始终会有那么些 🦅 炸天开发人员，他几乎可以解决任何问题。不要错愕他的技能，而是阅读他们的 pull request，进行技术聊天，并定期从他们那里获得反馈以提高自己。见贤思齐。
- 在工作之中能结识你最要要的朋友，那就太好了。不要克制自己向你的同事们敞开心扉 (这条建议你自己酌情决定 😅)
沟通:
- 聆听，再聆听！
- 在会议上没有任何要说的，也是没关系的。但绝不要东拉西扯地浪费大家的时间。
- 不要在 IM 软件上仅仅跟别人说句 Hi / Hello / 早上好！, 就干等着别人回复你。请直接说出你要找他的原因，谁会愿意听你的问候和日常祝福语的。
- 尽量使用图表去解释你的设计。一图胜千言，还方便记录。推荐：draw.io 和 excalidraw
- 在向他人解释设计或者概念的时候，减少使用黑话和行业术语。不是每个人都熟悉技术领域的，要视场景进行适当衡量。
- 你不应该羞于问一个你认为琐碎或愚蠢的问题。
- 如果你想事情分分钟内就搞定，就 call 他电话。如果你想事情在一个小时内搞定，那就在聊天软件上 ding 他。如果你打算一辈子把事情撩在那，那就给他写邮件吧。（2021 年了还有人在用邮件找人办事吗 🐶）。
- 向别人请教问题时，不要总是说「hi，X 出问题了，你帮我看一下吧？」而是应该说 「hi， 我运行 X 的时候，遇到了报 Y 错误，然后我查资料试了 Z 方案，但好像还是不行，你能帮我看一下吗？」。找人问问题前，自己要查资料，讲真的，请不要因为你的代码错误而去浪费他人的时间。
- 不要成为自行车棚效应的牺牲品。 在会议或讨论中，请重视复杂/关键项而不是琐碎项。
各种小建议:
- 为易读性而优化代码，通常一段 20 行略显「啰嗦」的代码，总是优于「精简」得只剩 1 行的代码的。
- 新手程序员通常会在编写代码时候倾注情感。但在敏捷开发环境中，需求和代码需要不断的变化，所以修改和删除刘代码时放轻松些。
- 对任何问题要做几手解决方案。这种尝试寻求不同方案能迫使你从不同角度思考，并且当你有了不同的解决方案，你就可以通过正确的权衡来做出正确的决定。
- 你工作接触的模块越多，你从中学习到的领域知识就会越丰富。领域知识越丰富，你就要参加更多会议。参加的会议越多，你要写的代码就会越少。通过记录和分享这些领域知识，这样你就不再是唯一的连接点。我知道这说起来容易做起来难。
- 当你被一个问题阻塞了，长期没有没有任何进展，就讲问题复述或者解释给某人听，总是会有奇效的。你想想为什么 小黄鸭调试法 如此受欢迎。
- 您不需要了解整个代码库就可以开始使用它。了解体系结构和生命周期，并开始学习您的模块。不要浪费时间去理解个 class 里的内容。
- 代码是一种负债而不是资产。您拥有的代码越多，就越需要阅读、理解、测试和维护。最好的代码是没有代码。
- 要学会如何在 StackOverflow 上提问。你很少需要提问，但当你正在使用的库或者框架文档和用户生态有限时，这就是一项非常有用的技能。
- 如果你在其他模块碰巧发现一个问题或者 bug，而这些不是你写的，请通知相应的开发人员，在工作流中提醒他这些问题。而不是像这样说：这个模块不是我负责的。
- 你负责写的函数理应是零/最小副作用的。这可以使得函数轻易地独立的测试。
- 看在上帝的份上，请不要编写自己的日期格式化/解析函数。每种编程语言都有许多流行的数据库，只要使用它们就可以了。日期和时区比你想象的要复杂得多。
还说点啥：
- 谨记帕累托法则 (二八法则)。软件工程中它的身影几乎无所不在：
- 80% 的工作是有 20% 的工程师完成的
- 80% 的说活来自于 20% 的工作
- 80% 的 bug 来自于 20% 的代码
- 80% 的地性能是由 20% 的代码导致的
- 感谢那些在问答社区和技术论坛上贡献答案和经验的人，他们的存在解决了我 95% 以上的问题（可能不包含私人问题）
部分内容摘自：
