ARTS 打卡第二周

作者：直须

2023-08-25
广东
本文字数：11821 字
阅读完需：约 39 分钟

1、Algorithm 一道算法题

leetcode 242. 有效的字母异位词

给定两个字符串 s 和 t ，编写一个函数来判断 t 是否是 s 的字母异位词。

注意：若 s 和 t 中每个字符出现的次数都相同，则称 s 和 t 互为字母异位词。

示例 1:输入: s = "anagram", t = "nagaram"输出: true
示例 2:输入: s = "rat", t = "car"输出: false

复制代码

看到次数相同，那就是用 map了。

先判断两个字符串长度是否一致，不一致那就返回false。
再用两个对象分别存储两个字符串的每个字母出现的次数，最后对比每个字母的次数是否一致。

var isAnagram = function (s, t) {  // 先判断两个字符串长度是否一致  if (s.length !== t.length) {    return false;  }  // 用两个对象分别存储两个字符串的每个字母出现的次数  const obj = {}  const obj2 = {}
  for (let a = 0; a < s.length; a++) {    obj[s[a]] = (obj[s[a]] || 0) + 1    obj2[t[a]] = (obj2[t[a]] || 0) + 1  }  // 对比两个对象中每个字母出现的次数是否一致  for (let c in obj) {    if(obj[c] !== obj2[c]) return false  }  return true};

复制代码

2、Review 读一篇英文文章

20 Things I’ve Learned in my 20 Years as a Software Engineer

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

原文链接：https://www.simplethread.com/20-things-ive-learned-in-my-20-years-as-a-software-engineer/

Important, Read This First

重要提示，请先阅读此内容

You’re about to read a blog post with a lot of advice. Learning from those who came before us is instrumental to success, but we often forget an important caveat. Almost all advice is contextual, yet it is rarely delivered with any context.

你即将读到一篇博客文章，里面有很多建议。向我们之前的人学习有助于取得成功，但我们经常忘记一个重要的警告。大多数建议是有前后关系的，但很少提供任何上下文。

(be about to 即将)

“You just need to charge more!” says the company who has been in business for 20 years and spent years charging “too little” to gain customers and become successful.

"你只是需要收取更多的费用！" 这家经营了 20 年的公司表示，数年来，为了获客和成功交易，收取的费用“太少”。

“You need to build everything as microservices!” says the company who built a quick monolith, gained thousands of customers, and then pivoted into microservices as they started running into scaling issues.

"你需要把一切东西都构建成微服务！"这家公司表示，他们构建了一个快速的巨型应用的，获得了成千上万的客户，然后在开始遇到扩展问题时转向了微服务。

(running into 遇到)

Without understanding the context, the advice is meaningless, or even worse, harmful. If those folks had followed their own advice early on, they themselves would likely have suffered from it. It is hard to escape this trap. We may be the culmination of our experiences, but we view them through the lens of the present.

没有解理上下文，那建议就是无意义，甚至是错误的，有害的。如果那些人早点听从自己的建议，他们自己可能会受到影响。难以逃脱这个陷井。我们可能在我们经验的顶点，但是我们是通过现在的视角来看待它们的。

So to give you a little context on where my advice comes from, I spent the first half of my career as a software engineer working for various small businesses and startups, then I went into consulting and worked in a number of really large businesses. Then I started Simple Thread and we grew from a team of 2 to a team of 25. 10 years ago we worked with mostly small/medium businesses, and now we work with a mix of big and small businesses.

所以给你一点上下文作为我建议的来源，因为我职业生涯的前半段是一名软件工程师，在各种小企业和初创公司工作，后来我从事咨询，在许多大公司工作。然后我创办了 Simple Thread，我们从 2 人团队成长到 25 人团队。

10 年前我们主要和中小型公司合作，现在我们和大公司和小公司合作。

My advice is from someone who…

我的建议来自于：

has almost always been on small, lean teams where we have to do a lot with very little.
values working software over specific tools.
is starting new projects all the time, but also has to maintain a number of systems.
values engineer productivity over most other considerations

1.总是在小型、精简的团队中，我们必须用很少的东西做很多事情。(have to do 必须，不得不)

2.重视工作软件而非特定工具。

3.一直在开始新项目，但同时也在维护许多系统。

4.重视工程师的生产力而非其它大多数的顾虑。

My experiences over the last 20 years have shaped how I view software, and have led me to some beliefs which I’ve tried to whittle down to a manageable list that I hope you find valuable.

我过去 20 年的经历塑造了我对软件的看法，并引导我得出一些信念，我试图将这些信念缩减为一个可管理的列表，我希望你觉得有价值。

1. I still don’t know very much

1. 我还是不太了解

“How can you not know what BGP is?” “You’ve never heard of Rust?” Most of us have heard these kinds of statements, probably too often. The reason many of us love software is because we are lifelong learners, and in software no matter which direction you look, there are wide vistas of knowledge going off in every direction and expanding by the day. This means that you can spend decades in your career, and still have a huge knowledge gap compared to someone who has also spent decades in a seemingly similar role. The sooner you realize this, the sooner you can start to shed your imposter syndrome and instead delight in learning from and teaching others.

”你怎么可能不知道什么是 BGP？“ “你从来没听说过 Rust？” 我们大多数人可能都听过这样的话，也许听得太多了。我们许多人喜欢软件的原因是因为我们是终身学习者，在软件中，无论你看哪个方向，都有广阔的知识向各个方向发展，并且每天都在发展。这意味着，即使在你的职业生涯中，你已经度过了几十年，与那些也在一个看似相似的职位上度过了几十年的人相比，你仍然有巨大的知识差距。你越早意识到这一点，你就越能开始摆脱自我怀疑，而是从学习和教导他人中获得乐趣。

2. The hardest part of software is building the right thing

2. 软件中最困难的部分就是构建正确的东西

I know this is cliche at this point, but the reason most software engineers don’t believe it is because they think it devalues their work. Personally I think that is nonsense. Instead it highlights the complexity and irrationality of the environments in which we have to work, which compounds our challenges. You can design the most technically impressive thing in the world, and then have nobody want to use it. Happens all the time. Designing software is mostly a listening activity, and we often have to be part software engineer, part psychic, and part anthropologist. Investing in this design process, whether through dedicated UX team members or by simply educating yourself, will deliver enormous dividends. Because how do you really calculate the cost of building the wrong software? It amounts to a lot more than just lost engineering time.

我知道这是一种陈词滥调，但大多数软件工程师不相信它的原因是他们认为这贬值了他们的工作。个人认为这是无稽之谈。相反，它凸显了我们必须在复杂且不合理的环境中工作的挑战。你可以设计出世界上技术上最令人印象深刻的东西，但却没有人想使用它。这种情况经常发生。设计软件主要是一项倾听活动，我们通常必须是软件工程师、心理学家和人类学家的一部分。通过投资设计过程，无论是通过专门的用户体验团队成员还是通过自我教育，都将带来巨大的回报。因为你如何真正计算建造错误软件的成本？这远远不止是失去工程时间的问题

3. The best software engineers think like designers

3. 最好的软件工程师像设计师一样思考

Great software engineers think deeply about the user experience of their code. They might not think about it in those terms, but whether it is an external API, programmatic API, user interface, protocol, or any other interface; great engineers consider who will be using it, why it will be used, how it will be used, and what is important to those users. Keeping the user’s needs in mind is really the heart of good user experience.

优秀的软件工程师深入思考其代码的用户体验。他们可能不会用这些术语来思考，但无论是外部 API、编程 API、用户界面、协议还是其他任何接口，优秀的工程师都会考虑谁将使用它、为什么使用它、如何使用它以及对这些用户来说什么是重要的。牢记用户的需求实际上是良好用户体验的核心。

4. The best code is no code, or code you don’t have to maintain

4. 最好的代码是没有代码，或者是你不需要维护的代码

All I have to say is “coders gonna code.” You ask someone in any profession how to solve a problem, and they are going to err on the side of what they are good at. It is just human nature. Most software engineers are always going to err on the side of writing code, especially when a non-technical solution isn’t obvious. The same goes for code you don’t have to maintain. Engineering teams are apt to want to reinvent the wheel, when lots of wheels already exist. This is a balancing act, there are lots of reasons to grow your own, but beware of toxic “Not Invented Here” syndrome.

我只想说“码农就是要写代码”。你问任何一个职业的人如何解决问题，他们都会偏向于自己擅长的领域。这是人类的本性。大多数软件工程师在写代码时总是会倾向于写代码，特别是在非技术解决方案不明显的情况下。对于不需要维护的代码也是如此。工程团队往往希望重新发明轮子，即使已经存在很多轮子。这是一个平衡的问题，有很多理由要自己开发，但要小心“非本土发明”综合症的毒害。

5. Software is a means to an end

5. 软件是达成目标的手段

The primary job of any software engineer is delivering value. Very few software developers understand this, even fewer internalize it. Truly internalizing this leads to a different way of solving problems, and a different way of viewing your tools. If you really believe that software is subservient to the outcome, you’ll be ready to really find “the right tool for the job” which might not be software at all.

任何软件工程师的主要工作是提供价值。很少有软件开发者能够理解这一点，更少的人能够内化它。真正内化这一点会导致一种不同的解决问题的方式，以及一种不同的看待你的工具的方式。如果你真的相信软件是为结果服务的，你就会准备好找到“最适合任务的工具”，这可能根本不是软件。

6. Sometimes you have to stop sharpening the saw, and just start cutting shit

6. 有时候你需要停止磨刀，开始动手做事

Some people tend to jump into problems and just start writing code. Other people tend to want to research and research and get caught in analysis paralysis. In those cases, set a deadline for yourself and just start exploring solutions. You’ll quickly learn more as you start solving the problem, and that will lead you to iterate into a better solution.

有些人倾向于直接开始编写代码解决问题。其他人则倾向于进行研究和分析，陷入分析麻痹症。在这种情况下，为自己设定一个最后期限，开始探索解决方案。随着你开始解决问题，你会很快学到更多，这将带领你不断迭代出更好的解决方案。

7. If you don’t have a good grasp of the universe of what’s possible, you can’t design a good system

7. 如果你对可能发生的事情没有很好的掌握，你就无法设计好的系统

This is something I struggle with a lot as my responsibilities take me further and further from the day to day of software engineering. Keeping up with the developer ecosystem is a huge amount of work, but it is critical to understand what is possible. If you don’t understand what is possible and what is available in a given ecosystem then you’ll find it impossible to design a reasonable solution to all but the most simple of problems. To summarize, be wary of people designing systems who haven’t written any code in a long time.

随着我的职责越来越远离日常软件工程，我经常会遇到这样的困境。跟进开发者生态系统需要大量的工作，但了解可能性是至关重要的。如果你不了解某个生态系统中可能发生的事情和可用的资源，那么你将很难设计出合理的解决方案，除非是最简单的问题。总之，要警惕那些长时间没有编写代码的人设计系统。

8. Every system eventually sucks, get over it

8. 每个系统最终都会变得糟糕，要接受这个事实

Bjarne Stroustrup has a quote that goes “There are only two kinds of languages: the ones people complain about and the ones nobody uses”. This can be extended to large systems as well. There is no “right” architecture, you’ll never pay down all of your technical debt, you’ll never design the perfect interface, your tests will always be too slow. This isn’t an excuse to never make things better, but instead a way to give you perspective. Worry less about elegance and perfection; instead strive for continuous improvement and creating a livable system that your team enjoys working in and sustainably delivers value.

Bjarne Stroustrup 说过一句话：“只有两种语言：那些人们抱怨的语言和那些没有人使用的语言。”这也可以扩展到大型系统上。没有“正确”的架构，你永远无法偿清所有技术债务，你永远无法设计出完美的界面，你的测试总是太慢。这不是不改进的借口，而是一种给你带来透视的方式。不要太担心优雅和完美；相反，应该追求不断改进，创造一个可居住的系统，使你的团队喜欢工作，并持续提供价值。

9. Nobody asks “why” enough

没有人问“为什么”足够多

Take any opportunity to question assumptions and approaches that are “the way things have always been done”. Have a new team member coming on board? Pay attention to where they get confused and what questions they ask. Have a new feature request that doesn’t make sense? Make sure you understand the goal and what is driving the desire for this functionality. If you don’t get a clear answer, keep asking why until you understand.

任何机会都应该质疑那些“一直以来都是这样做”的假设和方法。有新团队成员加入吗？注意他们在哪里感到困惑，以及他们会问什么问题。有一个新的功能请求不合理吗？确保你理解目标和驱动这种功能需求的原因。如果你没有得到明确的答案，就一直问“为什么”，直到你理解为止。

10. We should be far more focused on avoiding 0.1x programmers than finding 10x programmers

我们应该更专注于避免 0.1x 程序员，而不是寻找 10x 程序员

The 10x programmer is a silly myth. The idea that someone can produce in 1 day what another competent, hard working, similarly experienced programmer can produce in 2 weeks is silly. I’ve seen programmers that sling 10x the amount of code, and then you have to fix it 10x the amount of times. The only way someone can be a 10x programmer is if you compare them to 0.1x programmers. Someone who wastes time, doesn’t ask for feedback, doesn’t test their code, doesn’t consider edge cases, etc… We should be far more concerned with keeping 0.1x programmers off our teams than finding the mythical 10x programmer.

10x 程序员是一个愚蠢的神话。有人在 1 天内完成的工作，另一个有能力、勤奋、经验相似的程序员需要 2 周才能完成，这种想法是愚蠢的。我见过一些程序员，他们写的代码量是另一个程序员的 10 倍，但你还需要花费 10 倍的时间来修复它们。有人成为 10x 程序员的唯一方式是将他们与 0.1x 程序员进行比较。那些浪费时间、不寻求反馈、不测试代码、不考虑边缘情况等的人...我们应该更关注如何避免 0.1x 程序员加入我们的团队，而不是寻找神话般的 10x 程序员。

11. One of the biggest differences between a senior engineer and a junior engineer is that they’ve formed opinions about the way things should be

资深工程师和初级工程师之间最大的区别之一是他们对事情应该被如何完成形成了观点

Nothing worries me more than a senior engineer that has no opinion of their tools or how to approach building software. I’d rather someone give me opinions that I violently disagree with than for them to have no opinions at all. If you are using your tools, and you don’t love or hate them in a myriad of ways, you need to experience more. You need to explore other languages, libraries, and paradigms. There are few ways of leveling up your skills faster than actively seeking out how others accomplish tasks with different tools and techniques than you do.

没有什么比一个资深工程师没有对自己的工具或如何构建软件的方法表达任何观点更令我担忧。与其说他们没有任何观点，我宁愿他们给我提出我强烈反对的意见。如果你使用工具，你不喜欢或讨厌它们的多种方式，你需要经历更多。你需要探索其他语言、库和范例。很少有哪种方法能比积极寻找其他人用不同的工具和技术完成任务的方法更快地提高你的技能。

12. People don’t really want innovation

人们并不真正想要创新

People talk about innovation a whole lot, but what they are usually looking for is cheap wins and novelty. If you truly innovate, and change the way that people have to do things, expect mostly negative feedback. If you believe in what you’re doing, and know it will really improve things, then brace yourself for a long battle.

人们经常谈论创新，但他们通常在寻找的是便宜的胜利和新奇。如果你真正创新，并改变了人们必须做事情的方式，那么请预计大部分是负面的反馈。如果你相信你正在做的事情，并知道它会真正改善事情，那么你要为漫长的斗争做好准备。

13. Your data is the most important part of your system

你的数据是系统中最重要的部分

I’ve seen a lot of systems where hope was the primary mechanism of data integrity. In systems like this, anything that happens off the golden path creates partial or dirty data. Dealing with this data in the future can become a nightmare. Just remember, your data will likely long outlive your codebase. Spend energy keeping it orderly and clean, it’ll pay off well in the long run.

我见过很多系统，其中希望是数据完整性的主要机制。在这样的系统中，任何违反最佳路径的事情都会创建部分或脏数据。在未来处理这些数据可能会变成噩梦。记住，你的数据可能会比你的代码库更长久。花费精力使其有序和清洁，长期来看会得到很好的回报。

14. Look for technological sharks

寻找技术上的鲨鱼

Old technologies that have stuck around are sharks, not dinosaurs. They solve problems so well that they have survived the rapid changes that occur constantly in the technology world. Don’t bet against these technologies, and replace them only if you have a very good reason. These tools won’t be flashy, and they won’t be exciting, but they will get the job done without a lot of sleepless nights.

那些一直存在的旧技术是鲨鱼，而不是恐龙。它们解决问题非常好，因此在技术世界中不断发生的快速变化中得以生存。不要押注这些技术，并且只有在你有非常好的理由时才替换它们。这些工具不会很炫目，也不会很令人兴奋，但是它们可以在不引起太多不眠之夜的情况下完成工作。

15. Don’t mistake humility for ignorance

不要把谦虚误认为无知

There are a lot of software engineers out there who won’t express opinions unless asked. Never assume that just because someone isn’t throwing their opinions in your face that they don’t have anything to add. Sometimes the noisiest people are the ones we want to listen to the least. Talk to the people around you, seek their feedback and advice. You’ll be glad you did.

有很多软件工程师不会在没有被问到的情况下表达意见。不要假设仅因为某人没有在你面前表达意见，就认为他们没有任何添加的东西。有时候最吵闹的人是我们最不想听的人。与身边的人交流，寻求他们的反馈和建议。你会很高兴你这样做的。

16. Software engineers should write regularly

软件工程师应该定期写作

Software engineers should regularly blog, journal, write documentation and in general do anything that requires them to keep their written communication skills sharp. Writing helps you think about your problems, and helps you communicate those more effectively with your team and your future self. Good written communication is one of the most important skills for any software engineer to master.

软件工程师应该经常写博客、日记、撰写文档，总之做任何需要他们保持写作沟通技巧的事情。写作有助于你思考问题，并帮助你更有效地与团队和未来的自己沟通。良好的书面沟通是任何软件工程师掌握的最重要的技能之一。

17. Keep your processes as lean as possible

保持你的流程尽可能精简

Everyone wants to be agile these days, but being “agile” is about building things in small chunks, learning, and then iterating. If someone is trying to shoehorn much more into it than that, then they’re probably selling something. It isn’t to say that people don’t need accountability or help to work this way, but how many times have you heard someone from your favorite tech company or large open source project brag about how great their Scrum process is? Stay lean on process until you know you need more. Trust your team and they will deliver.

现在每个人都想成为“敏捷”，但“敏捷”是关于分阶段构建事物、学习，然后迭代的过程。如果有人试图把更多的东西塞进去，那么他们可能在推销某些东西。这并不是说人们不需要责任或帮助以这种方式工作，但你有多少次听到你最喜欢的科技公司或大型开源项目的人吹嘘他们的 Scrum 流程有多么好？在你知道需要更多之前，保持流程的精简。相信你的团队，他们会交付。

18. Software engineers, like all humans, need to feel ownership

软件工程师，像所有人一样，需要感到有所有权

If you divorce someone from the output of their work, they will care less about their work. I see this almost as a tautology. This is the primary reason why cross-functional teams work so well, and why DevOps has become so popular. It isn’t all about handoffs and inefficiencies, it is about owning the whole process from start to finish, and being directly responsible for delivering value. Give a group of passionate people complete ownership over designing, building, and delivering a piece of software (or anything really) and amazing things will happen.

如果你让一个人与他们的工作成果分离，他们就会对他们的工作不那么在意。我几乎认为这是一个重言。这是跨职能团队运作得如此出色的主要原因，也是为什么 DevOps 变得如此流行的原因。这不完全是关于交接和低效率，而是关于从头开始拥有整个流程，并直接负责交付价值。让一群充满热情的人完全拥有设计、构建和交付软件（或任何东西）的所有权，神奇的事情就会发生。

19. Interviews are almost worthless for telling how good of a team member someone will be

19. 面试几乎没有用于判断某个人是否是好的团队成员

Interviews are far better spent trying to understand who someone is, and how interested they are in a given field of expertise. Trying to suss out how good of a team member they will be is a fruitless endeavor. And believe me, how smart or knowledgable someone is is also not a good indicator that they will be a great team member. No one is going to tell you in an interview that they are going to be unreliable, abusive, pompous, or never show up to meetings on time. People might claim they have “signals” for these things… “if they ask about time off in the first interview then they are never going to be there!” But these are all bullshit. If you’re using signals like these you’re just guessing and turning away good candidates.

面试更好地用于尝试了解某个人是谁，以及他们在某个专业领域的兴趣程度。试图找出某个人是否是一个好的团队成员是徒劳的。相信我，某个人有多聪明或有多少知识并不是衡量他们是否是优秀的团队成员的好指标。没有人会在面试中告诉你他们将会不可靠、滥用、自大或从不准时参加会议。人们可能声称他们有“信号”来判断这些事情...“如果他们在第一次面试中询问了假期时间，那么他们永远不会来！”但这些都是骗人的。如果你使用这些信号，你只是在猜测并拒绝好的候选人。

20. Always strive to build a smaller system

20. 始终努力构建更小的系统

There are a lot of forces that will push you to build the bigger system up-front. Budget allocation, the inability to decide which features should be cut, the desire to deliver the “best version” of a system. All of these things push us very forcefully towards building too much. You should fight this. You learn so much as you’re building a system that you will end up iterating into a much better system than you ever could have designed in the first place. This is surprisingly a hard sell to most people.

有很多力量会推动你一开始就构建更大的系统。预算分配、无法决定哪些功能应该被削减、希望交付系统的“最佳版本”。所有这些事情都强烈地推动我们去建造太多的东西。你应该抵制这种情况。你在构建系统的过程中学到的东西是如此之多，以至于你最终会将其迭代成一个比你一开始设计的系统更好的系统。这很难向大多数人推销。