学习编程有多难( 三)

Jessica Su, Stanford CS PhD

杰西卡·苏，斯坦福大学计算机科学博士

The idea that you'll never figure out how to fix your code and you should give up on your project because you are not and will never be good enough.
Over the past two years I've gradually developed faith in my ability to (eventually) solve problems, and I think this alone made me a much stronger programmer than I was in college.

你永远不知道如何修复你的代码，你就应该放弃你的项目，因为你不会，就永远不会足够好。
在过去的两年里，我逐渐对自己(最终)解决问题的能力产生了信心，我认为这一点让我成为了一个比大学时更强大的程序员。

Jim Winstead
I am 76 and I have been a designer and programmer since 1961. Programming can be learned but The best programmers are born not taught. I simply understood from the beginning how to solve the problems. I saw it as a flow in my head and the programming language was not really significant. What ever language it was I could make it work. I didnt see it as a language I saw it as finding a translation of the solution I saw into the language that was required at the moment. So U dont start from the language u start from the understanding of the problem and then a translation..
I am not sure how clear that is to some of you but those that have been there that are natural problem solvers will understand.

我今年76岁，自1961年以来一直是一名设计师和程序员。编程是可以学习的，但最好的程序员不是天生的。我从一开始就明白如何解决这些问题。我认为这是我头脑中自动涌现出来的，编程语言并没有真正意义。无论是哪种语言，我都能让它发挥作用。我不认为它是一种语言，我认为它是将我所看到的解决方案翻译成目前所需的语言。所以你不是从语言开始，而是从对问题的理解开始，然后是翻译。
我不确定这对你们中的一些人来说够不够清楚，但那些天生就能解决问题的人会理解的。

Steve Baker, Senior Software Engineer (2013-present)

Steve Baker，高级软件工程师(2013-至今)

Writing small, simple programs, by yourself, is fairly easy.
Working with large, complex programs, in a team of other programmers is MUCH harder.
It’s kinda like asking whether playing the piano is hard or easy. Anyone can learn enough to play a few simple tunes in a matter of a few hours - but to become a concert pianist is insanely difficult.

自己编写小而简单的程序是相当容易的。
在一个由其他程序员组成的团队中处理大型、复杂的程序要困难得多。
这有点像问弹钢琴是难还是容易。任何人都能在几个小时内学会演奏几首简单的曲子，但要成为一名成为钢琴演奏家是极其困难的。

Andrew Sharpe, I have been a Software Engineer for 43 years.

安德鲁·夏普，我做软件工程师已经43年了

Programming itself isn’t hard; it is simply taking a language you know and implementing a solution with it. It’s almost mechanical. What is hard is finding a simple, succinct but appropriate solution for the problem you are trying to solve. Years ago, there were Analysts that formulated the solutions in a flow chart, and the Programmers simply implemented that flow chart in code. Now, the Software Engineer role has both of these components, as well as performance considerations, user experience considerations, maintainability considerations, cost considerations and many others. So, no, the mechanics of programming aren’t hard, learning a new language is no real challenge, it is the development of a good solution that consists of simple, maintainable, documented code that is the challenge.

编程本身并不难；它只是简单地使用一种你知道的语言并用它实现一个解决方案。这几乎是机械的。困难的是为你试图解决的问题找到一个简单、简洁其合适的解决方案。几年前，有分析师在流程图中制定了解决方案，程序员只是用代码实现了流程图。现在，软件工程师的角色包括这两个部分，以及性能考虑、用户体验考虑、可维护性考虑、成本考虑和许多其他因素。所以编程的机制并不难，学习一门新语言并不是真正的挑战，而是开发一个由简单、可维护、有文档记录的代码组成的好的解决方案才是挑战。

Brian Zoebisch, Back End Developer

Brian Zoebisch，后端开发者

