每一种编程语言所擅长的地方_如何擅长编程

每一种编程语言所擅长的地方

I have been asked this question so many times — “Am I a good programmer ?” I always say “It depends”. Programming is an art and a good code is no less appealing than a nice brush work on the canvas. With technology changing drastically, there are a lot of new concepts to learn, however, I believe the key principles always remain the same.

我已经被问过很多次这个问题了- “我是一个好程序员吗？” 我总是说“取决于” 。 编程是一门艺术，好的代码并不比在画布上漂亮的笔刷吸引人。 随着技术的急剧变化，有很多新概念需要学习，但是，我相信关键原理始终保持不变。

After being in the engineering line for a while, and working for reputed companies, I can share my experience on few good principles of writing a satisfactory code, and how to always improve along the way

在工程部门工作一段时间后，并在知名公司工作，我可以分享我的经验，分享一些编写令人满意的代码的良好原则，以及如何不断改进

Instead of Copy-Paste, Copy-Understand-Paste

复制-理解-粘贴而不是复制-粘贴

This is a very core and basic principle and is more applicable nowadays when you will get the solution to most of your problem online. Let me share a small example from my life.

这是一个非常核心和基本的原则，如今在您可以在线获取大部分问题的解决方案时更适用。 让我分享我生活中的一个小例子。

In the early 2000 I was working in unix and shell scripting. While analyzing some data, I had to do a group by on a fairly big data set. AWK was very popular to do this kind of quick analytics. So I searched in google — “Group by with awk”. There came my solution

在2000年初，我从事UNIX和Shell脚本编写。 在分析某些数据时，我不得不对相当大的数据集进行分组 。 AWK在进行这种快速分析方面非常受欢迎。 因此，我在Google中搜索了“ Group by with awk”。 我的解决方案来了

awk '{arr[$1]+=$2} END {for (i in arr) {print i, arr[i]}}'

I quickly pasted this into my terminal and voila — there’s my output. I tested and verified the code on small data set and did not have to change anything. Wow my luck. It was a big thing those days to get perfect results from Google. Being in the same project for a while, I needed this command for multiple times, and like the first time, I google and got my results. Then one day, I needed this command, but there was a slight change — Internet was down. I had no clue on how to logically write the “group by” using AWK. I understood the reason why — I had never, not even for a second tried to understand how the code works. I finally wrote the command myself, but from then on, I put an extra stress on understanding the piece of code that I copy from the internet even if it blindly works. I understand the above may a very minor problem, but it is the way of thinking that is more important. Although, google search is one click away, every time we copied something from the internet, we have a chance to learn and understand something new. In the race to deliver our results, we often forget to pause and understand what we are doing. I guess this could be applicable for the general life itself, but now thats a bit too philosophical. Let’s not go there.

我很快将其粘贴到终端中，瞧，这就是我的输出。 我测试并验证了小型数据集上的代码，而无需进行任何更改。 哇，我的运气。 如今，要从Google获得完美的结果是一件大事。 在同一个项目中一段时间​​，我多次需要此命令，就像第一次一样，我用google搜索并得到了结果。 有一天，我需要此命令，但有一点变化– Internet断开了。 对于如何使用AWK在逻辑上编写“分组依据”，我一无所知。 我理解了原因-我从来没有，甚至从未尝试过了解代码的工作原理。 我最终自己写了该命令，但是从那以后，即使我盲目地工作，我也会特别强调理解我从互联网复制的那段代码。 我了解以上可能是一个很小的问题，但更重要的是思维方式。 尽管Google搜索一键即可实现，但是每次我们从互联网上复制某些内容时，我们都有机会学习和理解新知识。 在争取结果的过程中，我们常常忘记暂停并了解我们在做什么。 我想这可能适用于一般生活本身，但是现在有点太哲学了。 我们不要去那里。

Unit Tests

单元测试

A beginner or novice engineer may not appreciate the importance of a test case. However, anyone who has been stuck in this line of work for a while will tell you the importance of writing test cases. There are few major reasons why test cases are very important for a nice and durable piece of code:

初学者或新手工程师可能不理解测试用例的重要性。 但是，任何长期从事此工作的人都会告诉您编写测试用例的重要性。 对于很好且持久的代码来说，测试用例非常重要的主要原因不多：

→ Prevent introducing bugs: In a large organization, there is no guarantee that the person who wrote the code will make all future changes. Sometimes lot of folks work on the same code. Adding more and more code will introduce bugs to some untouched piece of code. Having test cases for each modules and and each conditions increases the changes of catching and debugging these issues early.

→防止引入错误：在大型组织中，不能保证编写代码的人会进行所有将来的更改。 有时很多人都在使用相同的代码。 添加越来越多的代码将给一些未经修改的代码引入错误。 为每个模块和每个条件提供测试用例会增加早期发现和调试这些问题的变化。

→ Making the code modular: Unit Test are written for each unit / module of code. This makes the developer modularize the code, rather than writing all the code in one block.

