目录： (Table of contents:)

#1 Think before coding#2 Understand the business behind every project#3 Find someone with a different coding style and discuss with them#4 Don’t get religious#5 Learn and read on a regular basis#6 Dig deeper for more knowledge#7 Participate in forums, teach, share knowledge#8 Be willing to rewrite your own code when you learn something new#9 Combine ideas#10 Write good names and make comments#11 Learn more languages#12 Test#13 Design patterns#14 Separation of Concerns#15 Minimize the use of “and” when describing parts of your code#16 Do Not Repeat Yourself#17 Tell, don’t Ask#18 Open — Closed principle (OCP)#19 Short functions#20 Frameworks

＃1 编码前先思考 ＃2 了解每个项目背后的业务 ＃3 寻找具有不同编码风格的人并与他们讨论 ＃4 不要虔诚 ＃5 定期学习和阅读 ＃6 深入挖掘以获得更多知识 ＃ 7 参加论坛，教授，分享知识 ＃8 学习新 知识时 愿意重写自己的代码 ＃9 结合想法 ＃10 写好名字并发表评论 ＃11 了解更多语言 ＃12 测试 ＃13 设计模式 ＃14 分离关注的问题 ＃15 在描述代码的某些部分时尽量减少使用“和” ＃16 不要重复自己 ＃17 告诉，不要问 ＃18 开放-封闭原则(OCP) ＃19 短函数 ＃20 框架

Being a developer is a fantastic career, full of great challenges and puzzle solving that keep us awake at night. As developers of any skill level are in high demand and tend to be far too busy, they often don’t have enough time to stop and think about their own work.

成为开发人员是一个了不起的职业，充满了巨大的挑战和难题的解决方案，使我们彻夜难眠。 由于各种技能水平的开发人员都需求很高，并且往往太忙了，因此他们通常没有足够的时间停下来思考自己的工作。

Technology is advancing at an unbelievable rate, and we are required to keep up. However, many developers don’t want to. They learned something years ago and continue to use the same bad practice to this day. Well, if a programmer repeats the same old (often incorrect) concept over and over, even ten years of experience doesn’t help them become a better coder. On the other hand, studying can skyrocket your knowledge and skills towards programming in any language.

技术正在以令人难以置信的速度发展，我们必须跟上发展的步伐。 但是，许多开发人员都不想这样做。 他们几年前学到了一些东西，直到今天仍在使用同样的坏习惯。 好吧，如果程序员一遍又一遍地重复相同的旧概念(通常是错误的)，那么即使十年的经验也无法帮助他们成为更好的编码器。 另一方面，学习可以使您的知识和技能Swift发展为使用任何语言进行编程。

Experience built on knowledge increases much quicker and is more valuable.

建立在知识上的经验增长更快，更有价值 。

I would like to share 20 tips with you that will boost your coding skills immediately. If you are a beginner, pick a few, and study the particular topic further. It will be one of the best investments into your own career. Knowledge without experience is not very useful, and experience without knowledge can quite easily create a mess.

我想与您分享20条技巧，这些技巧将立即提高您的编码技能。 如果您是初学者，请选择一些，然后进一步研究特定主题。 这将是您职业生涯中最好的投资之一。 没有经验的知识不是很有用，没有知识的经验很容易造成混乱。

