作为软件工程师应该知道的100件事，收藏备用

软件工程师是一个神圣、严谨的工作，如果能有一套适合自己的良好习惯，不管是在工作、生活上对我们自己只有好处，绝无坏处。

不好的习惯我们要抛弃，而好习惯我们需要慢慢养成。

在下面搜集的100件好习惯中，看看你能满足几条，顺便检视一下自身也不错。

内容很多，建议收藏备用！

01. 构建软件 Building Software

(1) 不要对项目进行过早的优化，尤其是项目刚建立之初。而应该在项目稳定时再进行跌代，逐步优化。不要小看这句话。

(2) 在从头开始构建项目时，每个功能与需求现在几乎都有库和依赖项，所以应该把更多的时间用在待解决的需求上，而非重新发明轮子。我们可以借鉴轮子的思想，但没必要重新造。

(3) 在您找到解决方案前需要做的第一步就是：了解问题的范围所在。然而在实际工作中，却很容易跳过第一步而直接进入解决方案这是很常见的事情。

(4) 不要让自己成为完美主义者。首先要让软件正确的工作起来，然后再对它进行优化。记住：软件的交付始终具有最高优先级，如果不能按时交付，谈何优化与完美。

(5) 优秀的程序员担心的是数据结构及其关系，而糟糕的程序员担心的是代码。- 莱纳斯·托瓦兹

(6) 使用代码注释来解释你为什么要做某事，而不是你在做什么，更不要过度描述并像写小说一样。

(7) 拥有有意义的错误日志可以节省大量调试问题的时间。在错误消息中提供所有相关信息，而不是仅仅提示”函数x中发生错误！”，那毫无意义。并且记住永远不要记录任何敏感或个人信息。

(8) 虽然100%行/分支高覆盖率并不意味着您的代码没有错误，但低覆盖率太低肯定是坏事。所有编写测试用例以涵盖所有功能需求，而不是只涵盖行/分支。另外，100%覆盖率可能没有任何意义，因为覆盖率本身并不能告诉开发者有关测试质量的任何信息。

(9) 要习惯编写测试用例，可以很大程度上避免程序以后不会发生意外错误。通常发生这种现象是由于假设错误或不合理，为所有这些错误假设编写测试用例将使应用程序更加健壮。

(10) 当有人阅读你的代码时，他们不应该需要在脑子里保留超过7个东西来理解它。嗯，因为我们的大脑没有能力在短期记忆中一次容纳 超过7个东西 (
https://psycnet.apa.org/doiLanding?doi=
10.1037%2F0033-295X.101.2.343 ) 。这也是为什么许多代码linter对一个函数中超过7个参数提出警告的原因之一。

(11) 不要因为某些人的要求，而去做特定的事情，要明白为什么要这样做。如果你不赞同他的观点，那你应该提出自己的观点并和他讨论研究，可能的话就说服他。

(12) 解决问题是每个工程师应该真正擅长的最重要技能。然而在解决它们的过程中，不是所有的问题都能解决，这个比例甚至超过了20%。但在尝试解决的过程中，你会学到很多东西。

02. 设计系统 Designing Systems

(13) 最好的系统设计通常是最简单的。保持简单，降低你的维护成本。 ( Kiss )
https://en.wikipedia.org/wiki/KISS_principle

(14) 设计模式和最佳实践并不是在任何场景都适合。一个好的工程师知道最佳实践，但一个高级工程师知道什么时候应该打破最佳实践。

(15) 理解并运用好抽象性。在代码中引入不必要的复杂性逻辑，通常是因为抽象性差造成的。

(16) 一个系统只有在其最薄弱的地方才会强大。重点关注瓶颈问题。

(17) 你离开主要源代码的步骤越多，一切都会使维护变得更加糟糕。尽量减少调用嵌套，减少函数跳跃，这在技术和非技术背景下都适用。

(18) 不存在完美的解决方案，只有权衡其中的优点和缺点，以及你的要求，并做出正确的选择。

