如果您已经编程了一段时间并且想学习编程那么您可能正在考虑什么才是一个好的程序员计算机科学专业的毕业生可以为从事软件开发和编程工作做些什么对于初级开发人员的期望是我从Facebook和Emails上跟随我的许多学生那里收到的一些常见问题。这些大多数是大学生由于互联网他们现在可以访问大量信息并渴望提前学习一些东西以准备编程工作面试。1. 构建软件过早优化是万恶之源。不要低估了这个说法的有效性。你很少需要自己从头开始去开发一些东西几乎每一种应用场景都已经有了相应的库和依赖项。所以不要重复发明轮子。搞清楚问题域是找到解决方案之前的第一步但我们却经常会跳过第一步直接去寻找解决方案。不要太过于追求完美。首先让它能够正常运行然后再去优化。优先级最高的事情应该是先保证交付。糟糕的程序员操心代码优秀的程序员操心数据结构以及它们之间的关系。--Linus Torvalds在代码注释中解释你为什么要写这些代码而不是解释你在做什么。但不要过度描述不要把注释当成小说写。有意义的错误日志可以节省大量的调试时间。在错误日志中提供所有相关信息而不仅仅是“error occurred in Function X!”另外不要记录任何敏感信息或个人信息。100% 的代码行或分支覆盖率并不意味着你的代码就没有 bug。测试用例要覆盖所有的功能需求而不是覆盖代码行或分支。如果你在修复 bug请编写相应的测试用例那么这个 bug 就不会在未来某个时刻出现。bug 的出现通常是因为错误的假设为所有这些错误的假设编写测试用例将会让应用程序变得更加健壮。在人们阅读你的代码时让他们能够在不记住超过 7 样东西的情况下理解你的代码。因为人类大脑的短期记忆无法同时记住 7 样以上的东西。这也是为什么很多代码检查器在遇到包含超过 7 个参数的函数时就会发出警告。不要因为别人告诉你要怎样去做一件事情你就照做。你要明白为什么要这么做如果你不信服可以挑战一下。解决问题应该是每个工程师都最擅长的技能。你所在的组织有很多问题需要解决所以请开始解决问题吧。虽然不是所有问题都能够得到解决但在尝试解决问题的过程中你会学到很多。2. 系统设计最好的系统设计通常是最简单的。Keep it simple, stupid!KISS 原则。设计模式和最佳实践并非银弹。一个好的工程师遵循最佳实践但一个优秀的工程师知道什么时候打破最佳实践。理解抽象。代码中引入的不必要的复杂性通常是由于糟糕的抽象导致的。一个系统的健壮程度取决于它最薄弱的地方。所以请关注系统的瓶颈部分。偏离主要源头越远事情就越糟糕。所以尽量减少跳跃这个原则适用于技术和非技术方面。不存在完美的解决方案一切都是权衡的结果。列出解决方案的优点和缺点以及你的真正要求。你在项目中引入的每一项技术都有相应的风险。衡量风险并制定降低风险的计划不穿救生衣就不要往海里跳。避免过早抽象。解决你现在的问题这样就够了。当你看到类似的问题或者模式出现时这个时候应该考虑对其进行抽象。“软件设计有两种方法一种是保持简单简单到没有明显的缺陷另一种是让它变得复杂复杂到没有明显的缺陷。第一种方法要困难得多因为要保持简单是很难的”。——Tony Hoare。不要对编程语言或框架有太多偏见。如果你喜欢某种编程语言不要过于崇拜它也不要到处用它。如果你讨厌它也不要一直抱怨它。每种编程语言或框架都是为特定的场景而设计的。作为工程师你的工作是为特定场景选择正确的工具。当你弄清楚代码是怎样运行却忘记了为什么要这么做那么代码中就有很多不必要的抽象和复杂性需要清理。一旦复杂性累积起来就很难消除。不要认为你当下做出的变更所带来的一点点复杂性没什么大不了的如果每个开发人员都这么做复杂性就会成倍地增加。如果你决定要重写某个组件或服务请三思而后行。读代码比写代码难这就是为什么“重写软件”的想法在软件开发中非常常见。不要犹豫去挑战高级工程师或架构师提出的设计有时候你的设计比他们的更好。提出有说服力的观点并进行客观比较但不要做一个盲目自信的混蛋。大多数时候静态类型语言比动态类型语言要好尽管静态类型系统带来了一些额外的开销。这也是为什么 TypeScript 会是最受欢迎的编程语言之一。3. 一些其他贴士优化代码让它们更容易被读懂。冗长乏味的 20 行代码总比晦涩难懂的 1 行代码要好。新手容易与自己编写的代码建立情感联系但在敏捷开发环境中需求和代码会不断发生变化所以你要习惯于不断修改和删除旧代码。对于任何一个问题都要想出不止一种解决方法。试图找到多个解决方案会迫使你以不同的方式思考问题在有了不同的解决方案之后你就可以做出权衡。你负责的模块越多获得的领域知识就越多。你拥有的领域知识越多需要参加的会议就越多。你参加的会议越多写的代码就越少。通过记录和分享领域知识来打破这个链条这样你就不会成为唯一的瓶颈点。当然我也知道这说起来容易做起来难。当你在某个问题上困了很长一段时间而没有任何进展时重新描述这个问题或向别人解释这个问题大多数情况下这样做都会有神奇的效果。为什么小黄鸭调试法会如此受欢迎现在你应该知道答案了。你不需要在理解了整个代码库之后才开始工作。在了解了系统架构和生命周期之后就可以开始开发你的模块不要浪费时间去了解每一类是干什么的。代码是负债而不是资产。代码越多需要阅读、理解、测试和维护的代码就越多。最好的代码是没有代码。学习如何在 StackOverflow 上提问题。你可能很少需要在这类平台上提问题但是当你使用的库或框架只有很有限的文档或用户时这就成了一项有用的技能。如果你发现了其他模块出现了 bug请通知相应的开发人员或者在 Scrum 中提及不要因为这些模块不是你负责的就置之不理。你编写的函数应该没有副作用这样易于进行独立的测试。看在上帝的份上请不要自己编写日期格式化或日期解析函数。每种编程语言都有很多流行的库使用它们就可以了日期和时区问题比你想象的要复杂得多。4. 关于安全每个开发人员都应该知道如何编写安全的代码。基于糟糕的设计或抽象写代码是可以的但有安全漏洞的代码绝对不行。写代码前先了解一下 OWASP 项目。当你想要快速格式化或验证 JSON / XML / YAML 数据时不要使用在线格式化器或验证器特别是如果你处理的是一些机密的生产数据。这个时候请使用本地编辑器或命令行工具不要冒着把公司数据泄露出去的风险。(推荐工具 CyberChefhttps://gchq.github.io/CyberChef/请下载离线使用)永远不要向代码库中推送敏感信息。在提交和推送代码之前一定要仔细检查代码中是否包含了电子邮件地址、电话号码、密码、认证令牌、私钥等信息。总是对用户输入进行验证和清理。永远不要假设或期望用户按照指定的格式输入数据。在验证用户输入时首选白名单而不是黑名单。5. 关于拉取请求你可以在拉取请求的评论中加入赞美之词。当我们在代码评审时总是专注于不好的部分而一个小小的赞美可以给你的同事带来微笑。下次可以试一试这样做。每天查看拉取请求阅读其他开发人员的评论以获得关于特性和编码标准的不同观点。代码格式和其他标准应该被自动化。使用代码格式化器和检查器来构建项目开发管道让整个代码库保持一致和整洁。请停止在评论中进行有关 tab 好还是空格好的争论创建小而美的拉取请求。如果你正在处理多个功能请将它们分成多个拉取请求。给评审人员留有足够的评审时间不要在部署前 1 小时创建拉取请求。6. 关于学习作为一个程序员你应该喜欢学习和探索。如果你不喜欢这些需要考虑其他职业选择。你不需要去学习每一项技术你只需要紧跟潮流在需要的时候学习和使用它们。从一个刚毕业的实习生身上也可以学到很多东西。永远不要把你的学习对象局限于更高职位的人。阅读你所使用的开源项目的源代码理解和学习干净的代码实践和代码组织方式。一种学习技术的方法是自己尝试为某个开源项目构建一个高度简化的版本 (https://github.com/danistefanovic/build-your-own-x)。你可以在几天内学会一门编程语言但要了解它的生态系统需要几个月甚至几年的时间。探索不同的编程语言了解不同的编程范式。了解了不同的编程范式当你在为不同的应用场景选择正确的编程语言时就会有所裨益。学习 git不仅仅是 git pull 和 git commit要理解 git 所有的高级概念。不管你使用的是什么技术都不能没有 git。大多数开发人员的工作都集中在 Web/ 网络编程方面所以了解网络系统的底层协议是很有必要的HTTP、HTTPS、SSL/TLS、DNS、SMTP、IPv4、IPv6 等。拥有良好的 CSS 专业知识会让你看起来像一个大神如果你是一个 Web 全栈开发者请花几天时间学习 CSS这将为你避免“不知道自己做什么”的尴尬。一个有吸引力的 UI 设计比一个健壮的系统架构更容易给人们显然不是指领域专家留下深刻的印象。所以当你在进行概念验证时拥有良好的设计技能是非常有用的但不要把所有东西都硬编码成 HTML。7. 关于效率创建细粒度的子任务来跟踪任务进度尤其是当你在处理一项巨大的任务时。检查某件事是否已经完成这会给人一种难以言表的愉悦感这反过来会激励你坚持下去。不要试图同时做多个任务专注于一个任务尽量减少上下文切换上下文切换的成本比你预想的要高。改进和定制你的工作流IDE、调试工具、生产力工具、CI/CD帮你进行更快的迭代。8. 迭代得越快失败得越快失败得越快学习得就越快。把你的时间花在自动化常规任务上。如果你做某件事超过两次那就开发一个工具让它在第三次时可以自动完成。但不要浪费太多时间去自动化一个只需要几分钟时间就可以完成的简单任务。你应该找到一个正确的平衡点用文件夹和标签来整理工作邮件包括私人邮件。每天稍微整理一下邮件可以帮助你在需要的时候快速找到重要的文件或聊天记录。学习基本的 vi 绑定即使 vi 不是你的默认编辑器。你可以在几乎所有的文本编辑器中使用 vi 绑定相信我在这之后你的效率将得到大幅提升。在这个行业中文档技能被严重低估了。学习如何撰写设计文档、变更建议等。开始使用笔记工具来组织和记录几乎所有的事情——备忘录、个人目标、职业目标、随机出现的想法、书籍摘要等等。在评估任务时一定要预留一些缓冲时间你永远不知道在一个未知的洞穴里会遇到什么怪物。如果你要边听音乐边干活最好听器乐或低保真节拍或平静的音乐而不要听带有歌词的音乐。我个人觉得在听演奏器乐时更有效率这并不奇怪科学方面已经为此提供了证据支持。9.软件永远不会“完成”软件永远不会“完成”软件是一个迭代的过程在其生命周期中包含许多修订和更新。我们的工作是创造一个能认识到这一点的环境。同样我们从来没有期望市场营销和客户获取是“完成的”它们也是迭代过程。在每个迭代中随着我们不断地为业务交付价值我们也不断地学习和成长。即使已经做了一些成功的发布我们从来没有打算“停止”做这些事情。如果软件可以在一个版本中完成就好了但这不是现实。需求文档充满了模糊性软件的第一个版本充满了“哦那是我写的但不是我的意思”的场景。最好的软件能激发新的想法和功能需求看到新的销售管理系统更加高效就会激发出更高的效率。世界在变化竞争对手提供了新的功能人们就有了新的想法。另外总是有一些bug需要修复可能是在代码中也可能是在构建代码的底层软件框架和系统中。某些软件可能是完美的但可以确信的是随着时间的推移人们会发现它所构建的平台存在各种漏洞。我们的工作就是让一个组织能够认识到这一点。认识到这一点的方法是建立一个有信心定期发布新版本的组织。当完全自动化测试和其他工程规范就位时我们就建立了信心。这种信心创造了一种能力可以避免过长的发布周期而是每季度、每月甚至每周发布高质量的软件。特定的频率并不重要但是信心很重要自信能够带来更快的创新。10. 安全是每个人的责任不管知不知道无论愿不愿意我们都是从事安全行业的。所有软件都有安全需求和潜在的安全漏洞。开发软件所涉及的系统也有安全需求和漏洞。虽然防火墙和入侵检测等安全的基础设施组件是必要的但它们还不够还必须使用内置的安全控制来设计、实现和维护软件平台。安全既是好的技术也是好的流程。如果认为我们不是被攻击的目标那就错了。所有的计算机系统都是被攻击的目标因为攻击不仅是为了其中的信息而仅仅是它是一台计算机这样的一个事实。例如一个没有价值信息的系统是网络攻击目标因为它可以被用来转发对其他计算机的攻击或挖掘比特币或存储他人的盗版视频。安全不是打开/关闭这样按钮有许多灰色地带。安全性最好从一开始考虑。事后的亡羊补牢是昂贵的而且往往是无效的。我们不会先造一艘船然后再“添加”一种让它漂浮的功能。同样也无法先构建一个系统然后按下“具有安全性”按钮就安全了。安全是关于风险和对风险的容忍度。对两个节点之间的通信进行加密并不能保证它的安全性但它提高了安全性只有超级算力才有可能破解密码。在一个领域降低风险对其他领域没有帮助。保护网络并不能防止物理安全问题。一个人撑开一扇门其他人就能偷走你的备份磁带。正如吉恩·斯帕福德(Gene Spafford)的一句名言”唯一真正安全的系统是一个关了电、浇铸在混凝土里、由全副武装的警卫把守在绝缘房间里的系统——即便如此我还是心存疑虑。“遵守NIST CSF国家标准与技术网络安全框架学会、PCI DSS支付卡行业数据安全标准和SOC 2服务组织控制报告等安全标准可以量化风险如果做得合适还可以降低风险。这些标准并不能保证绝对安全绝对安全是不存在的。更重要的是它们为如何负责任地应对和报告不可避免的安全漏洞提供了指导。诚实、直率、公开是良好的建议。软件如果不管它就像面包一样变得陈旧。我们的工作是平衡安全妄想与现实并适当预算时间和资源。11. 伟大来自于成千上万的小进步伟大来自于在很长一段时间内所做的成千上万也许是数百万的小进步变更。如果变更的效果都被测量是负面的那么变更将被回滚。谷歌也不是一天建成的。谷歌的搜索引擎是数百万个人改进的结果。搜索质量小组每周开会一次工程师们走上讲台提出他们的修改建议。他们展示了在模拟的环境中会有多大的改进委员会进行辩论并投票表决。几周后将对测量结果进行评审并决定保留或回滚更改。谷歌搜索是迭代开发战胜“数据大爆炸”思维的胜利。谁都不可能在一开始做出一个好的搜索引擎。只有在好莱坞电影中一个聪明的极客才会想出一个惊人的新点子并且第一次就能完美地实现它。在现实世界中一夜成名需要数年的时间。无论试图实现的目标是一个为客户提供更好服务的系统还是一个更高效、错误更少的系统还是一个运行更顺畅的系统都是如此。我们的工作是要求系统的设计能够容易拥抱新的变化并定义相关的KPI关键性能指标这些KPI可以在更改之前和之后方便地进行度量。最重要的是必须有一个流程来检查结果并决定保留或回滚变更。回滚不应被视为失败或受到惩罚。从每次回滚中学到的与在每次保留的更改中学到的一样有价值。托马斯·爱迪生声称在发明灯泡的过程中测试了1000根灯丝。当一位记者问他”失败1000次是什么感受“他回答说”我没有失败1000次。灯泡是一项有1000个步骤的发明。”12. 关于自己马上调整好你的身体姿势工作之外最好有其他业余爱好。虽然你是一名开发人员但也没必要全天候在写代码。善待每一个人保持冷静最重要的是要谦虚记住要经常休息不要把自己弄得筋疲力尽。购买一套好的工作站因为你大部分时间都在办公桌前度过尤其是在远程工作的日子里在高质量的产品上多花点钱是值得的。去了解不同的认知偏见这样不仅能帮助你做出更好的个人决定还能帮助你做出更好的技术决策。在职业生涯早期就开始投资了解复利的力量相信我它很神奇。同时不要过度储蓄如果你无法享受当下就算存了很多钱又有什么意义呢13. 关于人际关系人际交往能力和你的技术能力一样重要。有意识地锻炼指导他人、公共演讲、领导项目等方面的能力。开发者可以打破给人留下的“社交无能”的刻板印象。并不是每个人都有和你一样的动机。不要因为你对某个话题感兴趣就指望别人也会感兴趣。不同的人对不同的动机有不同的反应。不要用你的同事事实上是任何人不懂的东西来评判他们。学习如何推销自己。你可能对很多东西都很熟练但如果你没有在正确的平台上展示这些技能没有人会欣赏你。帮助你周围的人让他们变得更好。传授或分享你所学到的东西。教授或写一些你学过的东西这样会让你更好地理解它们。勇敢地说出“我不知道”。你可能很擅长撒谎但我们的大脑很善于识别某人是否在撒谎或假装。你的团队中始终会有一个顶级的开发人员他几乎可以解决任何问题。不要被他们的技术能力吓倒看看他们提交的 PR跟他们聊技术方面的东西并定期从他们那里获得反馈来提高自己。你很有可能会在工作中遇到你最好的朋友不要因此无法向他们敞开心扉要不要接受这个建议取决于你自己的判断。14. 关于沟通倾听不疲于倾听如果你在会议上没有什么想说的也没关系不要东拉西扯浪费别人的时间。在给别人发消息时不要只是发“你好”或“早上好”之类的问候然后等着他们回话。你要告诉他们你找他们有什么事没有人喜欢你这种毫无意义的问候或祝福。在向别人介绍你的设计时尽可能使用图表一图胜千言。在文档里使用图表也很有意义推荐工具 draw.io。向别人介绍某些设计或概念时少用行话。不是每个人都很熟悉技术术语在使用术语时要恰到好处。不要羞于去问一些你认为琐碎或愚蠢的问题。如果你想在几分钟内完成工作那就打电话。如果你想在几个小时内完成工作那就使用即时通讯工具。如果你不想完成工作那就发邮件2021 年人们还在使用邮件吗。当你向别人寻求帮助时不要只说“嘿这个有问题你能帮我吗”你要说“嘿我在运行程序 X 时出现了错误 Y我研究并尝试了解决方案 Z但它似乎也不行你能帮我解决这个问题吗”。在向别人寻求帮助之前先自己做一些调查不要因为代码中小小的拼写错误而浪费别人的时间说真的不要成为自行车棚效应避重就轻的牺牲品。在会议或讨论中重视复杂或关键的事项而不是琐碎的事项。15. 关于职业生涯如果你不喜欢自己做的事情没关系但如果你讨厌自己做的事情那就不能接受了。当你刚进入职场时优先考虑的是学习和发展的机会而不是薪水、福利等。在学习效率高的活动或工作上投入更多的时间。发展综合能力你必须及早开始。你工作的动力应该是为团队和项目增加价值而不是为了给别人留下好印象进而获得更高的薪水或晋升。如果前者做好了后者自然会光顾。花点时间写简历并让它保持最新。建议为自己做一个可以描述你的项目和经验的作品集网站。你的职位越高你要解决的问题就越抽象模糊。所以你要学会适应不确定性。每六个月问自己以下这些问题我是否在学习新的技能、拓宽自己的专业领域我是否对组织产生了影响从我的技能和经验来看我的薪水是否足够高如果你的答案都是否定的那么你必须考虑换公司或团队了。如果你在现在的公司已经工作了 2 至 3 年以上并且你的答案都是肯定的那么你应该考虑换公司或者至少要对换公司持开放态度。如果你仔细观察你会发现编程和写作非常相似。编程语言类似于人类语言程序员类似于作家和诗人。任何人都可以成为作家但要成为一名优秀的作家需要付出大量时间和努力。定期与经理进行一对一面谈并寻求反馈不要等到年终总结时才发现“惊喜”。如果你的经理没有为你的失败负责并责怪你那么在他们手下工作就是在拿你的个人和职业发展冒险。经验年限只是一个数字。有时候你会发现初级工程师比高级工程师对某些事情更熟悉。但请不要误解了我的意思经验教会你的不仅仅是技能。工作经验固然重要但这并不是评判一个工程师的唯一因素。16. 额外的建议记住帕累托法则 (80/20 法则)它几乎适用于软件工程的方方面面80% 的工作是由 20% 的工程师完成的80% 的影响是由 20% 的工作所带来的80% 的错误是由 20% 的代码造成的80% 的慢性能是由 20% 的代码造成的。我可以举出无数个例子对于那些在 StackOverflow 出现之前就开始写代码的开发人员我们是否应该给他们一点掌声StackOverflow 可以解决你 95% 的问题但千万别在上面问你的个人问题。Git 的提交消息应该具备足够好的描述这样你就可以从成千上万的代码提交中轻松搜索到你想要的。停止使用诸如“修复了一个 bug”、“改进了性能”、“修改了 X 模块”之类的描述。参考文献每个程序员和软件工程师应该知道的10件事 | 码农家园10 个角度分析软件工程师应该知道的 100 件事关于软件开发都应该知道的10个常识 - 知乎
如果您已经编程了一段时间并且想学习编程那么您可能正在考虑什么才是一个好的程序员计算机科学专业的毕业生可以为从事软件开发和编程工作做些什么对于初级开发人员的期望是我从Facebook和Emails上跟随我的许多学生那里收到的一些常见问题。这些大多数是大学生由于互联网他们现在可以访问大量信息并渴望提前学习一些东西以准备编程工作面试。1. 构建软件过早优化是万恶之源。不要低估了这个说法的有效性。你很少需要自己从头开始去开发一些东西几乎每一种应用场景都已经有了相应的库和依赖项。所以不要重复发明轮子。搞清楚问题域是找到解决方案之前的第一步但我们却经常会跳过第一步直接去寻找解决方案。不要太过于追求完美。首先让它能够正常运行然后再去优化。优先级最高的事情应该是先保证交付。糟糕的程序员操心代码优秀的程序员操心数据结构以及它们之间的关系。--Linus Torvalds在代码注释中解释你为什么要写这些代码而不是解释你在做什么。但不要过度描述不要把注释当成小说写。有意义的错误日志可以节省大量的调试时间。在错误日志中提供所有相关信息而不仅仅是“error occurred in Function X!”另外不要记录任何敏感信息或个人信息。100% 的代码行或分支覆盖率并不意味着你的代码就没有 bug。测试用例要覆盖所有的功能需求而不是覆盖代码行或分支。如果你在修复 bug请编写相应的测试用例那么这个 bug 就不会在未来某个时刻出现。bug 的出现通常是因为错误的假设为所有这些错误的假设编写测试用例将会让应用程序变得更加健壮。在人们阅读你的代码时让他们能够在不记住超过 7 样东西的情况下理解你的代码。因为人类大脑的短期记忆无法同时记住 7 样以上的东西。这也是为什么很多代码检查器在遇到包含超过 7 个参数的函数时就会发出警告。不要因为别人告诉你要怎样去做一件事情你就照做。你要明白为什么要这么做如果你不信服可以挑战一下。解决问题应该是每个工程师都最擅长的技能。你所在的组织有很多问题需要解决所以请开始解决问题吧。虽然不是所有问题都能够得到解决但在尝试解决问题的过程中你会学到很多。2. 系统设计最好的系统设计通常是最简单的。Keep it simple, stupid!KISS 原则。设计模式和最佳实践并非银弹。一个好的工程师遵循最佳实践但一个优秀的工程师知道什么时候打破最佳实践。理解抽象。代码中引入的不必要的复杂性通常是由于糟糕的抽象导致的。一个系统的健壮程度取决于它最薄弱的地方。所以请关注系统的瓶颈部分。偏离主要源头越远事情就越糟糕。所以尽量减少跳跃这个原则适用于技术和非技术方面。不存在完美的解决方案一切都是权衡的结果。列出解决方案的优点和缺点以及你的真正要求。你在项目中引入的每一项技术都有相应的风险。衡量风险并制定降低风险的计划不穿救生衣就不要往海里跳。避免过早抽象。解决你现在的问题这样就够了。当你看到类似的问题或者模式出现时这个时候应该考虑对其进行抽象。“软件设计有两种方法一种是保持简单简单到没有明显的缺陷另一种是让它变得复杂复杂到没有明显的缺陷。第一种方法要困难得多因为要保持简单是很难的”。——Tony Hoare。不要对编程语言或框架有太多偏见。如果你喜欢某种编程语言不要过于崇拜它也不要到处用它。如果你讨厌它也不要一直抱怨它。每种编程语言或框架都是为特定的场景而设计的。作为工程师你的工作是为特定场景选择正确的工具。当你弄清楚代码是怎样运行却忘记了为什么要这么做那么代码中就有很多不必要的抽象和复杂性需要清理。一旦复杂性累积起来就很难消除。不要认为你当下做出的变更所带来的一点点复杂性没什么大不了的如果每个开发人员都这么做复杂性就会成倍地增加。如果你决定要重写某个组件或服务请三思而后行。读代码比写代码难这就是为什么“重写软件”的想法在软件开发中非常常见。不要犹豫去挑战高级工程师或架构师提出的设计有时候你的设计比他们的更好。提出有说服力的观点并进行客观比较但不要做一个盲目自信的混蛋。大多数时候静态类型语言比动态类型语言要好尽管静态类型系统带来了一些额外的开销。这也是为什么 TypeScript 会是最受欢迎的编程语言之一。3. 一些其他贴士优化代码让它们更容易被读懂。冗长乏味的 20 行代码总比晦涩难懂的 1 行代码要好。新手容易与自己编写的代码建立情感联系但在敏捷开发环境中需求和代码会不断发生变化所以你要习惯于不断修改和删除旧代码。对于任何一个问题都要想出不止一种解决方法。试图找到多个解决方案会迫使你以不同的方式思考问题在有了不同的解决方案之后你就可以做出权衡。你负责的模块越多获得的领域知识就越多。你拥有的领域知识越多需要参加的会议就越多。你参加的会议越多写的代码就越少。通过记录和分享领域知识来打破这个链条这样你就不会成为唯一的瓶颈点。当然我也知道这说起来容易做起来难。当你在某个问题上困了很长一段时间而没有任何进展时重新描述这个问题或向别人解释这个问题大多数情况下这样做都会有神奇的效果。为什么小黄鸭调试法会如此受欢迎现在你应该知道答案了。你不需要在理解了整个代码库之后才开始工作。在了解了系统架构和生命周期之后就可以开始开发你的模块不要浪费时间去了解每一类是干什么的。代码是负债而不是资产。代码越多需要阅读、理解、测试和维护的代码就越多。最好的代码是没有代码。学习如何在 StackOverflow 上提问题。你可能很少需要在这类平台上提问题但是当你使用的库或框架只有很有限的文档或用户时这就成了一项有用的技能。如果你发现了其他模块出现了 bug请通知相应的开发人员或者在 Scrum 中提及不要因为这些模块不是你负责的就置之不理。你编写的函数应该没有副作用这样易于进行独立的测试。看在上帝的份上请不要自己编写日期格式化或日期解析函数。每种编程语言都有很多流行的库使用它们就可以了日期和时区问题比你想象的要复杂得多。4. 关于安全每个开发人员都应该知道如何编写安全的代码。基于糟糕的设计或抽象写代码是可以的但有安全漏洞的代码绝对不行。写代码前先了解一下 OWASP 项目。当你想要快速格式化或验证 JSON / XML / YAML 数据时不要使用在线格式化器或验证器特别是如果你处理的是一些机密的生产数据。这个时候请使用本地编辑器或命令行工具不要冒着把公司数据泄露出去的风险。(推荐工具 CyberChefhttps://gchq.github.io/CyberChef/请下载离线使用)永远不要向代码库中推送敏感信息。在提交和推送代码之前一定要仔细检查代码中是否包含了电子邮件地址、电话号码、密码、认证令牌、私钥等信息。总是对用户输入进行验证和清理。永远不要假设或期望用户按照指定的格式输入数据。在验证用户输入时首选白名单而不是黑名单。5. 关于拉取请求你可以在拉取请求的评论中加入赞美之词。当我们在代码评审时总是专注于不好的部分而一个小小的赞美可以给你的同事带来微笑。下次可以试一试这样做。每天查看拉取请求阅读其他开发人员的评论以获得关于特性和编码标准的不同观点。代码格式和其他标准应该被自动化。使用代码格式化器和检查器来构建项目开发管道让整个代码库保持一致和整洁。请停止在评论中进行有关 tab 好还是空格好的争论创建小而美的拉取请求。如果你正在处理多个功能请将它们分成多个拉取请求。给评审人员留有足够的评审时间不要在部署前 1 小时创建拉取请求。6. 关于学习作为一个程序员你应该喜欢学习和探索。如果你不喜欢这些需要考虑其他职业选择。你不需要去学习每一项技术你只需要紧跟潮流在需要的时候学习和使用它们。从一个刚毕业的实习生身上也可以学到很多东西。永远不要把你的学习对象局限于更高职位的人。阅读你所使用的开源项目的源代码理解和学习干净的代码实践和代码组织方式。一种学习技术的方法是自己尝试为某个开源项目构建一个高度简化的版本 (https://github.com/danistefanovic/build-your-own-x)。你可以在几天内学会一门编程语言但要了解它的生态系统需要几个月甚至几年的时间。探索不同的编程语言了解不同的编程范式。了解了不同的编程范式当你在为不同的应用场景选择正确的编程语言时就会有所裨益。学习 git不仅仅是 git pull 和 git commit要理解 git 所有的高级概念。不管你使用的是什么技术都不能没有 git。大多数开发人员的工作都集中在 Web/ 网络编程方面所以了解网络系统的底层协议是很有必要的HTTP、HTTPS、SSL/TLS、DNS、SMTP、IPv4、IPv6 等。拥有良好的 CSS 专业知识会让你看起来像一个大神如果你是一个 Web 全栈开发者请花几天时间学习 CSS这将为你避免“不知道自己做什么”的尴尬。一个有吸引力的 UI 设计比一个健壮的系统架构更容易给人们显然不是指领域专家留下深刻的印象。所以当你在进行概念验证时拥有良好的设计技能是非常有用的但不要把所有东西都硬编码成 HTML。7. 关于效率创建细粒度的子任务来跟踪任务进度尤其是当你在处理一项巨大的任务时。检查某件事是否已经完成这会给人一种难以言表的愉悦感这反过来会激励你坚持下去。不要试图同时做多个任务专注于一个任务尽量减少上下文切换上下文切换的成本比你预想的要高。改进和定制你的工作流IDE、调试工具、生产力工具、CI/CD帮你进行更快的迭代。8. 迭代得越快失败得越快失败得越快学习得就越快。把你的时间花在自动化常规任务上。如果你做某件事超过两次那就开发一个工具让它在第三次时可以自动完成。但不要浪费太多时间去自动化一个只需要几分钟时间就可以完成的简单任务。你应该找到一个正确的平衡点用文件夹和标签来整理工作邮件包括私人邮件。每天稍微整理一下邮件可以帮助你在需要的时候快速找到重要的文件或聊天记录。学习基本的 vi 绑定即使 vi 不是你的默认编辑器。你可以在几乎所有的文本编辑器中使用 vi 绑定相信我在这之后你的效率将得到大幅提升。在这个行业中文档技能被严重低估了。学习如何撰写设计文档、变更建议等。开始使用笔记工具来组织和记录几乎所有的事情——备忘录、个人目标、职业目标、随机出现的想法、书籍摘要等等。在评估任务时一定要预留一些缓冲时间你永远不知道在一个未知的洞穴里会遇到什么怪物。如果你要边听音乐边干活最好听器乐或低保真节拍或平静的音乐而不要听带有歌词的音乐。我个人觉得在听演奏器乐时更有效率这并不奇怪科学方面已经为此提供了证据支持。9.软件永远不会“完成”软件永远不会“完成”软件是一个迭代的过程在其生命周期中包含许多修订和更新。我们的工作是创造一个能认识到这一点的环境。同样我们从来没有期望市场营销和客户获取是“完成的”它们也是迭代过程。在每个迭代中随着我们不断地为业务交付价值我们也不断地学习和成长。即使已经做了一些成功的发布我们从来没有打算“停止”做这些事情。如果软件可以在一个版本中完成就好了但这不是现实。需求文档充满了模糊性软件的第一个版本充满了“哦那是我写的但不是我的意思”的场景。最好的软件能激发新的想法和功能需求看到新的销售管理系统更加高效就会激发出更高的效率。世界在变化竞争对手提供了新的功能人们就有了新的想法。另外总是有一些bug需要修复可能是在代码中也可能是在构建代码的底层软件框架和系统中。某些软件可能是完美的但可以确信的是随着时间的推移人们会发现它所构建的平台存在各种漏洞。我们的工作就是让一个组织能够认识到这一点。认识到这一点的方法是建立一个有信心定期发布新版本的组织。当完全自动化测试和其他工程规范就位时我们就建立了信心。这种信心创造了一种能力可以避免过长的发布周期而是每季度、每月甚至每周发布高质量的软件。特定的频率并不重要但是信心很重要自信能够带来更快的创新。10. 安全是每个人的责任不管知不知道无论愿不愿意我们都是从事安全行业的。所有软件都有安全需求和潜在的安全漏洞。开发软件所涉及的系统也有安全需求和漏洞。虽然防火墙和入侵检测等安全的基础设施组件是必要的但它们还不够还必须使用内置的安全控制来设计、实现和维护软件平台。安全既是好的技术也是好的流程。如果认为我们不是被攻击的目标那就错了。所有的计算机系统都是被攻击的目标因为攻击不仅是为了其中的信息而仅仅是它是一台计算机这样的一个事实。例如一个没有价值信息的系统是网络攻击目标因为它可以被用来转发对其他计算机的攻击或挖掘比特币或存储他人的盗版视频。安全不是打开/关闭这样按钮有许多灰色地带。安全性最好从一开始考虑。事后的亡羊补牢是昂贵的而且往往是无效的。我们不会先造一艘船然后再“添加”一种让它漂浮的功能。同样也无法先构建一个系统然后按下“具有安全性”按钮就安全了。安全是关于风险和对风险的容忍度。对两个节点之间的通信进行加密并不能保证它的安全性但它提高了安全性只有超级算力才有可能破解密码。在一个领域降低风险对其他领域没有帮助。保护网络并不能防止物理安全问题。一个人撑开一扇门其他人就能偷走你的备份磁带。正如吉恩·斯帕福德(Gene Spafford)的一句名言”唯一真正安全的系统是一个关了电、浇铸在混凝土里、由全副武装的警卫把守在绝缘房间里的系统——即便如此我还是心存疑虑。“遵守NIST CSF国家标准与技术网络安全框架学会、PCI DSS支付卡行业数据安全标准和SOC 2服务组织控制报告等安全标准可以量化风险如果做得合适还可以降低风险。这些标准并不能保证绝对安全绝对安全是不存在的。更重要的是它们为如何负责任地应对和报告不可避免的安全漏洞提供了指导。诚实、直率、公开是良好的建议。软件如果不管它就像面包一样变得陈旧。我们的工作是平衡安全妄想与现实并适当预算时间和资源。11. 伟大来自于成千上万的小进步伟大来自于在很长一段时间内所做的成千上万也许是数百万的小进步变更。如果变更的效果都被测量是负面的那么变更将被回滚。谷歌也不是一天建成的。谷歌的搜索引擎是数百万个人改进的结果。搜索质量小组每周开会一次工程师们走上讲台提出他们的修改建议。他们展示了在模拟的环境中会有多大的改进委员会进行辩论并投票表决。几周后将对测量结果进行评审并决定保留或回滚更改。谷歌搜索是迭代开发战胜“数据大爆炸”思维的胜利。谁都不可能在一开始做出一个好的搜索引擎。只有在好莱坞电影中一个聪明的极客才会想出一个惊人的新点子并且第一次就能完美地实现它。在现实世界中一夜成名需要数年的时间。无论试图实现的目标是一个为客户提供更好服务的系统还是一个更高效、错误更少的系统还是一个运行更顺畅的系统都是如此。我们的工作是要求系统的设计能够容易拥抱新的变化并定义相关的KPI关键性能指标这些KPI可以在更改之前和之后方便地进行度量。最重要的是必须有一个流程来检查结果并决定保留或回滚变更。回滚不应被视为失败或受到惩罚。从每次回滚中学到的与在每次保留的更改中学到的一样有价值。托马斯·爱迪生声称在发明灯泡的过程中测试了1000根灯丝。当一位记者问他”失败1000次是什么感受“他回答说”我没有失败1000次。灯泡是一项有1000个步骤的发明。”12. 关于自己马上调整好你的身体姿势工作之外最好有其他业余爱好。虽然你是一名开发人员但也没必要全天候在写代码。善待每一个人保持冷静最重要的是要谦虚记住要经常休息不要把自己弄得筋疲力尽。购买一套好的工作站因为你大部分时间都在办公桌前度过尤其是在远程工作的日子里在高质量的产品上多花点钱是值得的。去了解不同的认知偏见这样不仅能帮助你做出更好的个人决定还能帮助你做出更好的技术决策。在职业生涯早期就开始投资了解复利的力量相信我它很神奇。同时不要过度储蓄如果你无法享受当下就算存了很多钱又有什么意义呢13. 关于人际关系人际交往能力和你的技术能力一样重要。有意识地锻炼指导他人、公共演讲、领导项目等方面的能力。开发者可以打破给人留下的“社交无能”的刻板印象。并不是每个人都有和你一样的动机。不要因为你对某个话题感兴趣就指望别人也会感兴趣。不同的人对不同的动机有不同的反应。不要用你的同事事实上是任何人不懂的东西来评判他们。学习如何推销自己。你可能对很多东西都很熟练但如果你没有在正确的平台上展示这些技能没有人会欣赏你。帮助你周围的人让他们变得更好。传授或分享你所学到的东西。教授或写一些你学过的东西这样会让你更好地理解它们。勇敢地说出“我不知道”。你可能很擅长撒谎但我们的大脑很善于识别某人是否在撒谎或假装。你的团队中始终会有一个顶级的开发人员他几乎可以解决任何问题。不要被他们的技术能力吓倒看看他们提交的 PR跟他们聊技术方面的东西并定期从他们那里获得反馈来提高自己。你很有可能会在工作中遇到你最好的朋友不要因此无法向他们敞开心扉要不要接受这个建议取决于你自己的判断。14. 关于沟通倾听不疲于倾听如果你在会议上没有什么想说的也没关系不要东拉西扯浪费别人的时间。在给别人发消息时不要只是发“你好”或“早上好”之类的问候然后等着他们回话。你要告诉他们你找他们有什么事没有人喜欢你这种毫无意义的问候或祝福。在向别人介绍你的设计时尽可能使用图表一图胜千言。在文档里使用图表也很有意义推荐工具 draw.io。向别人介绍某些设计或概念时少用行话。不是每个人都很熟悉技术术语在使用术语时要恰到好处。不要羞于去问一些你认为琐碎或愚蠢的问题。如果你想在几分钟内完成工作那就打电话。如果你想在几个小时内完成工作那就使用即时通讯工具。如果你不想完成工作那就发邮件2021 年人们还在使用邮件吗。当你向别人寻求帮助时不要只说“嘿这个有问题你能帮我吗”你要说“嘿我在运行程序 X 时出现了错误 Y我研究并尝试了解决方案 Z但它似乎也不行你能帮我解决这个问题吗”。在向别人寻求帮助之前先自己做一些调查不要因为代码中小小的拼写错误而浪费别人的时间说真的不要成为自行车棚效应避重就轻的牺牲品。在会议或讨论中重视复杂或关键的事项而不是琐碎的事项。15. 关于职业生涯如果你不喜欢自己做的事情没关系但如果你讨厌自己做的事情那就不能接受了。当你刚进入职场时优先考虑的是学习和发展的机会而不是薪水、福利等。在学习效率高的活动或工作上投入更多的时间。发展综合能力你必须及早开始。你工作的动力应该是为团队和项目增加价值而不是为了给别人留下好印象进而获得更高的薪水或晋升。如果前者做好了后者自然会光顾。花点时间写简历并让它保持最新。建议为自己做一个可以描述你的项目和经验的作品集网站。你的职位越高你要解决的问题就越抽象模糊。所以你要学会适应不确定性。每六个月问自己以下这些问题我是否在学习新的技能、拓宽自己的专业领域我是否对组织产生了影响从我的技能和经验来看我的薪水是否足够高如果你的答案都是否定的那么你必须考虑换公司或团队了。如果你在现在的公司已经工作了 2 至 3 年以上并且你的答案都是肯定的那么你应该考虑换公司或者至少要对换公司持开放态度。如果你仔细观察你会发现编程和写作非常相似。编程语言类似于人类语言程序员类似于作家和诗人。任何人都可以成为作家但要成为一名优秀的作家需要付出大量时间和努力。定期与经理进行一对一面谈并寻求反馈不要等到年终总结时才发现“惊喜”。如果你的经理没有为你的失败负责并责怪你那么在他们手下工作就是在拿你的个人和职业发展冒险。经验年限只是一个数字。有时候你会发现初级工程师比高级工程师对某些事情更熟悉。但请不要误解了我的意思经验教会你的不仅仅是技能。工作经验固然重要但这并不是评判一个工程师的唯一因素。16. 额外的建议记住帕累托法则 (80/20 法则)它几乎适用于软件工程的方方面面80% 的工作是由 20% 的工程师完成的80% 的影响是由 20% 的工作所带来的80% 的错误是由 20% 的代码造成的80% 的慢性能是由 20% 的代码造成的。我可以举出无数个例子对于那些在 StackOverflow 出现之前就开始写代码的开发人员我们是否应该给他们一点掌声StackOverflow 可以解决你 95% 的问题但千万别在上面问你的个人问题。Git 的提交消息应该具备足够好的描述这样你就可以从成千上万的代码提交中轻松搜索到你想要的。停止使用诸如“修复了一个 bug”、“改进了性能”、“修改了 X 模块”之类的描述。参考文献每个程序员和软件工程师应该知道的10件事 | 码农家园10 个角度分析软件工程师应该知道的 100 件事关于软件开发都应该知道的10个常识 - 知乎
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