So my latest gig was a programmers nightmare.
I was hired in to essentially port a back end that was previously running microservices which populated endpoints with JSON. The previous programmers had written the system over the course of something over a year, with some of these endpoints being adjusted over that entire span. My guess is tweaks to the data model once issues arose from users manipulating the data.
If you have never heard of an Enterprise Resource Planning (ERP) system, basically it encompasses all of the business in data form. Everything is in there from employee and HR data, orders, invoices, bill of materials (BOMs), production schedules, shipping schedules and a bunch of other information. The concept is the foundation for modern production systems.
The company had software which pulled the data from the servers and then aggregated said data into digestible format on a Swift frontend. So Apple TVs were all over the business, producing up-to-date information on financial information, production logistics and shipping logistics…along with a few other tidbits. All of this was essentially in a particular format as a matter of course from the particular ERP system.

所以我最近的现场演示简直是一场噩梦。
我被雇来主要是移植一个后端，该后端以前运行的是用JSON填充端点的微服务。之前的程序员在一年多的时间里编写了这个系统，其中一些端点在整个时间跨度内进行了调整。我的猜测是，一旦用户操作数据出现问题，就会对数据模型进行调整。（注：JSON，基于 jaxcript 语言的轻量级的数据交换格式（jaxcript obxt Notation））
如果你从未听说过企业资源规划（ERP）系统，那么它基本上以数据形式包含所有业务。从员工和人力资源数据、订单、发票、物料清单（BOM）、生产计划、发货计划和一系列其他信息，一切都在那里。这一概念是现代生产系统的基础。
该公司拥有从服务器中提取数据的软件，然后在Swift前端将这些数据聚合成可消化的格式。因此，苹果电视遍布整个行业，生产有关财务信息、生产物流和运输物流的最新信息等等以及其他一些细小方面。所有这些基本上都是特定ERP系统中的特定格式。 （注：Swift，苹果公司发布的一种支持多编程范式和编译式的编程语言）

My job was to replicate these methods, with a brand new ERP system, with a few extremely important caveats. For starters, the company migrated to three tier orders from two tier, which dramatically increases the complexity of the problem. Additionally since there were no more 1-to-1 variable translations, another layer of complexity was added to the problem because in order to reproduce the data sets, the new systems variables had to be matched with the old. Another issue was the company decided to go with a “cloud” based system, I put the cloud in quotes because it essentially was a very obscure and limited system with the data access being “data sources” which were not documented anywhere. The only thing “cloud” about it was the SQL calls. There was an existing set of hand tailored data sources which were created for individual companies for their particular needs, yet were accessible to anyone with an account with the company.

我的工作是用一个全新的ERP系统复制这些方法，并附带一些极其重要的注意事项。首先，该公司从两级订单转移到三级订单，这大大增加了问题的复杂性。此外，由于没有更多的1对1变量转换，问题又增加了一层复杂性，因为为了重现数据集，新系统变量必须与旧系统变量匹配。另一个问题是该公司决定使用基于“云”系统，我引用了云，因为它本质上是一个非常模糊和有限的系统，数据访问是“数据源”，没有任何地方记录。关于“云”的唯一一件事就是SQL调用。有一套现有的手工定制数据源，是为个别公司的特殊需要而创建的，但任何拥有该公司账户的人都可以访问这些数据源。
原创翻译：龙腾网 http://www.ltaaa.cn 转载请注明出处

For instance, if I wanted a data source which produced my orders and shipments with lead times for the shipments, the company could make the data call (essentially a complex SQL call which was hidden behind an XML data interface) for about 5k. So basically you would make a “call” with XML parameters and the data source would pull the data from their servers and produce the results, as requested. This data source, would then be available to anyone, but since it was custom, this also meant that you might be getting the wrong data back and not know it. Variable names were not consistent in their meaning. For instance a variable called “ship date” might mean “estimated ship date”, “desired ship date” or “actual ship date”, but there was no way to tell other than by working through real data…a little more on that below.