(19) 你在项目中引入的每一项技术都伴随着附带的风险。衡量风险并制定减轻风险的计划，不要在没有任何应对突发的情况下就去使用它们。

(20) 避免过早的抽象化。解决你现在的问题，而且只解决这个问题。当你看到有类似的问题出现，并且你看到是以一种模式的形态出现，那么这时你就应该考虑把它建立成一个抽象形态，并在以后的工作中加以复用。

(21) 构建软件设计有两种方法：一种方法是使其简单到明显没有缺陷，另一种方法是使其复杂到没有明显缺陷。第一种方法要困难得多。因为简单很难。”-托尼·霍尔。

(22) 不要过于偏向于语言或框架，如果你喜欢某种语言，就不要一直崇拜它，不要开始到处使用它。如果你讨厌它，也不要老是埋怨它。每一种语言或框架都是为一个特定的使用案例而设计的。作为一个工程师，要根据使用情况挑选合适的工具。

(23) 如果当你弄清楚某件事情是如何运作的时候，你已经忘记了其原因，那么代码中就会有很多不必要的抽象和复杂的东西需要清理掉。

(24) 复杂性一旦积累，就很难消除。不要认为你目前所引入的一点点复杂性没有什么大不了的。如果每个开发人员都遵循同样的方法，复杂性就会以指数形式累积。

(25) 如果你决定重写一个组件/服务，一定要重新考虑你的决定。读代码比写代码更难，这就是为什么 “我应该重写它！”在软件开发中非常常见。

(26) 当你的高级工程师或建筑师提出的设计，你有不同看法的时候，不要犹豫，请提出来，有时你的设计会更好。提出有效的令人信服的观点，客观地进行比较。只是不要做一个过于自信的人，把这件事做得太过火了。

(27) 大多数时候，静态类型的语言比动态类型的语言更好，尽管静态类型系统会带来附加开销。而这也解释了为什么TypeScript是 最受欢迎的语言(
https://insights.stackoverflow.com/survey/2021#
technology-most-loved-dreaded-and-wanted ) 之一。

03. 各种小贴示 Miscellaneous Tips

(28) 优化你的代码，以便于理解。一段无聊的冗长的20行代码总比一个巧妙的单行代码要好理解的多，不是吗？

(29) 新手对他们写的代码产生情感联系是很常见的。在需求和代码不断变化的敏捷环境中，修改和删除你的旧代码时要不会感到不适。

(30) 为任何问题提出一个以上的解决方案。试图找到多种解决方案迫使你以不同的方式思考，一旦你有不同的解决方案，你可以通过选择正确的权衡来决定。

(31) 你从事的模块越多，你获得的领域知识就越多。你拥有的领域知识越多，你需要加入的会议就越多。你参加的会议越多，你写的代码就越少。通过记录和分享领域知识来打破这个链条，这样你就不是唯一的联系点了。我知道说起来容易，实施起来难。