＃1编码前先思考 (#1 Think before coding)

Writing lines of code should not cover 100% of your development time. 50–60% is more than enough. I have seen many programmers writing faster than they’re even capable of thinking. Humans are not well-suited to multitasking. Take one step at a time, and think before taking it.

编写代码行不应占用您100％的开发时间。 50-60％绰绰有余。 我已经看到许多程序员的写作速度甚至超过了他们的思维能力。 人类不适合多任务处理。 一次迈出一步，然后再思考。

Tips:

温馨提示 ：

• Put a piece of paper close to your keyboard. Draw graphs, concepts, images, tables. Any kind of silly visualization may be helpful. If you have a drawing board in front of you, even better.
  在您的键盘附近放一张纸。 绘制图形，概念，图像，表格。 任何一种愚蠢的可视化可能会有所帮助。 如果您面前有画板，那就更好了。
• Think first, then put your ideas on paper. Writing code after you know what you want to achieve is much more effective.
  首先思考，然后将您的想法写在纸上。 在知道要实现的目标之后编写代码会更加有效。
• Starting with writing code right away may seem like super-effective development, but it’s not. That is just a delusion. You may actually catch yourself going back and forth, up and down within your code, continually making changes to the previous lines.
  立即开始编写代码似乎是非常有效的开发，但事实并非如此。 那只是个妄想。 您实际上可能会在代码中来回移动，不断对前几行进行更改。

• Divide and conquer. Every problem seems complicated at the beginning. Do not panic. Think about splitting your code into smaller parts. There are several possible approaches for how to do this.

  分而治之 。 一开始每个问题似乎都很复杂。 不要恐慌。 考虑将代码分成较小的部分。 有几种方法可以做到这一点。

• Think about testing before you write code. It may be very helpful to have a clear idea about how a tester or a product owner would know that the task has been completed. Too vague goals are terrible and ultimately lead to much longer development time than was expected. Do not forget that this issue can get costly!
  在编写代码之前，请考虑一下测试。 对测试人员或产品所有者如何知道任务已完成有一个清晰的想法可能会很有帮助。 过于模糊的目标是可怕的，最终导致开发时间比预期的要长得多。 不要忘了这个问题可能会造成巨大的损失！

＃2了解每个项目背后的业务 (#2 Understand the business behind every project)

It might not seem like a programming thing, but trust me, business is essential. It pays your salary. It may be fun to code in some crazy way for just yourself. However, we all need to make a living. Therefore, our code must follow some business goals.

看起来似乎不是编程的事情，但请相信我，业务必不可少。 它支付您的薪水。 以某种疯狂的方式为自己编写代码可能会很有趣。 但是，我们都需要谋生。 因此，我们的代码必须遵循一些业务目标。

Many people, including managers and marketers, make fun of programmers, perceiving them as weirdos and geeks who live in their own world of ones and zeros. While it’s totally fine to dive into your lines of code, it’s also extremely useful to raise your head every once in a while and look outside of what you’re doing and why.

许多人，包括管理人员和营销人员，都在嘲笑程序员，将他们视为生活在自己的零世界中的怪胎和怪胎。 尽管深入研究代码行是完全可以的，但偶尔抬起头来看看正在做的事情和原因之外，这也非常有用。

There is always a client with their needs, budgets, business concepts, and expectations. If a programmer understands the big picture, he or she may be useful for solving future problems the client may not have thought about before.

总会有客户满足他们的需求，预算，业务概念和期望。 如果程序员了解全局，那么他或她对于解决客户以前可能没有想到的未来问题可能会很有用。

＃3找到完全不同的编码风格的人并与他们讨论 (#3 Find someone with a completely different coding style and discuss with them)

When people do something, no matter how silly it looks to us, they always have a reason for it. It is true that the reason might be flawed in the first place, but expect that others have put thought into what they do.They most likely know something you don’t and can learn from.

当人们做某事时，无论它看起来多么愚蠢，他们总是有理由这么做。 诚然，原因可能是有缺陷的，但希望其他人已经思考了自己的所作所为，他们很可能知道您不了解的东西并可以从中学到东西。

Some developers prefer object-oriented programming, others fight for the functional style, or a combination of the two. Each group is able to list plenty of benefits of their style and can defend why they decided to use it. OOP has many great concepts that I am a huge fan of. However, functional programming is built on principles that can make even OOP architecture more robust and easier to read. Avoiding changing state is a concept that makes more predictable behavior of methods and classes, and also makes unit testing easier and more reliable.

一些开发人员更喜欢面向对象的编程，另一些开发人员则更喜欢功能风格，或者两者兼而有之。 每个小组都可以列出自己风格的许多好处，并可以辩护为什么决定使用它。 OOP有很多很棒的概念，我非常喜欢。 但是，函数式编程是建立在可以使OOP体系结构更健壮和更易于阅读的原理上的。 避免更改状态是一个使方法和类的行为更具可预测性的概念，并且使单元测试更容易，更可靠。

Being able to listen to others as well as defend your own ideas are both extremely valuable skills. Don’t underestimate them!

能够倾听他人的意见并捍卫自己的想法都是极为宝贵的技能。 别小看他们！

＃4不要信教 (#4 Don’t get religious)

Way too often we can read tech articles praising one specific technology, and claiming others are crappy. It goes on and on — relational databases vs. noSQL, OOP vs. functional programming, Laravel vs. Symfony vs Nette, VueJs vs. React vs. Angular, Nginx vs. Apache, etc. etc.

我们经常阅读支持某项特定技术的技术文章，却声称其他技术糟透了。 它不断地进行着—关系数据库与noSQL，OOP与函数式编程，Laravel与Symfony与Nette，VueJs与React与Angular，Nginx与Apache等等等。

I don’t find these little wars to be particularly useful, and they do nothing more than confuse new developers. Searching for objective information and valid comparisons can truly be a difficult task, especially since not every tool is useful in the same situation. Tech decisions should always emphasize business goals.

我认为这些小小的战争没有什么特别的用处，它们只会使新开发人员感到困惑。 搜索客观信息和有效比较确实是一项艰巨的任务，特别是因为并非每种工具在相同情况下都有用。 技术决策应始终强调业务目标。

No matter what technology we use and like, let’s remain open to new ideas.

无论我们使用和喜欢什么技术，我们都对新想法持开放态度。

＃5定期学习和阅读 (#5 Learn and read on a regular basis)

Technology is the most dynamic area of the modern world. We, the developers, need to keep up with the times, at least to some extent. Our knowledge gets older every day, and we need to learn new stuff. When it comes to new hardware, server technology, the cloud, programming languages or frameworks, testing tools, and others, we should maintain at least a general knowledge of where the tech world is heading.

技术是现代世界中最具活力的领域。 我们，开发人员，至少在某种程度上需要与时俱进。 我们的知识每天都在变老，我们需要学习新知识。 当涉及到新的硬件，服务器技术，云，编程语言或框架，测试工具等时，我们至少应保持对技术领域发展的一般了解。

Learning new stuff is extremely easy nowadays. You can find plenty of free materials on YouTube. Paid channels such as lynda.com, udemy.com, or laracast.com (for Lavarel framework) cost surprisingly little compared to the value you get. Dozens of hours of learning material for a $10- 15/course is simply amazing. If you need to learn something new, you have no excuse for not doing it. Whatever you need is somewhere online. It may be challenging to plunge ourselves into the state of “not knowing”. The more experienced we are in one domain, the less we want to move in another direction. However, this is an essential part of personal growth and self-development.

如今，学习新东西非常容易。 您可以在YouTube上找到许多免费的资料。 与您所获得的价值相比，诸如lynda.com，udemy.com或laracast.com(适用于Lavarel框架)等付费频道的费用出奇地少。 每门课程10至15美元的数十小时的学习材料简直令人称奇。 如果您需要学习新知识，则没有理由不这样做。 无论您需要什么，都可以在网上找到。 让自己陷入“不知道”的状态可能具有挑战性。 我们在一个领域中越有经验，就越不希望朝另一个方向发展。 但是，这是个人成长和自我发展的重要组成部分。

Medium.com is also a great source of information. Devote at least 1–2 hours a week to reading. Split your reading into two parts — things you already know and would like to learn more about and things you’re not familiar with at all, but wish to learn. Plus, you might find it fun to build knowledge in areas completely outside the tech world. I personally like physics, astronomy, and economics.

Medium.com还是一个很好的信息来源。 每周至少花1-2个小时阅读。 将您的阅读分为两个部分-您已经知道并且想了解更多的东西，以及您根本不熟悉但希望学习的东西。 另外，您可能会发现在完全不在技术领域的领域中积累知识很有趣。 我个人喜欢物理学，天文学和经济学。

＃6深入挖掘以获得更多知识 (#6 Dig deeper for more knowledge)

Great developers also set themselves apart from average ones in their knowledge of the underlying technology. Sure, coding in React or VueJs doesn’t require any understanding of IP addresses, routing or DNS systems. Yet, the more we know, the more difficult problems we are able to solve.

优秀的开发人员在底层技术方面的知识也使他们与普通人区分开。 当然，在React或VueJs中编码不需要对IP地址，路由或DNS系统有任何了解。 但是，我们知道的越多，我们解决的难题就越困难。

I personally love learning new stuff very much. I want to understand technology as deeply as I can. You don’t have to be like me, but some knowledge of the underlying technology is always an advantage. Great developers don’t recreate the wheel. Use open-source assets in the wild. Open-source materials have surged greatly in the past 10 years.

我个人非常喜欢学习新知识。 我想尽可能深入地了解技术。 您不必像我一样，但是对底层技术的一些了解永远是一个优势。 优秀的开发人员不会重蹈覆辙。 在野外使用开源资产。 在过去的十年中，开放源材料激增。

Here are a few tips you may find both interesting and useful in advancing your career. Plus, you’ll increase your ability to solve more complex problems.

这里有一些技巧，您可能会发现它们对您的职业发展既有趣又有用。 此外，您将增强解决更复杂问题的能力。

• Learn about computers to their core. Have a look at small processors and how they handle data. What Assembler looks like, and how C or C++ commands can be compiled to Assembler. There are many good resources explaining computers at their core level. You’ll find one such YouTube channel here.

  了解有关计算机的核心知识。 看一下小型处理器及其处理数据的方式。 汇编程序的外观以及如何将C或C ++命令编译为汇编程序。 有很多很好的资源可以解释计算机的核心水平。 您会在这里找到一个这样的YouTube频道。

• If you’re a web developer, you should definitely learn how data is stored and how it travels across the globe. The physical layer, data layer, network layer, etc. This is called the OSI model, sources: 1 or 2.

  如果您是网络开发人员，则一定应该了解数据的存储方式以及如何在全球范围内传输。 物理层，数据层，网络层等。这称为OSI模型 ，来源： 1或2 。

• Web developers should be familiar with a client-server architecture. Names such as Apache, Nginx, IIS, Postfix, Node, Composer should sound familiar.
  Web开发人员应该熟悉客户端-服务器体系结构。 诸如Apache，Nginx，IIS，Postfix，Node，Composer之类的名称听起来应该很熟悉。
• The cloud is a big deal today. Azure and AWS are extremely complex tools. I don’t think you have to be an expert on these cloud technologies, but at least have a look at what they can do. As a web developer, you will definitely communicate with a team taking care of the hosting stuff. It’s always beneficial to be able to understand each other and be aware of what issues might arise.
  今天，云计算已成为大问题。 Azure和AWS是极其复杂的工具。 我认为您不必成为这些云技术的专家，但至少可以看看它们可以做什么。 作为Web开发人员，您一定会与负责托管事务的团队进行沟通。 能够相互了解并知道可能会出现什么问题总是有益的。

• Even if you’re not a big Linux fan, like me, learn at least some basic commands. Linux is widely used for web servers, and you most likely won’t be able to avoid it. Command-line doesn’t look friendly to everyone, but some basic knowledge is more than necessary. When you get used to it, it will feel more natural, and your effectiveness will go up.

  即使您不是像我这样的Linux狂热者，也至少要学习一些基本命令。 Linux被广泛用于Web服务器，您很可能无法避免使用它。 命令行对每个人看起来并不友好，但是一些基本知识是不必要的。 当您习惯了它之后，它将感觉更自然，并且您的效率将会提高。

＃7参加论坛，教授，分享知识 (#7 Participate in forums, teach, share knowledge)

When you reach a higher level of experience and knowledge, it may be good to share a part of it. We developed our knowledge using many free resources, provided by people who were willing to share their experience and spent a lot of time on their craft. Giving back to the community should be a part of a developers’ job description.

当您获得更高水平的经验和知识时，最好分享其中的一部分。 我们使用许多免费资源开发知识，这些资源由愿意分享经验并花大量时间从事Craft.io的人们提供。 回馈社区应该是开发人员工作说明的一部分 。

There is stackoverflow.com where you can help people solve their issues. Every developer probably uses the accumulated knowledge provided by this portal, so it’s great to lend a hand from time to time.

在stackoverflow.com上，您可以在其中帮助人们解决他们的问题。 每个开发人员都可能使用此门户提供的累积知识，因此不时伸出援助之手非常重要。

Teaching creates an opportunity not only to deepen our knowledge, but also to articulate it better. Being able to describe what we want and explain solutions is essential for team leading and communicating with clients. Practice is key. Writing articles (e.g. here on medium) or shooting short educational videos are great ways of sharing knowledge and learning together.

教学不仅为加深我们的知识创造了机会，而且还可以更好地表达它。 能够描述我们想要什么并解释解决方案对于团队领导和与客户沟通至关重要。 练习是关键。 撰写文章(例如，此处为媒体)或拍摄简短的教育视频是共享知识和共同学习的好方法。

＃8在学习新知识时愿意重写自己的代码 (#8 Be willing to rewrite your own code when you learn something new)

Most developers have a full-time job and a few smaller projects on their own, often open-source. Clients usually don’t want to pay for a larger refactoring, unless absolutely necessary. However, working on your own smaller projects can be exceedingly beneficial for your personal skill building. After some time, most of us can see how much better we could have written our previous code. That is a great opportunity to start over and do it better.

大多数开发人员都有自己的全职工作，并且有一些较小的项目通常是开源的。 除非绝对必要，否则客户通常不愿为更大的重构付费。 但是，开展自己的小型项目可能对您的个人技能培养特别有益。 一段时间后，我们大多数人都可以看到我们编写以前的代码会更好。 这是一个重新开始并做得更好的好机会。

Personally, I have rewritten one of my projects three times from scratch. I reached the point where I could no longer accept the original style. I don’t consider it a waste of time, because it helped me gain additional experience very quickly. Time itself doesn’t help. Doing the same thing over and over for 10 years is hardly better than extensively learning and practicing for one year. I know developers who have been in the trade for a decade or more, yet aren’t even able to use the include command to separate their code. All their experience isn’t helping them at all.

就个人而言，我从头开始重写了我的项目三遍。 我到了无法再接受原始风格的地步。 我认为这不会浪费时间，因为它可以帮助我很快地获得更多经验。 时间本身无济于事。 一遍又一遍地做同一件事，并不比广泛学习和练习一年更好。 我知道开发人员从事交易已有十年或更长时间，但甚至无法使用include命令来分隔他们的代码。 他们所有的经验根本无法帮助他们。

How skill development may look like:

技能发展的样子：

• Study, learn best practices, review others people’s code
  学习，学习最佳做法，查看他人的代码
• Do your projects the best you can
  尽力做到最好的项目
• Have someone else review your work and provide feedback
  让其他人查看您的工作并提供反馈
• Refactor your code in a better way or start all over if needed
  以更好的方式重构代码或在需要时从头开始
• Have another person review your code again. Collect feedback and learn something new
  让其他人再次查看您的代码。 收集反馈并学习新知识
• Choose your own style, while using as many best practices as possible
  选择自己的风格，同时使用尽可能多的最佳实践

Whenever you find Code Smells in your code, think about the code and the overall programming style. It may be time to improve the existing code.

每当您在代码中找到代码气味时 ，请考虑代码和整体编程风格。 现在可能是时候改进现有代码了。

＃9结合想法 (#9 Combine ideas)

Many programmers tend to choose one way of writing code (OOP, functional programming, procedural programming), and they want to stick to their style, no matter the situation. They may even dislike some approaches and styles without understanding them at all. All programming styles may be useful given a specific scenario.

许多程序员倾向于选择一种编写代码的方式(OOP，函数式编程，过程式编程)，并且无论情况如何，他们都希望坚持自己的风格。 他们甚至可能完全不了解它们而讨厌某些方法和样式。 在特定情况下，所有编程样式都可能有用。

Another example is using jsons in relational databases. MySQL 8 has quality support for jsons, and there’s no reason to make your databases 100% relational. It can produce a very difficult structure of tables. I personally like the concept of hybrid databases.

另一个示例是在关系数据库中使用json。 MySQL 8对json具有高质量的支持，因此没有理由使您的数据库具有100％的关系。 它会产生非常困难的表结构。 我个人喜欢混合数据库的概念。

You may find endless discussions about whether a monolithic app makes for a better concept than using microservices. As usual, the world is not black and white, and the typical answer would be “it depends”. There is no reason to avoid a hybrid model. We are back in section #4 — don’t get too religious.

您可能会发现无休止的讨论，关于单片应用程序是否比使用微服务更好。 和往常一样，世界不是黑白的，典型的答案将是“ 它取决于 ”。 没有理由避免使用混合模型。 我们回到了第4节-不要太虔诚。

＃10写好名字并发表评论 (#10 Write good names and make comments)

Naming and cache invalidation are humorously considered the most difficult parts of programming. And for a good reason. Naming makes a difference between well and poorly readable code.

幽默地认为命名和缓存无效是编程中最困难的部分。 并且有一个很好的理由。 命名使可读性强的代码有所区别。

When I studied at university, we used Matlab extensively as our primary programming tool. One of Matlab’s strong features is the possibility to write increasingly dense code. When we started learning Matlab, we had a programming task that most of us dealt with in a standard procedural way. Then, the second task was: “write your code in a single line”. This can often be done in Matlab with little effort. However, reading it can truly be a hellish experience. Avoid overly dense code unless absolutely necessary for performance reasons, for example. Usually, programmers give up a little performance for readability. Remember, you may have difficulties reading your own code after two months as well. Don’t sabotage your future work!

当我在大学学习时，我们广泛使用Matlab作为我们的主要编程工具。 Matlab的强大功能之一是可以编写越来越密集的代码。 当我们开始学习Matlab时，我们有一个编程任务，我们大多数人都是以标准的程序方式处理的。 然后，第二个任务是：“ 用一行编写代码 ”。 这通常可以在Matlab中轻松完成。 但是，阅读它确实是一种地狱般的经历。 例如，除非出于性能原因绝对必要，否则请避免使用过于密集的代码。 通常，程序员为了可读性而放弃一些性能。 请记住，两个月后，您可能也很难阅读自己的代码。 不要破坏您的未来工作！

Creating good names for methods is essential for reading any code. I even show this to our clients and demonstrate how we create code and why it’s important. If you do so, the project price matters significantly less, because the value is demonstrated.

为方法创建好名字对于阅读任何代码都是必不可少的。 我什至向我们的客户展示了这些，并演示了我们如何创建代码以及代码为什么如此重要。 如果这样做，项目价格的重要性将大大降低，因为已证明了其价值。

Using proper names is closely connected to the code separation. Remember, loops, nested conditions, and regular expressions are hard to read. Encapsulate blocks of code into functions or classes. It will make the code much more friendly for our teammates.

使用专有名称与代码分隔紧密相关。 请记住，循环，嵌套条件和正则表达式很难阅读。 将代码块封装到函数或类中。 这将使代码对我们的队友更加友好。

Compare these two examples (PHP code):

比较这两个示例(PHP代码)：

if(!preg_match("^[_a-z0–9-]+(\.[_a-z0–9-]+)*@[a-z0–9-]+(\.[a-z0–9-]+)*(\.[a-z]{2,3})$^", $email)) {
   … handling wrong email
}

or

要么

if(!$this->isEmailValid($email)) {
   … handling wrong email
}private function isEmailValid(string $email) 
{
     return preg_match("^[_a-z0–9-]+(\.[_a-z0–9-]+)*@[a-z0–9-]+(\.
            [a-z0–9-]+)*(\.[a-z]{2,3})$^", $email);
}

A few tips for classes/methods/variables naming:

有关类/方法/变量命名的一些提示：

• If possible, avoid words management or manager. Why? Because pretty much everything can be a manager. It will quickly get overused.

  如有可能，请避免与管理人员或经理谈话 。 为什么？ 因为几乎所有事情都可以成为经理。 它将很快被滥用。

• Use the order of verbs and nouns consistently. For example, emailValidation or validateEmail are both fine. Just pick one style and stay with it.

  一致地使用动词和名词的顺序。 例如， emailValidation或validateEmail都可以。 只需选择一种样式并保持不变即可。

• If possible, indicate what the method returns. I like using “is” for boolean return types. For example, I think isEmailValid is a better name than emailValidation. You will immediately know that the “is” at the beginning of the name means true/false return type. Similarly, has or contains can indicate a boolean return type.

  如果可能，请指明方法返回的内容。 我喜欢对布尔值返回类型使用“ is”。 例如，我认为isEmailValid是比emailValidation更好的名称。 您将立即知道，名称开头的“ 是 ”表示返回true / false 。 同样， 有或含有可以表明一个布尔返回类型。

• If possible, don’t repeat yourself. One example is for using classes. Consider a $user class. It’s fine to have method names without the word “user”. It’s clear that the method is about the user. $user->getFullName() or $user->getAddress() are better than $user->getUserFullName() or

  如果可能的话，不要重复自己。 一个示例是使用类。 考虑一个$ user类。 方法名称不带“ user ”一词是很好的。 显然，该方法与用户有关。 $ user-> getFullName()或$ user-> getAddress()优于$ user-> getUserFullName()或

  If possible, don’t repeat yourself. One example is for using classes. Consider a $user class. It’s fine to have method names without the word “user”. It’s clear that the method is about the user. $user->getFullName() or $user->getAddress() are better than $user->getUserFullName() or $user->getUserAddress().

  如果可能的话，不要重复自己。 一个示例是使用类。 考虑一个$ user类。 方法名称不带“ user ”一词是很好的。 显然，该方法与用户有关。 $ user-> getFullName()或$ user-> getAddress()比$ user-> getUserFullName()或$ user-> getUserAddress()更好 。

• If there’s no strong reason to do otherwise, follow generally accepted conventions. For example, in PHP, variable names are in the camelCase style. SQL column names are written in snake_case. Classes and objects use PascalCase.

  如果没有充分的理由这样做，请遵循公认的惯例。 例如，在PHP中，变量名称采用camelCase样式。 SQL列名称写在snake_case中 。 类和对象使用PascalCase 。

• In some languages, e.g., Javascript, it’s possible to use the $-sign as a regular character, as with any other letter. In PHP, the $-sign is a special character, yet it’s not in JS. So, you are free to name your variable “var user” or “var $user”. However, the $-sign can separate special variables. When you join a new JS project, ask the software architect how to use it. In VueJs, for instance, variables starting with $ indicate special objects provided by Vue itself. For example, this.$route or this.$store. Again, whatever notation you go with, stay consistent.

  在某些语言(例如Javascript)中，可以将$符号用作常规字符，就像其他任何字母一样。 在PHP中， $-符号是一个特殊字符，但在JS中不是。 因此，您可以随意将变量命名为“ var user ”或“ var $ user ”。 但是， $符号可以分隔特殊变量。 当您加入新的JS项目时，请询问软件架构师如何使用它。 例如，在VueJs中，以$开头的变量表示Vue本身提供的特殊对象。 例如， this。$ route或this。$ store 。 同样，无论使用哪种符号， 都应保持一致 。

• Similar to the previous point, sometimes _ is used for private variables, especially in JavaScript. Some developers love it, some hate it. You know how it is.. Just be consistent.
  与上一点类似，有时_用于私有变量，尤其是在JavaScript中。 有些开发人员喜欢它，有些讨厌它。 你知道这是怎么回事。

＃11了解更多语言 (#11 Learn more languages)

If you are a professional programmer, definitely learn more languages. At least some experience is useful. For example, the Matlab/R approach to programming is totally different from that of C. An object-oriented approach of C++ is different from C or Basic. Programming for Windows using C# requires a different approach than creating a console program in C. Then, there are several new ones, such as Go, Rust, or Swift.

如果您是专业程序员，请一定要学习更多的语言。 至少有一些经验是有用的。 例如，用于编程的Matlab / R方法与C完全不同。C++的面向对象方法与C或Basic不同。 使用C＃进行Windows编程所需要的方法不同于用C创建控制台程序所采用的方法。然后，有几个新的程序，例如Go，Rust或Swift。

Different languages solve the same problems differently. Learning them will greatly increase your problem-solving skills.

不同的语言以不同的方式解决相同的问题。 学习它们将大大提高您的解决问题的能力。

＃12测试 (#12 Test)

Testing is an essential part of any kind of code writing. There is a whole approach built around testing, called Test-Driven Development (TDD in short). The main principle of this approach is to first write tests for new objects, and then fill the classes with business logic. There are several advantages to this approach:

测试是任何类型的代码编写的重要组成部分。 围绕测试构建了一种完整的方法，称为“ 测试驱动开发” (简称TDD )。 这种方法的主要原理是首先为新对象编写测试，然后用业务逻辑填充类。 这种方法有几个优点：

• tests are done first. Therefore you need to think of inputs and outputs before any business logic is implemented
  首先进行测试。 因此，在实现任何业务逻辑之前，您需要考虑输入和输出
• once you have the tests ready, it is very easy to safely update your app
  准备好测试后，很容易安全地更新应用程序
• the larger the app, the more important testing is — it’s very difficult to find all the possible errors in a large app
  应用程序越大，测试就越重要-在大型应用程序中很难找到所有可能的错误

TDD may seem like a lot of work and, therefore, only a fraction of programmers actually use it. I personally don’t know anyone using this technique. However, there are several useful principles involved that will help every programmer.

TDD似乎需要大量工作，因此，只有一小部分程序员实际使用它。 我个人不知道有人在使用这种技术。 但是，其中涉及一些有用的原则，这些原则将对每个程序员都有帮助。

A big role in testing is to be able to refactor and verify that everything is still working as expected. It’s difficult to achieve that state with an overabundance of unit tests and, thus, a combination of unit tests + component tests should be explored. In component tests, N-units talk together. On top of that, clients appreciate e2e (end to end) tests that ensure the client’s experience remains the same after a new release. For a web application, there are several popular tools, such as Cypress, TestCafe, or Selenium, (Selenium vs. Cypress).

测试中的重要角色是能够重构并验证一切是否仍按预期进行。 过多的单元测试很难达到这种状态，因此，应该探索单元测试和组件测试的组合。 在组件测试中，N个单元一起交谈。 最重要的是，客户欣赏e2e(端到端)测试，这些测试可确保在新版本发布后客户的体验保持不变。 对于Web应用程序，有几种流行的工具，例如Cypress，TestCafe或Selenium( Selenium v​​s. Cypress )。

Write applications and their parts in such a way that allows easy testing — manual or automatic. If testing is difficult, that usually means that the code structure is too complicated and may require further thought.

以易于测试的方式编写应用程序及其各部分(手动或自动)。 如果测试困难，通常意味着代码结构太复杂，可能需要进一步考虑。

＃13设计模式 (#13 Design patterns)

Design patterns (1) are general code constructs solving specific problems that appear frequently. It is not necessary to force yourself into using all of them. However, having knowledge of their construction is extremely powerful.

设计模式( 1 )是解决常见问题的通用代码构造。 不必强迫自己使用所有这些。 但是，了解其构造非常强大。

There are several design patterns that, in my opinion, every programmer should be aware of:

我认为，每个程序员都应该意识到几种设计模式：

• observer
  观察者
• factory
  厂
• builder
  建造者
• singleton
  单身人士
• decorator
  装饰工

These patterns will help you decouple your code and solve typical problems in a well-tested manner. Plus, your code will become easier to read, as the naming will suggest what the classes and methods do.

这些模式将帮助您将代码解耦并以经过测试的方式解决典型问题。 另外，您的代码将变得更易于阅读，因为命名将建议类和方法的功能。

Another exceptionally important piece of knowledge is being aware of anti-patterns, (1). Anti-patterns are concepts that lead to problems, yet are extremely typical in a lot of software. A few examples include:

另一个非常重要的知识是了解反模式( 1 )。 反模式是导致问题的概念，但是在许多软件中却非常典型。 一些示例包括：

• God objects
  神的对象
• Reinventing the wheel
  重新发明轮子
• Swiss army knife
  瑞士军刀
• Spaghetti code
  意大利面代码
• Lava flow
  熔岩流

＃14关注点分离 (#14 Separation of Concerns)

One of the most powerful programming principles is the Separation of Concerns (SoC). The rule is simple, each class or function should do a simple task. Classes that have a lot of different methods are quite difficult to maintain and extend. This is where the banana/gorilla jokes come from: “You wanted a banana but what you got was a gorilla holding the banana and the entire jungle”. Don’t let your classes and methods grow too much. The next rule will help you stay on track.

最强大的编程原理之一是关注点分离 (SoC)。 规则很简单，每个类或函数都应该做一个简单的任务。 具有许多不同方法的类很难维护和扩展。 这就是香蕉/大猩猩笑话的来源：“ 您想要一个香蕉，但您得到的是一只大猩猩，盛着香蕉和整个丛林 ”。 不要让您的类和方法增长太多。 下一条规则将帮助您保持进度。

If a class or a function does too many things, it is difficult to read and understand. Additionally, combining multiple features together makes code reuse much more difficult.

如果类或函数执行了太多操作，则很难阅读和理解。 此外，将多个功能组合在一起会使代码重用变得更加困难。

A very nice example of separation is the development of html. When html started, there was no CSS. If a specific font was needed, there was a tag for it:

分离的一个很好的例子是html的开发。 html启动时，没有CSS。 如果需要特定的字体，则有一个标签：

<font color="red" face="Verdana, Geneva, sans-serif" size="+1">My text in red and Verdana font</font>

The web structure, its content and styles were closely binded together. CSS allowed to separate styles and the web structure. Suddenly it was possible to update styles without touching the html code itself.

网络结构，其内容和样式紧密地结合在一起。 CSS允许分隔样式和网络结构。 突然之间，无需触摸html代码本身就可以更新样式。

＃15在描述部分代码时，尽量减少使用“和” (#15 Minimize the use of “and” when describing parts of your code)

When explaining what any of your functions or classes do, listen carefully if you’re not using “and” too many times. If you do, that is a sign that your function or class should be split into multiple entities. The Single Responsibility Principle truly is your friend.

在解释任何函数或类的功能时，如果您不多次使用“ and”，请仔细听。 如果这样做，则表明您应将函数或类拆分为多个实体。 单一责任原则确实是您的朋友。

An example of a non-optimal class: Carries user’s data and validates input data and saves data to DB.

非最佳类的示例：携带用户数据并验证输入数据，并将数据保存到DB。

＃16不要重复自己 (#16 Do Not Repeat Yourself)

Do Not Repeat Yourself (DRY)! This is an extremely important rule that everyone should remember. Any time you use copy & paste, just stop doing it, and rethink what you are doing. Do you really need to copy some parts of the code? Can’t it be changed to code reuse?

不要重复自己( 干 )！ 这是每个人都应该记住的极其重要的规则。 每当您使用复制和粘贴时，就停止这样做，然后重新考虑您在做什么。 您是否真的需要复制部分代码？ 不能更改为代码重用吗？

It might sound obvious, but if we, as programmers, forget to think, and we just keep writing new lines of code, it can be tricky to follow this rule. I saw a code, where each of the 30 html pages had its own header. No include of a header file. If the customer decided to change a favicon, the programmers would need to update 30 pages. A true nightmare.

听起来似乎很明显，但是如果我们(作为程序员)忘记思考，而我们只是继续编写新的代码行，那么遵循此规则可能会很棘手。 我看到了一个代码，其中30个html页面中的每个页面都有自己的标题。 不包括头文件。 如果客户决定更改图标，则程序员将需要更新30页。 一场真正的噩梦。

＃17告诉，不要问 (#17 Tell, don’t Ask)

The “Tell, don’t Ask” principle describes a very important concept of writing functions. The core idea is that we should tell a class what to do with its data. The data business logic should be inside, not outside, the class. The incorrect way would be asking for the data, updating them, and setting them back to the class. Examples:

“不说话，不问 ”原理描述了编写函数的一个非常重要的概念。 核心思想是我们应该告诉一个类如何处理其数据。 数据业务逻辑应该在类的内部，而不是外部。 错误的方式是要求数据，更新数据并将其设置回类。 例子：

Violating the Tell, don’t Ask principle

违反“不说，不问”原则

class User {
    public $firstName;
    public $lastName;
    public $fullName;
    public $myValue = 0;
}$user = new User();
$user->fullName = $user->firstName . '' . $user->lastName;
$user->myValue = $user->myValue++;

Better code

更好的代码

class User {
    public $firstName;
    public $lastName;
    private $myValue = 0;    public function getFullName() {
       return $this->firstName . ‘ ‘ . $this->lastName;
    }    public function incrementMyValue() {
        $this->$myValue ++;
    }
}$user = new User();
$fullName = $user->getFullName();

＃18开放-封闭原则(OCP) (#18 Open — Closed principle (OCP))

Programming should follow best practices and certain rules such as SOLID, which improves the code, making it easier for maintaining, reading, and reusing. However, at some point, every programmer has to decide where to put the line between good and over-optimized code. If you take any rule to the extreme, the result will not be optimal. This is the beauty of programming — there’s never only one right answer. The Open-Closed principle is one of those that always calls for a compromise between the programming pace, code length, number of classes, readability, reusability, etc. In my opinion, this is one of the trickiest rules to actually apply in real coding. Let’s explain it a little bit using examples.

编程应遵循最佳实践和某些规则，例如SOLID ，它可以改进代码，使其更易于维护，读取和重用。 但是，在某个时候，每个程序员都必须决定在好的代码与过度优化的代码之间的界限。 如果您采取任何规则，那么结果将不是最佳的。 这就是编程的美–永远不会只有一个正确的答案。 开放封闭原则是始终要求在编程速度，代码长度，类数，可读性，可重用性等之间折衷的原则之一。在我看来，这是实际应用于实际编码的最棘手的规则之一。 让我们使用示例进行一些解释。

The Open-closed principle means that your code is open for extension and closed for modification. To put it simply, it means that in order to extend it, you should not update the existing code. This rule is especially important for libraries that tend to have their own production cycle. If you are a library developer, you don’t want to update/test/release your code every time some need an extension.

开闭原则意味着您的代码是开放的以便扩展，封闭的代码则可以进行修改。 简而言之，这意味着为了扩展它，您不应该更新现有代码。 对于倾向于具有自己的生产周期的库，此规则尤其重要。 如果您是图书馆开发人员，则不想每次有人需要扩展时都更新/测试/发布您的代码。

How do you recognize that the OCP may be violated in your code? A typical scenario involves using multiple items of the same type — for example, different file types. You may need a handler and a model for each file type (jpg, png, doc, pdf, etc.). A simple solution may include a block of if/elseif or a long switch, such as the following:

您如何识别代码中可能违反了OCP？ 典型的场景涉及使用相同类型的多个项目，例如，不同的文件类型。 对于每种文件类型(jpg，png，doc，pdf等)，您可能需要一个处理程序和一个模型。 一个简单的解决方案可以包括一个if / elseif块或一个长开关，例如：

public function getHandler(string $fileType){
    switch ($fileType) {        case “jpg” : 
             return new JpgHandler();
             break;        case “doc” : 
             return new DocHandler();
             break;        case “pdf” :
             return new PdfHandler();
             break;
    }
}

This is a typical example where OCP is violated, because every time a new file type is meant to be added, you need to update this switch. The code is not closed for modification. This kind of trivial solution with the switch will cause problems down the road.

这是违反OCP的典型示例，因为每次要添加新文件类型时，您都需要更新此开关。 该代码未关闭以进行修改。 这种使用交换机的简单解决方案将在以后引起问题。

A solution that I like to use is implementing registers. Anytime you need a new handler, you simply register it. In Laravel, this can be done in the AppServiceProvider, which handles binding in the container.

我喜欢使用的一种解决方案是实现寄存器。 每当您需要新的处理程序时，只需注册它即可。 在Laravel中，这可以在AppServiceProvider中完成，该AppServiceProvider处理容器中的绑定。

Example:

范例 ：

class FilesRegistry
{
    private $handlers = [];    public function addFileHandler(Handler $handler){
        $this->handlers[$handler->getExtension()] = $handler;
    }    public function getHandler(string $extension) {
        return $this->handlers[$extension];
    }
}

in the AppServiceProvider (or other register method of the Dependency Injection container) we have:

在AppServiceProvider (或依赖注入容器的其他注册方法)中，我们具有：

$filesRegistry = new FilesRegistry();$jpgHandler = new JpgHandler();
$filesRegistry->addFileHandler($jpgHandler);$docHandler = new DocHandler();
$filesRegistry->addFileHandler($docHandler);

Now, we have all the handlers in one place, and everything is defined on the container (or other top-level places of our code). If we need to add a new handler, we simply add it to the service provider and register it. Then, the code that needs to get the handler will ask the register, assuming it has one. If not, there can, for instance, be a general file handler, or it throws an exception.

现在，我们将所有处理程序放在一个位置，并且所有内容都在容器(或代码的其他顶级位置)上定义。 如果我们需要添加一个新的处理程序，我们只需将其添加到服务提供商并进行注册。 然后，需要获取处理程序的代码将假设该寄存器有一个请求寄存器。 如果没有，例如，可以有一个通用文件处理程序，否则它将引发异常。

＃19简短功能 (#19 Short functions)

Writing short, well-named functions is the key to the good readability of every code. This rule of thumb is incredibly simple — if the function code is longer than the height of your screen, then it’s most likely too long. Shorter functions can be named better, making the code easier to understand. On top of that, they are easier for testing.

编写简短的，有名字的函数是每个代码良好可读性的关键。 这个经验法则非常简单-如果功能代码长于屏幕的高度，则很可能太长。 较短的函数可以更好地命名，从而使代码更易于理解。 最重要的是，它们更易于测试。

Long functions should always turn the red light on as a code smell. They often contain too many nested if/else/for/while blocks, which are extremely difficult to read. Keep in mind that someone else will read your code. Even you, after 2–3 months, will have a hard time figuring out what your crazy functions do, and why you implemented them in such a messy way.

长功能应始终将红灯作为代码气味打开。 它们通常包含太多嵌套的if / else / for / while块，这是很难阅读的。 请记住，其他人也会阅读您的代码。 即使是2到3个月后的您，也将很难弄清您疯狂的功能是什么，以及为什么您要以这种混乱的方式实现它们。

There are several methods for shortening functions.. Here are a few examples:

有几种缩短函数的方法。以下是一些示例：

• reduce the use of if/else

  减少使用if / else

if($var === 1) {
    return true;
}
else {
    return false;
}

replace with:

用。。。来代替：

return $var === 1;

• foreach can be usually effectively replaced with array functions

  foreach通常可以用数组函数有效地替换

$result = 0;
foreach($numbers as $number) { /* $number is a class */
    $result += number.value;
}

replace with:

用。。。来代替：

$result = array_reduce($numbers, “sumNumberValues”);

where the sumNumberValues is defined separately as

其中sumNumberValues分别定义为

sumNumberValues ($total, $number){
    return total + $number->value;
}

＃20框架 (#20 Frameworks)

Nowadays, most of the popular programming languages have multiple frameworks available. A framework is not only a set of functions/classes/tools, but also an approach to writing code. It helps you be consistent with your coding style. On top of that, all the typical tasks that every web has to deal with are already solved and well tested — for instance — routing, data validation, database communication, collections, and arrays manipulations, etc. Don’t try to reinvent the wheel!

如今，大多数流行的编程语言都有多种可用的框架。 框架不仅是一组功能/类/工具，还是一种编写代码的方法。 它可以帮助您与编码风格保持一致。 最重要的是，每个网络必须处理的所有典型任务都已经解决并经过了良好的测试，例如，路由，数据验证，数据库通信，集合和数组操作等。不要试图重新发明轮子！

讨论区 (Discussion)

What are your tips for becoming a better programmers? Share in the comments!

您成为更好的程序员的提示是什么？ 分享评论！