例如，如果我想要一个数据源来生成我的订单和发货，并提供发货的交付周期，该公司可以进行大约5k的数据调用（基本上是一个隐藏在XML数据接口后面的复杂SQL调用）。因此，基本上，你可以使用XML参数进行“调用”，数据源将从其服务器中提取数据，并根据请求生成结果。然后，任何人都可以使用此数据源，但由于它是自定义的，这也意味着您可能会获取错误的数据，而不知道它。变量名的含义不一致。例如，一个名为“发货日期”的变量可能意味着“预计发货日期”、“期望发货日期”或“实际发货日期”，但除了通过实际数据进行操作之外，没有其他方法可以判断，下面将对其进行详细说明。

The company wanted to build their own business logic off of existing data sources. This meant that in order for me to retrieve the aggregate data sets I had to figure out which calls would produce the data I needed. All of this was on an undocumented system, so basically it was all trial and error after making my best engineering guess.
I want to talk about the most difficult part of this…and that was…there was no data in the system. The company had not even begun to figure out how they were going to use the system! This meant that at any given future moment, the very foundation of the architecture might be completely incorrect. Outside of concrete rules, you make your best guess. Now to my credit, when the software went live, many of the data aggregations were perfectly correct. Others however, would morph on a daily basis as user began to do all sorts of ad-hoc methods of data entry. And this problem was well beyond the scope of being able to filter out bad data. There were just too many unknowns.

该公司希望在现有数据源的基础上构建自己的业务逻辑。这意味着，为了检索聚合数据集，我必须找出哪些调用将生成所需的数据。所有这些都是在一个没有文件记录的系统上进行的，所以基本上，在我做出了最好的工程猜测之后，这一切都是反复试验。
我想谈谈最困难的部分，那就是系统中没有数据。该公司甚至还没有开始弄清楚他们将如何使用该系统！这意味着，在任何给定的未来时刻，架构的基础可能是完全错误的。在具体规则之外，你可以做出最好的猜测。值得赞扬的是，当软件上线时，许多数据聚合都是完全正确的。然而，随着用户开始使用各种特殊的数据输入方法，是否会在每天的基础上发生变化。这个问题远远超出了过滤坏数据的范围，有太多的未知情况。

I say all of this to bring up a real life example of something far more difficult than programming. The programming was the easy (and for the most part, fun) part of this gig. My fingers would fly once I knew what calls I actually needed to get the desired results. But this didn’t happen until the point where the system went live. What was harder than the programming was envisioning an accurate and efficient method of retrieving the data (as the company paid per call volume), prior to actually having data….with no roadmap to what data would be returned by the system!
I remember arguing with the manager because he stubbornly refused to listen to what the actual underlying issues were. I learned early on in the process of building out these data calls that there was an inherent (and inconsistent by size returned) limitation on the size of the data set returned. For some the calls would return 1000 rows, for others, 500, so on and so forth. I discovered this about a month prior to going live and said this issue would be a potentially very serious obstacle to aggregate data sets.

我说这一切是为了提出一个比编程困难得多的现实例子。编程是这场演示中最简单的部分（大部分是有趣的部分）。一旦我知道要得到想要的结果，我的手指就会飞起来。但直到系统投入使用时，这种情况才发生。比编程更难的是，在实际拥有数据之前，设想一种准确高效的数据检索方法（如公司按通话量付费）。没有关于系统将返回哪些数据的路线图！
我记得和经理争论过，因为他固执地拒绝倾听真正的根本问题是什么。在构建这些数据调用的早期过程中，我了解到对返回的数据集的大小有一个固有的限制（并且返回的数据大小不一致）。有些调用返回1000行，有些调用返回500行，以此类推。我在上线前大约一个月发现了这个问题，并表示这个问题可能会成为聚合数据集的一个非常严重的障碍。
原创翻译：龙腾网 http://www.ltaaa.cn 转载请注明出处