(32) 当你被困在某个问题上相当长的时间而没有任何进展时，重新表述这个问题或向别人解释这个问题，神奇的是这在大多数情况下是有效的。这就是为什么 橡皮鸭调试(
http://www.nowamagic.net/librarys/veda/detail/968 ) 会如此流行了。

(33) 你不需要了解整个代码库就可以开始工作。了解架构和生命周期，然后开始做你的模块。不要浪费你的时间去理解每一个编写的类。

(34) 代码是一种负债，而不是一种资产。你拥有的代码越多，就越需要阅读、理解、测试和维护。最好的代码是没有代码。

(35) 学习如何在StackOverflow上发布问题。你很少需要发布问题，但这是一项有用的技能，当你在一个文档和用户都很有限的库/框架上工作时，它就会派上用场。

(36) 如果你偶然发现其他模块有问题，而你并没有使用相关模块，那么请告知相关的开发人员，或在Scrum中提及并修复问题。不要因为自己现在或将来不使用该模块，就弃之不顾。

(37) 你编写的函数应该没有副作用或最小的副作用。这使得函数易于独立测试。

(38) 请不要写你自己的日期格式化/解析函数。每种编程语言都有许多流行的日期库，使用它们就可以了。日期和时区比你想象的要复杂得多。

04. 安全 Security

(39) 每个开发者都应该知道如何编写更加安全的代码。有时编写出来的设计/抽象代码不太好也是可以的，但编写有安全漏洞的代码绝对不行。阅读 OWASP Top 10(
https://owasp.org/www-project-top-ten/ ) 文档来开始吧。

(41) 永远不要在你的代码库中推送任何敏感信息。在提交和推送之前，一定要仔细检查你的代码是否有电子邮件地址、电话 码、密码、认证令牌、私钥等。

(42) 始终对用户的输入进行验证。不要假设或期望用户会以正确的格式发送某些输入。在验证时，总是倾向于正确的白名单而不是错误的黑名单。

05. 拉取请求 Pull Requests

(43) 你可以在拉动请求评论中给予赞美。我们在审查时总是关注不好的部分，却忽略了其它美妙的地方，一个小小的赞赏可以给你的同伴带来微笑。下次试试吧。

(44) 将阅读拉动请求和了解其他开发者的评论作为日常工作，以便对不同功能和编码标准理解的更加深入。

(45) 代码格式化和其他标准应该是自动化的，并且用它们建立你的项目开发管道，这样整个代码库就能保持一致和干净。请不要再在PR评论中争论Tabs与Spaces的问题了。

(46) 创建简短的拉动请求。如果你在做多个功能，把它们分成多个PR。并给审查者足够的时间来审查，不要在部署前一小时创建PR。

06. 学习 Learning

(47) 作为一个程序员，你应该从根本上享受学习和探索。如果你不喜欢这些，你应该认真考虑其他职业选择。

(48) 你不需要学习市场上出现的每一项技术。保持对自己主流技术的更新、迭代，并在需要时学习和使用它们。

(49) 从一个刚毕业的大学生实习生那里也可以学到很多东西。永远不要把你的学习范围只限制在高职位的人身上。

(50) 阅读你所涉及技术的不同开源项目的源代码，了解和学习代码瘦身的做法与组织。

(51) 学习一些技术的最好方法是自己建立一个高度简化的版本。( Build-your-own-x (
https://github.com/danistefanovic/build-your-own-x ) )

(52) 在几天内学习一种语言很容易。但要了解其生态系统则需要几个月或几年的时间。

(53) 探索不同的编程语言以了解不同的范式编程思想。了解不同的思想将有助于你以后在不同的使用环境下，可以选择合适的语言。

(54) 学习git。不仅仅是git pull和git commit，还要了解所有的高级概念。无论你使用什么技术，git都会是最通用技术栈。

(55) 鉴于大多数开发者的工作都集中在 络编程上。了解 络系统中的基础协议是很有帮助的。HTTP、HTTPS、SSL/TLS、DNS、SMTP、IPv4、IPv6等等。

(56) 拥有良好的CSS专业知识会让你看起来像个魔术师，总能让人眼前一亮! 如果你是一个全栈开发人员，花几天时间来掌握CSS，就可以省去几个小时的”我不知道我在做什么”的状态。

(57) 用一个有吸引力的用户界面设计来打动人们（显然不是指领域专家）比用一个强大的系统结构来打动人们要容易得多。因此，当你在进行概念验证时，拥有良好的设计技能是非常有用的。(只是不要滥用它，把所有东西都硬编码成HTML)

07. 生产力 Productivity

(58) 创建细化的子任务来跟踪你的进展，特别是当你正在处理一项巨大的任务时。很难描述某件事情是否完成的这种幸福感，这反过来又会激励你前进的步伐。

(59) 不要试图在同一时间处理多项任务。专注于一项任务，尽量减少上下文切换。殊不知频繁切换的成本比你预期的要高的多。

(60) 改进和定制你的工作流程（IDE、调试工具、生产力工具、CI/CD），以便你可以更快地迭代。

你迭代得越快，你的失败就越快。

你失败得越快，你的学习就越快。

(61) 将你的时间投入到常规任务的自动化中。如果你做了两次以上的事情，就写一个工具，让它在第三次的时候自动化。同时，不要浪费几个小时/几天的时间来自动化一个几乎连几分钟或更短时间的简单任务。找到正确的平衡点！

(62) 用文件夹和标签整理你的工作邮件（也包括个人邮件）。每天花一点功夫整理邮件，将有助于你在需要时迅速找到重要文件或对话。

(64) 文档技能在这个行业被高度低估。学习如何撰写设计文件、变更提案等。开始使用笔记工具来组织和记录几乎所有的东西 – MoMs，个人目标，职业目标，随机想法，书籍摘要，以及其他列表。( 推荐工具： Notion ( https://notion.so/ ) )

(65) 在给你的任务做排期时，总是保留一些缓冲时间。你永远不知道在一个未开发的功能/需求里会遇到什么突发状况。

(66) 最好是听器乐或 Lo-fi节拍 (
https://www.youtube.com/watch?v=f02mOEt11OQ ) 或平静的声音，而不是带歌词的音乐。就我个人而言，我觉得写代码时听器乐会更有感觉，而且令人惊讶的是， 科学也证明了这一点 (
https://jaxenter.com/music-for-coding-152327.html ) 。

08.自己 Self

(67) 现在就解决你在办公桌前的身体姿态问题！

(68) 在工作之外有不同的爱好是件好事。不要因为你是一个开发人员，就24小时不间断地编码。

(69) 善待每一个人! 始终保持冷静! 而最重要的是：要谦虚！

(70) 记住要定期休息，不要把自己累坏了。

(71) 给自己投资一套好的工作设备。鉴于你大部分时间都在你的办公桌前度过（特别是在这些远程工作的日子里）。多花几分钱购买高质量的产品是值得的。

(72) 阅读关于不同的 认知偏见 (
https://en.wikipedia.org/wiki/Cognitive_bias ) 。它不仅能帮助你做出更好的个人决定，还能帮助你做出更好的技术决定。

(73) 在你的职业生涯早期就开始投资。了解复利的力量，相信我，它是神奇的。同时，不要过度储蓄，当你不享受当下时，储蓄的作用便毫无意义，要择机储蓄。

09. 人际关系 Interpersonal

(74) 人际交往能力与你的技术能力同样重要。练习指导、公开演讲、领导项目等。开发人员不需要遵循不善于 交的刻板印象。

(75) 不是每个人都会有和你一样的动机。永远不要指望别人会因为你的原因而对任何话题感到兴奋并表现出兴趣。不同的人对不同的动机作出反应也会不同。

(76) 不要以你的同事（事实上是任何人）不知道的东西来判断他们的能力。

(77) 学习如何推销自己。你可能在很多方面都很有技巧，但如果你不在正确的平台上展示这些技能，没有人会欣赏。

(78) 帮助你周围的人变得更好，分享你所学到的东西，并写下你所学到的东西的行为将使你更好地理解它。

(79) 永远不要犹豫说 “我不知道”。你可能是一个非常会说谎话的人，但我们的大脑在发现某人是否在说谎或作假方面是惊人的。而更糟糕的是这会导致更高的期望。

(80) 你的团队中一定会有一个开发者大佬，所谓”三人行，必有我师”，他几乎能解决任何问题。不要被他们的技能所吓倒，而是阅读他们的拉动请求，进行技术聊天，并定期从他们那里获得反馈，以提高自己。

(81) 你很有可能在工作中遇到你的闺蜜。不要克制自己，可以和同事试着提升一下你们之间的关系。(请自行斟酌采纳此建议)

10. 沟通 Communication

(82) 听着，我重复一遍，听着！

(83) 如果你在会议上没有任何观点，那也没关系，千万不要喋喋不休，浪费别人的时间。

(84) 不要只用 “嗨/你好/早上好 “给别人发信息，然后等待他们的回复。给他们讲讲你发信息的原因。没有人只想听你的问候或祝福。

(85) 在解释你的设计时，尽可能使用图示。一张图片胜过千言万语。而且对记录也有帮助。( 推荐工具： draw.io ( https://draw.io/ ) )

(86) 在向别人解释一些设计或概念时，减少行话的使用。不是每个人都能熟悉所有的技术术语。适当地平衡使用它们。

(87) 你不应该为问一个你认为微不足道或愚蠢的问题而感到羞耻。

(88) 如果你想在几分钟内完成工作，那就打电话。如果你想在几个小时内完成工作，那么就用IM。请尽量减少使用电子邮件来完成工作（2021年人们还在使用电子邮件吗？)，但可以用于工作联系。

(89) 当你向别人寻求帮助时，不要只是到处说 “嘿，X不工作，你能帮助我吗？”，而是说 “嘿，当我运行X时，我面临错误Y，我已经研究并尝试了解决方案Z，但它似乎也不工作，你能帮助我解决这个问题吗？”。在接受别人的帮助之前，请做好研究，不要因为你的代码中的一些错别字而浪费别人的时间，真的！”。

(90) 不要成为自行车棚效应的牺牲品。在会议或讨论中，要重视复杂/关键的项目，而不是琐碎的项目。

11. 职业生涯 Career

(91) 如果你在做你不喜欢的事情，那可以接受，但在你讨厌的事情上工作是不可以的。

(92) 当你在职业生涯的早期，优先考虑学习和机会，而不是工资、福利等。在学习率高的活动或工作上投入更多时间。学习是复利的，你必须尽早开始才能收获它。

(93) 你在工作中的动机应该是为团队和项目增加价值，而不是为了高薪或晋升而给任何人留下印象。如果前者的收益是终身的，后者的收益只是暂时的。

(94) 在你的简历上花点时间，并始终保持更新。建议有一个描述你的项目和经验的 站/博客。

(95) 你解决的问题如果更加大局观和针对性，那么你的角色的重要性就越高。请适应不确定性和全局性。

(96) 每六个月都要问自己这些问题：

我是否正在学习新的技能并扩大我的专业领域？

我是否在组织中产生了影响？

我的技能和经验是否得到了足够的 酬？

如果你的答案都是否定的，那么你必须考虑更换公司或团队。如果你已经在目前的公司工作了2-3年以上，而且你的答案都是肯定的，那么你还是应该考虑换公司，或者至少对它持开放态度。除非你去寻找，否则你永远不会知道你错过了什么。

(97) 如果你仔细注意，编程与写作非常相似。编程语言类似于人类语言，程序员类似于作家/诗人。任何人都可以成为一个作家，但要成为一个好的作家需要大量的努力和时间。

(98) 定期与你的经理进行1对1交流，并寻求反馈。不要等到年度审查时才临时抱佛脚。

(99) 如果你的经理不为你的失败负责，而把责任归咎于你，那么你在他们手下工作就是在冒个人和职业成长的风险。

(100) 经验年限只是一个数字。有时你会发现初级工程师比高级工程师更有技能。不要误会我的意思，经验教给你的不仅仅是技能，所以工作经验也很重要，但这不是唯一因素。

12. 奖励 Bonus

(101) 记住帕累托原则（80/20规则）。它确实适用于软件工程中的几乎所有情况。

80%的工作是由20%的工程师完成的

80%的影响是由20%的工作完成的

80%的bug是由20%的代码造成的

80%的性能缓慢是由20%的代码造成的

我可以继续举出无数的例子。

(102) 我们能不能为那些在StackOverflow出现之前不得不写代码的开发者默哀一下？StackOverflow对你95%的问题都有解决方案。(只要不开始问你的个人问题）。

(103) Git提交信息应该有足够的描述性，以便你能从成千上万的提交中轻松地搜索到它们。不要再写这样的信息。”修复了一个bug”，”提高了性能”，”模块X变化 “等等。

最后

如果您遇到什么疑问或者建议，欢迎多多交流，大家共同进步。

在阅读过程中，如果有不正确的地方，希望您能提出来，我会努力改正并提供更优质的文章。