→使代码模块化：为代码的每个单元/模块编写单元测试。 这使开发人员将代码模块化，而不是将所有代码写在一个块中。

→ Reusability and Reliability: By unit testing, individual components become isolated from each other, making the codes are more reliable, since it’s been tested in a contained environment. This also makes the code more reusable. This again ties back to the previous point of making code modular.

→可重用性和可靠性：通过单元测试，各个组件变得彼此隔离，从而使代码更加可靠，因为它已在封闭环境中进行了测试。 这也使代码更可重用。 这再次与使代码模块化的先前观点联系在一起。

Adding Comments:

添加评论：

One of the most simplest and easiest change that one can do in their code is add comments. Adding comments help future developers to get a grasp of what this piece of code is supposed to do. By adding comments, I do not mean going back and adding comments after the coding is done — it should be written before the class / method is written. Ideally, each class and method should have a comment. I would also add comments to complex logic to explain why I did it this way. This would help others understand and propose a better way without going through the code at all.

在代码中可以做的最简单，最简单的更改之一就是添加注释。 添加注释可帮助将来的开发人员了解这段代码应该做什么。 通过添加注释，我并不是要在编码完成后返回并添加注释- 它应该在编写类/方法之前编写 。 理想情况下，每个类和方法都应有一个注释。 我还将在复杂的逻辑中添加注释，以解释为什么这样做。 这将帮助其他人完全理解并提出更好的方法，而无需阅读代码。

Always Write to an Abstract class:

始终写入抽象类：

This is a principle I try to follow to make my code modular. This is mostly prevalent in OOP. Let us look at an example to understand the idea behind this — Suppose you re given a task of writing a data to text file. The easiest option is to define a method SaveToText and call this method.

这是我尝试遵循的使我的代码模块化的原则。 这在OOP中最普遍。 让我们看一个示例，以了解其背后的思想-假设您被赋予将数据写入文本文件的任务。 最简单的选择是定义方法SaveToText并调用此方法。

def SaveToText(data) = {
  data.write …
}

What happens when there is a migration effort and you are asked to write to a database. What if some users still want to continue save to text, while some users want to write to database. The code can better messier in no time and testing this can be a nightmare.

当进行迁移工作并要求您写入数据库时​​会发生什么。 如果某些用户仍想继续保存到文本，而某些用户想写入数据库怎么办？ 该代码可以立即改善混乱状况，而对其进行测试可能是一场噩梦。

An alternate approach is using abstract class.

另一种方法是使用抽象类。

Lets define an abstract class

让我们定义一个抽象类

abstract class WriteContext() = {
  def store(data)
}

And we add a builder class

然后添加一个构建器类

class BuildWriteContext(storeType) = {def CreateStoreContext() = {
  case storeType = "text", call TextWriter // No hard codings though
  case storeType = "DB", call DBWriter
}

Then we have concrete implementations of the writers

然后我们有作者的具体实现

class DBWriter extends WriteContext{
  override method store(data) = {
    data.writeToDB …
  }
}

Call the method like

像这样调用方法

(new BuildWriteContext("DB")).CreateStoreContext

This makes the code modular, extensible and more easy to test. This is a simple example, but the principle can be used every-time. Some hard codings are shown as example. Good practice to use enum.

这使代码模块化，可扩展且更易于测试。 这是一个简单的示例，但是原理可以每次使用。 以一些硬编码为例。 最好使用枚举。

Complexity:

复杂：

Everyone here would have heard of complexity of an algorithm, those mystifying Big(O) notation. Time complexity is commonly estimated by counting the number of elementary operations performed by the algorithm. Similarly, there is space complexity. A small change to the code can help improving this complexity. It could be as simple as using a HashTable / Map instead of an Array or mathematically solving a problem instead of looping an extra time. It is always a good practice to review each data structure before using it, or analyzing the way we are searching an element etc.

这里的每个人都会听说过算法的复杂性，那些神秘的Big(O)表示法。 通常通过计算算法执行的基本运算的数量来估算时间复杂度。 同样，也存在空间复杂性。 对代码进行少量更改可以帮助改善这种复杂性。 它可以像使用HashTable / Map而不是Array一样简单，或者可以通过数学方式解决问题而不是浪费额外的时间。 在使用每个数据结构之前，或者分析我们搜索元素的方式等，总是一个好习惯。

I hope this document helps you look at the code with a different perspective. If we keep these in mind when writing every piece of code, I am sure your code will be a piece of beauty. I may have missed few such principles and I will appreciate if you can add them to the comments. I will surely add them here.

希望本文档可以帮助您以不同的角度看待代码。 如果在编写每段代码时都牢记这些，我相信您的代码将是一件美丽的事。 我可能错过了一些这样的原则，如果您可以将其添加到评论中，将不胜感激。 我一定会在这里添加它们。

翻译自: https://medium.com/swlh/how-to-excel-in-programming-19d3dad8a0e8

每一种编程语言所擅长的地方