I also offered a possible solution which was a modified binary tree solution, based on the time delta being shortened whenever the system would return too large a data set. This all fell on deaf ears. I even said that in the case of pre-filtering data (you could request data by start date and end date in many cases) there was a hard limit which might be create serious issues, and that was the smallest time delta for pre-filtering was one day. This meant that if you requested say, all of the orders on a given day and there were more than 1,000 record in the system….well then you would never be able to get all of your data for that day. The response I got was “That will never happen”. Well, guess what happened? Since they were uploading mass orders into the system, they put more than 1,000 into the system on one day. There was no fixing it other than actually owning up and paying for a custom data call.
The long-winded story is to manifest another very important point. In reference to the question, being able to deal with people, especially managers, which do not see the bigger picture and therefore are prone to falling back into the age-old arrogant and ignorant viewpoint of “why isn’t this working”? Yup dealing with that nonsense, is waaaay more difficult than the actual programming.

我还提供了一种可能的解决方案，这是一种改进的二叉树结构解决方案，基于每当系统返回太大的数据集时，时间增量就会缩短。这一切都被置若罔闻。我甚至说过，在预过滤数据的情况下（在许多情况下，您可以按开始日期和结束日期请求数据），存在一个硬限制，这可能会造成严重问题，即预过滤的最小时间差为一天。这意味着如果你要求，比如说，某一天的所有订单，系统中有1000多条记录。那么你就永远无法获得那天的所有数据了。我得到的回应是“这永远不会发生”。猜猜发生了什么事？由于他们正在向系统上传大量订单，他们一天就向系统发送了1000多份订单。除了实际承认并支付一个定制的数据通话费用之外，没有别的办法可以解决这个问题。
这个冗长的故事是为了表明另一个非常重要的观点。在这个问题上，要善于与人打交道，尤其是与管理者打交道，因为他们看不到大局，因此容易陷入古老的傲慢和无知的观点，即“为什么这样不行?是的，应付这些废话比实际编程更难。

Chris Schneider, Software Developer

Chris Schneider，软件开发人员
原创翻译：龙腾网 http://www.ltaaa.cn 转载请注明出处

And yet another perspective:
You’ve started work at a new company. This company is 10 years old. They have 10 years worth of proprietary code. Some of it’s good, some (more?) of it’s nasty and overly complex. You still need to be able to use it.
You’ve now got to take your client’s requirements and implement them using this enormous codebase that many people have worked on over the years.
That’s it! Good luck.

还有另一种观点:
你在一家新公司开始工作。这家公司已经成立10年了。他们有10年的专有代码。有些是好的，有些(更多)是令人讨厌和过于复杂的。你仍然需要能够使用它。
现在，你必须获取客户的需求，并使用许多人多年来开发的庞大代码库来实现它们。
就是这样!祝你好运。

Md Saiful Islam, Lecturer at Bangladesh University of Engineering and Technology (2017-present)

Md Saiful Islam，孟加拉国工程技术大学讲师(2017-至今)

That depends actually. Depends on how much you like to think logically. At first things seem to be a little bit weird. But if you are good at logic, reasoning, math, you will start to understand the syntax with your instinct very quickly.
Otherwise, you need to continuously put your efforts until it starts to make sense. Once you get comfortable, it gets easier.
On a different note, learning a programming language and being a good programmer is a different thing. You need years of dedication and effort to be a good programmer.

实际上这取决于你有多喜欢逻辑思考。一开始，事情似乎有点奇怪。但如果你擅长逻辑、推理和数学，你就会很快开始凭直觉理解语法。
否则，你需要不断地努力，直到它开始有意义。一旦你适应了，就会变得更容易。
另一方面，学习一门编程语言和成为一名优秀的程序员是两码事。要成为一名优秀的程序员，你需要多年的奉献和努力。

Marcelo Sztainberg, Associate Professor at Northeastern Illinois University

Marcelo Sztainberg，东北伊利诺伊大学副教授

Most people trying to learn programming are trying to learn two things at the same time:
How to solve problems in an algorithmic way.
Learn how to “translate” step by step instructions into a particular language (“coding”).
For “Algorithmic problem solving” you need to train your brain to approach a problem in a systemic way:
What is the problem that you are trying to solve
What are the “inputs” for the problem. These are things that you either know before hand (constants) or that you should ask at the beginning of the algorithm (variables)
What is the expected “output”. This is not necessarily what the answer should be but how it should look like. If my problem deals with an arithmetic computation I expect a “number” as an answer. If it deals with finding a word inside of an article the expected answer is a “word”
Lastly, the hard part, how to partition the problem into steps (classes, methods/functions) that can be further partitioned into more specific steps (instructions). This is done mostly by solving first simple problems and increasing the complexity as you become better or faster at getting the best solution for it.

大多数试图学习编程的人都试图同时学习两件事：
如何用算法解决问题。
学习如何将一步一步的指令“翻译”成特定的语言（“编码”）。
对于“算法问题解决”，你需要训练你的大脑以系统的方式处理问题：
你想解决的问题是什么？
问题的“输入”是什么。这些都是你事先知道的（常数），或者你应该在算法开始时问的（变量）
预期的“产出”是什么。答案不一定是这样的，而是应该是这样的。如果我的问题涉及算术计算，我希望答案是“数字”。如果要在文章中找到一个单词，那么预期的答案是“单词”
最后是难点部分，如何将问题划分为步骤（类、方法/函数），这些步骤可以进一步划分为更具体的步骤（指令）。这主要是通过解决第一个简单的问题来实现的，并且随着你更好或更快地获得最佳解决方案而增加复杂性。

For “coding” in a particular language you just need to learn:
A language vocabulary: what key words can be used to represent the set of instructions that you came up with in your algorithmic approach.
Syntax: how to put these instructions and methods together. Some languages require to separate instructions using a semicolon “;” others separate blocks of instructions with curly brackets “{}”, and more.
The language environment. What tool(s) do you need to write/edit your code, how to go from code to a “running program” and how and where to “run” this program.
Unfortunately most courses try to teach people both skills at the same time, generating confusion and anxiety. That’s why most people learn programming by “doing”/“working on problems”. They let their brains sort out how much time to put on the algorithmic thinking and how much to put on coding.
Every programmer will tell you that learning a second programming language is “way easier” than learning the first one. You just spend time learning a new “language” and focus on coding.
If you are new to it, start with a course on problem solving before you can learn how to code… or find an online tutorial (or a book) with plenty of examples and focus on the way each problem is approached before thinking about “vocabulary” and “syntax”

对于特定语言的“编码”，你只需要学习：
语言词汇：什么关键词可以用来代表你在算法方法中提出的一组指令。
语法：如何将这些指令和方法组合在一起。有些语言要求用分号分隔指令”另一些则用大括号“{}”等分隔指令块。
语言环境：你需要什么工具来编写/编辑代码，如何从代码转到“正在运行的程序”，以及如何以及在何处“运行”该程序。
不幸的是，大多数课程试图同时教授人们这两种技能，从而让人产生困惑和焦虑。这就是为什么大多数人通过“做”/“解决问题”来学习编程。他们让自己的大脑决定花多少时间进行算法思考，花多少时间进行编码。
每个程序员都会告诉你，学习第二种编程语言比学习第一种编程语言“容易得多”。你只需要花时间学习一门新的“语言”，并专注于编码。
如果你是新手，在学习如何编写代码之前，先上一门关于解决问题的课程或者找一本有大量例子的在线教程（或一本书），在思考“词汇”和“语法”之前，先关注每个问题的处理方式。

Oliver L, former Digital Creative at Jibjub (2000-2018)
I will give you two examples from my personal experience.
1. My first taste of programming was with an abandoned computer in a storage room at high school. It came with BASIC, and an coding recipe book of sorts with a simple space invaders game that you could type in manually and play.
Even though the code was complex, I found it was super easy to learn! I pretty soon was playing around with the code, making modifications and upgrades, adding different sounds… This is what set me off on my own programming journey, and I learned all sorts of other languages simply by the will to make these little games, or just make things move on the screen.

我将根据我的个人经验给你们举两个例子。
我第一次尝试是在高中的一个储藏室里用一台废弃的电脑编程。它带有BASIC语言，还有一本编程手册，里面有一个简单的太空入侵者游戏，你可以手动输入并玩。
尽管代码很复杂，但我发现它非常容易学习！我很快就开始玩弄代码，进行修改和升级，添加不同的声音，这就是我开始自己编程之旅的原因，我学习了其他各种语言，只是出于制作这些小游戏的意愿，或者只是让屏幕上的东西移动。

2. Fast forward ten years, I applied to a C++ and OO course to up my game. Pretty standard classroom environment but the teacher had no real passion for it, he was just going through the motions and teaching prepared content. We sit down and start the exercises all of which involve printing letters on a screen in different orders. Very very dry.
This was so incredibly hard to learn. Was it C++ and the complexity of the new language? No… I understood all the concepts involved… It was just that the spark that got me to that point had been completely snuffed out. I had no reason to learn anymore, I had no desire to print these stupid letters on the screen.

时间快进十年，我应用了C++和面向对象程式设计课程来提高我的游戏水平。相当标准的课堂环境，但老师对它没有真正的热情，只是走走过场，教授准备好的内容。我们坐下来开始练习，所有的练习都涉及到在屏幕上以不同的顺序打印字母，非常非常干燥。
这太难学了，是C++和新语言的复杂性吗？不，我理解所有涉及的概念，只是让我达到这一点的火花已经完全熄灭了。我没有理由再学习了，我也不想在屏幕上打印这些愚蠢的字母。

I eventually started lecturing OO programming and game design myself, and these experiences really stuck with me. I was always encouraging my students to find something they wanted to do, even if it was on the fringes of the course requirements… I found that if and when that happened, if they could find a reason to code, then the actual coding part came almost naturally… As if it was always there just waiting for them to find it, rather than this long list of boring methods and abstractions that had to be memorised.
So here I am with two examples of why learning programming is both easy sometimes and very hard others. If you are still asking yourself why is learning programming hard, maybe instead ask yourself why learning to do the thing you love seems so easy (and maybe bring some of that over into what you’re doing with code).

我最终开始自己讲授面向对象编程和游戏设计，这些经历让我难以忘怀。我总是鼓励我的学生找到他们想做的事情，即使是在课程要求的边缘，我发现，如果发生了这种情况，如果他们能找到一个编码的理由，那么实际的编码部分几乎是自然而然地出现的，好像它总是在那里等待他们找到它，而不是一长串无聊的方法和必须记住的抽象内容。
这里我举了两个例子来说明为什么学习编程有时很容易，有时却很难。如果你仍然在问自己为什么学习编程很难，那么不妨问问自己，为什么学习做你喜欢的事情看起来很容易（也许可以把其中的一些东西带到你用代码做的事情中去）。

Mike Klaene, former IT at SEPTA

Mike Klaene，前SEPTA的IT人员
原创翻译：龙腾网 http://www.ltaaa.cn 转载请注明出处

Almost anyone can learn how to program.
Some folks seem to have the ability to more easily learn programming.
Much like anyone can play scales on a piano or draw a circle, being a concert pianist or the next Renoir is not likely.

几乎每个人都能学会如何编程。
有些人似乎有能力更容易地学习编程。
就像任何人都能在钢琴上弹奏音阶或画圆圈一样，成为职业钢琴演奏家或下一个雷诺阿就不太可能。