
Korean: 
안녕하세요, 저는 Carrie Anne입니다. 
컴퓨터 과학 특강에 오신 것을 환영합니다!
이전에 강의에서 정렬에 대해 많이 이야기했었는데요, 종종 숫자 목록을 정렬하는 코드는 10줄이면 되기 때문에
한명의 프로그래머가 충분히 쉽게 사용할 수 있습니다.
또한, 특별한 도구가 필요하지 않을 정도로  짧습니다. 
- 여러분이 메모장에서도 할수 있을 정도에요.
또한, 특별한 도구가 필요하지 않을 정도로  짧습니다. 
- 여러분이 메모장에서도 할수 있을 정도에요.
정말요!
그러나 정렬 알고리즘은 프로그램이 아닙니다.
훨씬 더 큰 프로그램의 작은 부분과 같습니다.
그러나 정렬 알고리즘은 프로그램이 아닙니다.
훨씬 더 큰 프로그램의 작은 부분과 같습니다.
예를 들어, Microsoft Office는 대략
4천만 줄의 코드를 가지고 있습니다.
4천만이나!
그것은 혼자서 알아내고 쓰기에는 너무 크죠.
이러한 거대한 프로그램을 만들기 위해서, 
프로그래머들은 일련의 도구와 실습을 사용합니다.
종합하면, 이것들은 소프트웨어 공학의 한
분야를 형성합니다.
이것은 엔지니어인 Margaret Hamilton이 만든 용어입니다.
그녀는 NASA가 달에 대한 아폴로 미션을 수행하던 
 중 문제가 발생하지 않도록 도운 사람이었습니다.
그녀는 한 번은 이렇게 설명했습니다. " 이것은 신경치료와도 같아요. 당신은 끝까지 기다렸지만,"
"그것은 미리 할 수 있었던 일이 아니었습니다."
"그것은 예방용 건강관리와 같지만 그것은
예방용 소프트웨어입니다. "

Portuguese: 
Oi, eu sou Carrie Anne, e bem-vindo ao CrashCourse Computer Science!
Então, nós falamos muito sobre ordenação nessa série, e frequentemente sobre códigos para ordenar uma lista de números
talvez tenha apenas dez linhas, o que é fácil o suficiente para um único programador escreve-lo.
Além do mais,  é curto o suficiente para você não precisa de nenhuma ferramenta especial.
- Você poderia fazer
no Notepad.
Sério!
Mas, um algoritmos de ordenação não é um programa, é apenas uma pequena parte de um
programa maior.
Por exemplo, Microsoft Office tem mais ou mentos 40 milhões de linhas de código.
40 MILHÕES!
Isso é de longe muito grande para qualquer pessoa projetar e programar sozinha!
Para construir grandes programas como esse, programadores utilizam um conjunto de ferramentas e práticas.
Colocadas junto, elas formam a disciplinas de engenharia de software - um temo estabelecido
pela engenheira Margaret Hamilton, que ajudou a NASA a evitar sérios problemas durante as missões
Apollo para a lua.
Ela explicou uma vez dessa forma: "É como se fosse um canal na raiz do dente: você esperou até
a ultima consequência, [mas] há coisas que você poderia ter feito de ante mão.
é parecido com plano de saúde preventivo, mas é software preventivo".

English: 
Hi, I’m Carrie Anne, and welcome to CrashCourse
Computer Science!
So we’ve talked a lot about sorting in this
series and often code to sort a list of numbers
might only be ten lines long, which is easy
enough for a single programmer to write.
Plus, it’s short enough that you don’t
need any special tools – you could do it
in Notepad.
Really!
But, a sorting algorithm isn’t a program;
it’s likely only a small part of a much
larger program.
For example, Microsoft Office has roughly
40 millions lines of code.
40 MILLION!
That’s way too big for any one person to
figure out and write!
To build huge programs like this, programmers
use a set of tools and practices.
Taken together, these form the discipline
of Software Engineering – a term coined
by engineer Margaret Hamilton, who helped
NASA prevent serious problems during the Apollo
missions to the moon.
She once explained it this way: “It’s
kind of like a root canal: you waited till
the end, [but] there are things you could
have done beforehand.
It’s like preventative healthcare, but it’s
preventative software.”

Chinese: 
(｡･∀･)ﾉﾞ 我是Carrie Anne 欢迎收看10分钟速成课：计算机科学
我们已经讲了很多排序的知识
也写了一些 10 行左右的排序代码
这些代码对单个程序员来说很容易写
另外，这些代码很短，你不必用特定的工具写
- 甚至"记事本"就够了
讲真！
但排序算法不会独立存在
它更可能是大项目中的一小部分
例如，微软的 Office 大约有 4000 万代码
4000 万！
这种量级一个人是不可能做到的
为了构建大型程序，程序员会使用各种工具和方法。
这些综合起来形成了“软件工程”这个学科
- 这个名词由工程师 Margaret Hamilton 创造
她曾经在阿波罗登月计划中帮助 NASA 避免了严重的问题
她这样解释：
“有点像牙根管治疗一样：你拖到最后才去做
但有些事可以事先做好
有点像预防性体检
不过是预防性软件”

Korean: 
 
12강에서 얘기했었듯이,
큰 프로그램을 작은 함수들로 쪼개면
사람들은 동시에 일할 수 있습니다.
그들은 전체에 대해 걱정할 필요가 없습니다. 
단지 그들이 작업하고 있는 함수에만 집중했습니다.
따라서, 만약 여러분이 정렬 알고리즘을 작성하고 있다면,
정렬이 효율적이고 적절하게 되었는지만 
확실하게 하면 됩니다.
그러나, 코드를 함수로 묶는 것 만으로는 
충분하지 않았습니다.
Microsoft Office는 아마 수십만 개의 함수를 가지고 
있을 것입니다.
그것은 4천 만가지를 다루는 것 보단 낫지만, 
여전히 너무 많습니다.
한 사람이나 팀이 관리 할 수있는 "것"으로는요.
해결책은 함수를 계층구조로 패키지화하여 관련된 코드를 "객체"로 모으는 것입니다.
해결책은 함수를 계층구조로 패키지화하여 관련된 코드를 "객체"로 모으는 것입니다.
예를 들어, 자동차의 소프트웨어에는
크루즈 컨트롤과 관련된 여러 기능을 가지고 있습니다.
- 속도 설정, 속도 올리기 또는 내리기, 크루즈 컨트롤을 
정지하는 것과 같은 기능들을 가지고 있을 것입니다.
모두 관련되어 있으므로 이들을 통합된 크루즈 
컨트롤 객체로 포장 할 수 있습니다.
그러나 이게 끝이 아닙니다.
크루즈 컨트롤은 엔진 소프트웨어의 한 부분일 뿐입니다.
그러나 이게 끝이 아닙니다.
크루즈 컨트롤은 엔진 소프트웨어의 한 부분일 뿐입니다.
점화 플러그 점화, 연료 펌프 및 라디에이터를  제어하는 함수 셋트도 있을 것입니다.
점화 플러그 점화, 연료 펌프 및 라디에이터를  제어하는 함수 셋트도 있을 것입니다.

English: 
INTRO
As I mentioned in episode 12, breaking big
programs into smaller functions allows many
people to work simultaneously.
They don’t have to worry about the whole
thing, just the function they’re working on.
So, if you’re tasked with writing a sort
algorithm, you only need to make sure it sorts
properly and efficiently.
However, even packing code up into functions
isn’t enough.
Microsoft Office probably contains hundreds
of thousands of them.
That’s better than dealing with 40 million
lines of code, but it’s still way too many
“things” for one person or team to manage.
The solution is to package functions into
hierarchies, pulling related code together
into “objects”.
For example, car’s software might have several
functions related to cruise control, like
setting speed, nudging speed up or down, and
stopping cruise control altogether.
Since they’re all related, we can wrap them
up into a unified cruise control object.
But, we don’t have to stop there, cruise
control is just one part of the engine’s
software.
There might also be sets of functions that
control spark plug ignition, fuel pumps, and
the radiator.

Portuguese: 
Introdução
Como mencionei no episódio 12, quebrar grandes programas em funções pequenas permite que muitas
pessoas trabalhem simultaneamente.
Eles não tem que se preocupar com todas as coisas, apenas a função que eles estão trabalhando.
Então, se você é designado para escrever um algoritmo de ordenação, você apenas precisa assegurar que ele ordena
apropriadamente e eficientemente.
Entretanto, mesmo colocando o código em funções, não é suficiente.
Microsoft Office provavelmente contem centenas de milhares delas.
Isso é melhor que lidar com 40 milhões de linhas de código, mas ainda continua sendo muitas
"coisas" para uma pessoa ou time gerenciar.
A solução é colocar as funções em uma hierarquia, agrupando códigos relacionados juntos
dentro de "objetos".
Por exemplo, o software de um carro deve ter muitas de funções relacionadas ao controle de cruzeiro, como
definir a velocidade, variar a velocidade para cima ou para baixo e parar o controle de cruzeiro, tudo junto
Desde que são todos relacionados, nós podemos empacota-los em um único objeto de controle de cruzeiro
Mas, nós não temos que parar por aqui, controle de cruzeiro é apenas uma parte do software do motor.
Devem haver também conjuntos de funções que controlam a ignição da vela, a bomba de combustível e o radiador.

Chinese: 
正如在第 12 集中提到的
把大项目分解成更小的函数  可以让许多人同时工作
他们不用操心整个项目
只要关心他们的函数就好了
因此，如果你的任务是写一个排序算法
你只需要确保它排序高效正确就可以了
然而，仅把代码打包进函数是不够的
只是这样做的话，微软的 Office 可能有数十万个函数
这虽然比处理 4000 万行代码要好一些
但对于单个程序员或团队来说还是太多了
解决办法是把函数打包成层级分明的体系
将相关代码合并为“对象”（objects）
例如，汽车软件中，可能有若干个和定速巡航相关的函数
如设定速度，加减速度，中断巡航定速等等
由于这些函数都是相关的
可以包装成一个“定速巡航对象”
但是我们不会就此止步
“定速巡航”只是引擎软件的一部分
其他可能还有 "火花塞点火"函数
"燃油泵"函数 和 "散热器"函数

Portuguese: 
Então não podemos criar um objeto "pai" Motor que contem tudo desses objetos "filhos".
Além dos "objetos" filhos, o motor deve possuir suas "próprias" funções
Você quer ser capaz de liga-lo e desliga-lo por exemplo.
Ele também terá suas próprias variáveis, como quantas milhas o carro já viajou.
Geralmente, objetos podem conter outros objetos, funções e variáveis.
E obviamente, o motor é apenas uma parte do objeto carro.
Há também a transmissão, rodas, portas, janelas, etc.
Agora, como um programador, se eu quero definir o controlo de cruzeiro, eu navego pela hierarquia do objeto,
dos objetos mais externos para os mais profundos.
Eventualmente, Eu alcanço a função que quero para disparar: "Car, então Engine, então CruiseControl
então setCruisespeed para 55".
linguagens de programação muitas vezes usam algo equivalente a sintaxe mostrada aqui.
A ideia de colocar unidades funcionais dentro do objetos aninhados é chamado de programação orientada a objeto.
Isso é muito similar ao que nós temos feito ao longo de toda a série: ocultar a complexidade encapsulando
detalhes de baixo nível em componentes de ordem superior.
Antes nós empacotamos coisas como circuitos de transistores em portas logicas de alto nível.
Agora estamos fazendo a mesma coisas com software.

Chinese: 
因此我们可以创建一个“父对象”（引擎对象）
包含所有“子对象”
除了子对象之外
“引擎对象”可能有自己的函数
比如 开启或关闭引擎
对象也有自己的变量
比如汽车已经行驶了多少英里
对象可以包含其它对象，函数和变量
当然，“引擎对象”只是“汽车对象”的一部分
“汽车对象”还包括传动装置，车轮，车门，车窗等等
现在，作为程序员，如果我想对定速巡航进行设置
我需要向下浏览对象层级
从最外层对象一层层的深入，直到找到我需要的
最后找到想执行的函数：
Car.Engine.CruiseControl.setCruiseSpeed(55)
编程语言经常用类似的语法包装对象
把函数打包成对象的思想叫
“面向对象编程”
这种思想贯穿这个系列：
把底层细节封装成组件来隐藏复杂度
之前我们把晶体管电路  打包成了抽象层级更高的“布尔门”
现在我们对软件也做同样的事情

English: 
So we can create a “parent” Engine Object
that contains all of these “children”
objects.
In addition to children *objects*, the engine
itself might have its *own* functions.
You want to be able to stop and start it,
for example.
It’ll also have its own variables, like
how many miles the car has traveled.
In general, objects can contain other objects,
functions and variables.
And of course, the engine is just one part
of a Car Object.
There’s also the transmission, wheels, doors,
windows, and so on.
Now, as a programmer, if I want to set the
cruise control, I navigate down the object
hierarchy, from the outermost objects to more
and more deeply nested ones.
Eventually, I reach the function I want to
trigger: “Car, then engine, then cruise
control, then set cruise speed to 55”.
Programming languages often use something
equivalent to the syntax shown here.
The idea of packing up functional units into
nested objects is called Object Oriented Programming.
This is very similar to what we’ve done
all series long: hide complexity by encapsulating
low-level details in higher-order components.
Before we packed up things like transistor
circuits into higher-level boolean gates.
Now we’re doing the same thing with software.

Korean: 
그래서 우리는 "부모" 엔진 객체를 만들어 "자식"객체들을 포함시킬 수 있습니다.
그래서 우리는 "부모" 엔진 객체를 만들어 "자식"객체들을 포함시킬 수 있습니다.
자식 * 객체 * 외에도 엔진
그 자체는 그것의 * 자체 * 함수를 가질 수 있습니다.
자체 함수의 예로,
여러분은 엔진을 멈추거나 작동시킬 수 있습니다.
또한 차가 몇 마일이나 주행했는지를 나타내는 
자체 변수도 있습니다.
일반적으로, 객체는 다른 객체와 함수 및 변수를 
포함할 수 있습니다.
물론 엔진은 단지 자동차의 한 부분일 뿐입니다.
변속기, 바퀴, 문, 창문 등도 자동차의 부분이죠.
이제 프로그래머로서 만약 크루즈 컨트롤을 
설정하고 싶다면,
객체를 조정하여  가장 바깥 쪽 객체에서 더 깊숙이 중첩 된 객체 계층까지 탐색합니다.
결국 조정하고 싶은 기능에 도달해서 " 차, 엔진, 크루즈 컨트롤, 그리고 크루즈 스피드를 55로 설정" 합니다.
결국 조정하고 싶은 기능에 도달해서 " 차, 엔진, 크루즈 컨트롤, 그리고 크루즈 스피드를 55로 설정" 합니다.
프로그래밍 언어는 종종 여기 표시된 
구문과 같은 것들을 사용합니다.
기능 단위를 중첩된 객체로 묶는 것을 
객체 지향 프로그래밍이라고합니다.
이것은 우리가 앞선 강의에서 했던 것과 매우 비슷합니다.
고차원 구성 요소에 하위 수준의 세부 정보를 캡슐화하여
복잡성을 숨기는 것이죠!
이전에 우리는 트랜지스터 회로를 상위 수준의 
논리게이트로 묶었습니다.
지금 우리는 소프트웨어로 똑같은 일을하고 있습니다.

Chinese: 
又提升了一层抽象！
将一个大型软件（如汽车上的软件）
拆成一个个函数单元，适合团队合作
一个团队负责定速巡航系统
团队中的一位程序员负责其中一些函数
这和建造摩天大楼相似
有电工装电线
管道工配管子
焊接工焊接
绘图师绘画
还有成百上千的人在修筑外围
他们同时在不同岗位工作
各尽其能
直到某天，完成一整栋楼的建设
现在回到定速巡航的例子...
它的代码要用到引擎软件其它部分的函数
来保持车速不变
“定速巡航”团队不负责这部分代码
是另一个团队负责编写。
因为是其他团队写的代码，
所以"定速巡航"团队需要文档帮助了解代码
以及“应用程序编程接口”
-简称“API”

English: 
Yet again, it’s a way to move up a new level
of abstraction!
Breaking up a big program, like a car’s
software, into functional units is perfect
for teams.
One team might be responsible for the cruise
control system, and a single programmer on
that team tackles a handful of functions.
This is similar to how big, physical things
are built, like skyscrapers.
You’ll have electricians running wires,
plumbers fitting pipes, welders welding, painters
painting, and hundreds of other people teeming
all over the hull.
They work together on different parts simultaneously,
leveraging their different skills.
Until one day, you’ve got a whole working
building!
But, returning to our cruise control example…
its code is going to have to make use of functions
in other parts of the engine’s software,
to, you know, keep the car at a constant speed.
That code isn’t part of the cruise control
team’s responsibility.
It’s another team’s code.
Because the cruise control team didn’t write
that, they’re going to need good documentation
about what each function in the code does,
and a well-defined Application Programming
Interface -- or API for short.

Portuguese: 
De novo, isso é uma forma de mover para um novo nível de abstração!
Quebrar um grande programa, como o software de um carro em unidades funcionais é perfeito para equipes.
Uma equipe deve ser responsável pelo sistema controle de cruzeiro e um único programador naquela
equipe cuida de um punhado de funções.
Isso é similar a como grande coisas físicas são construídas, como arranha-céus.
Você terá eletricistas passando fios, encanadores encaixando tubos, soldadores soldando, pintores
pintando e centenas de outras pessoas repletas de tarefas
Eles trabalham juntos em diferentes partes simultaneamente, tirando proveito de suas diferentes habilidades.
Até que um dia, você tem um edifício inteiro funcionando!
But voltando para o nosso exemplo de controle de cruzeiro... o código dele fará uso de funções
em outras partes do software do motor, para, você sabe, manter o carro em velocidade constante.
Esse código não é parte da responsabilidade da equipe de cruzeiro.
Isso é o código de uma outra equipe.
Por não ter escrito o codigo o time do controle de cruzeiro vai precisar de uma boa documentação
sobre o que cada função no código faz e uma Interface de Programação de Aplicação [Application Programming Interface] -- ou API para abreviar -- bem delimitada.

Korean: 
다시 한번 말하지만, 그것은 새로운 레벨의 추상화로 
가는 길 입니다!
새로운 레벨의 추상화~!
자동차 소프트웨어와 같이 큰 프로그램을 기능적 단위로 분해는 것은 팀으로 작업하기에 완벽합니다.
자동차 소프트웨어와 같이 큰 프로그램을 기능적 단위로 분해는 것은 팀으로 작업하기에 완벽합니다.
한 팀이 크루즈 제어 시스템에 책임이 있고 팀원 중 
한 프로그래머는 몇 가지의 기능을 다룰 것입니다.
한 팀이 크루즈 제어 시스템에 책임이 있고 팀원중 
한 프로그래머는 몇 가지의 기능을 다룰 것입니다.
이것은 크고 물리적인 고층 빌딩이 
건설되는 방식과 비슷합니다.
전기 기사는 전선을 달고, 배관공은 파이프를 설치하고, 용접공은 용접을, 도장공은 페인팅을 할 것입니다.
그리고 , 수백 명의 다른 사람들이 
선체 전체에 퍼져 있습니다.
그들은 서로 다른 부분에서 각각의 기술을 활용하여 
동시에 작업합니다.
언젠가는, 전체 건물이 완성되겠죠!
그러나, 크루즈 컨트롤 예제로 다시 돌아와보면,
알다시피, 코드는 엔진 소프트웨어의 다른 부분에서 함수를 사용하여 차를 일정 속도로 유지해야 합니다.
이 코드는 크루즈 컨트롤팀의 책임 부분이 아닙니다.
그것은 다른 팀의 코드입니다.
크루즈 컨트롤팀이 그 코드를 작성하지 않았기 때문에
각 코드의 기능이 무엇인지, 잘 정의된 API (응용 프로그램 인터페이스)에 대한 좋은 문서를 필요로 할 것입니다.
각 코드의 기능이 무엇인지, 잘 정의된 API (응용 프로그램 인터페이스)에 대한 좋은 문서를 필요로 할 것입니다.

English: 
You can think of an API as the way that collaborating
programmers interact across various parts
of the code.
For example, in the IgnitionControl object,
there might be functions to set the RPM of
the engine, check the spark plug voltage,
as well as fire the individual spark plugs.
Being able to set the motor’s RPM is really
useful, the cruise control team is going to
need to call that function.
But, they don’t know much about how the
ignition system works.
It’s not a good idea to let them call functions
that fire the individual spark plugs.
Or the engine might explode!
Maybe.
The API allows the right people access to
the right functions and data.
Object Oriented Programming languages do this
by letting you specify whether functions are
public or private.
If a function is marked as “private”,
it means only functions inside that object
can call it.
So, in this example, only other functions
inside of IgnitionControl, like the setRPM
function, can fire the sparkplugs.
On the other hand, because the setRPM function
is marked as public, other objects can call
it, like cruise control.
This ability to hide complexity, and selectively
reveal it, is the essence of Object Oriented

Portuguese: 
Você pode pensar em uma API como uma forma como programadores trabalhando de forma colaborativa interagem através de várias partes do código.
Por exemplo, no objeto IgnitionControl, devem haver funções para definir a RPM do
motor, checar a voltagem das velas, como também disparar as velas individualmente.
Ser capaz de ajustar a RPM do motor é realmente útil, a equipe do controle de cruzeiro
vai precisar chamar essa função.
Mas, eles não sabem muito sobre como o sistema de ignição funciona.
Não é uma boa ideia deixa-los chamar funções que disparam as velas individualmente.
Ou o motor pode explodir!
Talvez.
A API permite que as pessoas certas acessem as funções e os dados certos.
Linguagens de programação orientadas a objetos fazer isso permitindo que você especifique se as funções são
públicas ou privadas.
Se uma função é marcada como "privada", significa que apenas funções dentro daquele objeto
podem chama-la.
Então, nesse exemplo, apenas outras funções dentro de IgnitionControl, como a função
setRPM, pode disparar as velas.
De outro lado, por causa da função setRPM ser marcada como publica, outros objetos podem chama-la,
como o controle de cruzeiro.
Essa habilidade de esconder a complexidade e seletivamente revela-la, é a essência da programação orientada a objetos,

Korean: 
API는 프로그래머가 코드의 다양한 부분에서 공동 작업하는 방식이라고 할 수 있습니다.
API는 프로그래머가 코드의 다양한 부분에서 공동 작업하는 방식이라고 할 수 있습니다.
예를 들어, 점화 제어 객체에서는,
엔진의 RPM을 설정하는 기능과
점화 플러그 전압을 확인하고, 개별 스파크 플러그를 발사 하는 기능이 있을 수 있습니다.
모터의 RPM을 설정할 수 있다는 것은 정말유용합니다. 크루즈 컨트롤 팀은 그 함수를 호출해야 합니다.
모터의 RPM을 설정할 수 있다는 것은 정말유용합니다. 크루즈 컨트롤 팀은 그 함수를 호출해야 합니다.
그러나, 그들은 어떻게 점화 시스템이 작동하는 지에 대해 많이 알지 못합니다.
개별 점화 플러그를 작동하는 함수를 호출하는 것은 
좋은 아이디어가 아닙니다.
또는 엔진이 폭발 할 수도 있습니다!
아마도요..
API를 사용하면 적절한 함수와 데이터에 대한 
적절한 접근 권한을 얻을 수 있습니다.
객체 지향 프로그래밍 언어는 함수의 공개 혹은 비공개 
사용 여부를 지정할 수 있게 하여 이를 수행합니다.
객체 지향 프로그래밍 언어는 함수의 공개 혹은 비공개 
사용 여부를 지정할 수 있게 하여 이를 수행합니다.
함수가 "비공개"로 표시된 경우, 해당 객체 내부의 함수만 호출할 수 있다는 것을 의미합니다.
함수가 "비공개"로 표시된 경우, 해당 객체 내부의 함수만 호출할 수 있다는 것을 의미합니다.
따라서 이 예에서는, IgnitionControl의  setRPM 함수처럼 내부의 다른 함수들만이
sparkplugs를 실행할 수 있습니다.
한편, setRPM 함수 공개로 표시되어 있기 때문에,
Cruise control과 같은 다른 객체가 
그것을 호출할 수 있습니다.
복잡성을 숨기고 선택적으로 그것을 드러낼 수 있는 능력은 객체 지향 프로그래밍의 본질입니다.

Chinese: 
你可以把 API 看作是程序员让多个模块协作互动的一种方式
例如在“点火控制”对象中
可能有"设置发动机转数"的函数
"检查火花塞电压"的函数
以及"点燃单个火花塞"的函数
"设置发动机的转速"非常有用
“定速巡航”团队需要用到这个函数
但他们对点火系统知之甚少
让他们调用"点燃单个火花塞"的函数不是一个好点子
引擎可能会搞炸！
可能啦..
API 允许正确的人有权使用正确的函数和数据。
"面向对象"的编程语言通过
让你指定函数的“public”或“private”来做权限设置
当函数标记为“private”时
意味着只有同一个对象的其他函数才能调用它
因此在这个例子中，只有"点火控制"对象内部的其它函数
比如 setRPM 函数
才可以调用 fireSparkplug 函数
另一方面，由于 setRPM 函数被标记为 public
其它对象可以调用它（ 比如定速巡航对象）
这种隐藏复杂性的做法，以及有选择性地暴露出一部分功能
是“面向对象编程”的本质

English: 
Programming, and it’s a powerful and popular
way to tackle building large and complex programs.
Pretty much every piece of software on your
computer, or game running on your console,
was built using an Object Oriented Programming
Language, like C++, C# or Objective-C. Other
popular “OO” languages you may have heard
of are Python and Java.
It’s important to remember that code, before
being compiled, is just text.
As I mentioned earlier, you could write code
in Notepad or any old word processor.
Some people do.
But generally, today’s software developers
use special-purpose applications for writing
programs, ones that integrate many useful
tools for writing, organizing, compiling and
testing code.
Because they put everything you need in one
place, they’re called Integrated Development
Environments, or IDEs for short.
All IDEs provide a text editor for writing
code, often with useful features like automatic
color-coding to improve readability.
Many even check for syntax errors as you type,
like spell check for code.
Big programs contain lots of individual source
files, so IDEs allow programmers to organize
and efficiently navigate everything.

Portuguese: 
e isso é uma forma poderosa e popular de abordar a construção de programas grandes e complexos.
Muitas das partes dos softwares do seu computador, ou dos jogos rodando em seu console,
foram feitas utilizando uma linguagem de programação orientada a objetos, como C++, C# ou Objective-C. Outras
linguagens "OO" populares que você pode ter ouvido são Python e Java.
É importante lembrar que o código antes de ser compilado é apenas texto.
Como eu mencionei no começo, você poderia escrever códigos no Notepad ou qualquer editor de texto antigo.
Algumas pessoas fazem isso.
Mas geralmente, desenvolvedores de software hoje em dia usam aplicações de propósito específico para escrever
programas, que integram varias ferramentas úteis para escrever, organizar, compilar e
testar códigos.
Por elas colocarem tudo que você precisa em um único lugar, são chamas de Ambiente de desenvolvimento integrado [Integrated Development Environments],
ou IDEs, abreviando.
Todas as IDEs disponibilizam um editor de texto para escrever códigos, muitas vezes com aspectos úteis como colorir
automaticamente o código para melhor legibilidade.
Muitos ainda conferem erros de sintaxe enquanto você digita, como um corretor ortográfico para código.
Programas grandes contêm vários arquivos de código fonte individuais, então IDEs permitem os programadores organizarem
e navegar por tudo de forma eficiente.

Chinese: 
用这种方式处理大型复杂项目非常有效，所以广受欢迎
计算机上几乎每个软件，或游戏主机里的每个游戏
都是用"面向对象"的编程语言做的。
比如 C++, C#, Objective-C 等
其他的流行 "OO" 语言，你可能还听过 Python 和 Java
有一点很重要：代码在编译前就只是字母而已
正如前面提到的
你可以在记事本或任何古老的文字处理器中写代码
有人确实这样做
但一般来说，现代的软件开发者会用特定的应用来编程
它集成了很多有用工具来编写，组织，编译及测试代码
因为集成了所有你需要的东西
所以它们又叫“集成开发环境”，简称 IDE
所有 IDE 都提供可以写代码的编辑器界面
以及附带一些有用的功能，如"代码高亮"来提高可读性
许多 IDE 还提供实时语法检查，如拼写检查
大型项目会包含很多源文件
IDE 可以让开发者高效的组织并浏览代码

Korean: 
그리고 그것은 크고 복잡한 프로그램을 만드는 
강력하고 대중적인 방법입니다.
여러분의 컴퓨터 또는 콘솔에서 실행되는 게임의
거의 모든 부분은,
객체 지향 프로그래밍 언어인 C ++, C # 또는 Objective-C와 같은 것들을 사용하여 작성되었습니다.
그 외 대중적인, 여러분이 들어봤을 법한 객체 지향 언어는 Python과 Java입니다.
컴파일 되기 전에 코드는 텍스트일 뿐이라는 것을 
기억하는 것이 중요합니다.
앞서 언급했듯이 여러분은 코드를 메모장이나 
워드프로세서에서 작성할 수 있습니다.
어떤 사람들은 그렇게 하기도 합니다.
하지만 일반적으로, 요즘 소프트웨어 개발자들은 프로그램을 쓰기 위한 특수 목적의 응용 프로그램을 사용합니다.
그것은 코드를 쓰고, 조직하고, 편집하고 테스트할 수 있는 많은 유용한 도구들을 통합하는 프로그램입니다.
그것은 코드를 쓰고, 조직하고, 편집하고 테스트할 수 있는 많은 유용한 도구들을 통합하는 프로그램입니다.
그들은 여러분이 필요로 하는 모든 것을 하나에 넣기 때문에, 통합개발환경(줄여서 IDE)라고 불리기도 합니다.
그들은 여러분이 필요로 하는 모든 것을 하나에 넣기 때문에, 통합개발환경(줄여서 IDE)라고 불리기도 합니다.
모든 IDE는 작문을 위한 텍스트 편집기를 제공하며,
가독성을 향상시키는 자동 컬러 코딩과 같이 종종 유용한 기능을 포함합니다.
코드의 맞춤법 검사와 같이, 입력하는 동안 
구문 오류가 있는지 대부분 확인합니다.
큰 프로그램에는 많은 개별 소스가 포함되어 있어
IDE를 사용하면 프로그래머가 모든 것을 구성하고 
효율적으로 탐색 할 수 있습니다.

Chinese: 
IDE 一般还可以直接编译代码以及运行代码
如果你正在写的一段程序奔溃了
IDE 可以定位到奔溃的那一行代码
并且提供额外信息去帮助你解决 bug
这个过程叫“调试”（debug）
调试很重要
因为大多数程序员会花 70％~80％ 时间调试，而不是纯写代码
IDE 里这些工具极大的帮助了程序员防止和发现错误
很多开发者只用一款他们喜爱的 IDE
但是说实话
VIM 才是最棒的编辑器
如果你知道怎么退出 VIM 的话
除了写代码和调试
程序员工作的另一个重要部分 是给代码写文档
文档一般写在一个叫“ README”的文件里
告诉其他程序员在深入研究代码前  先看这个
代码文档也可以以“注释”的形式出现在源代码中
注释是标注过的一段文字 （上面的示例以 /*  */ 包裹了注释）
当编译代码时，注释会被忽略掉
注释存在的唯一作用就是帮助开发者理解源代码
好的文档能帮助开发者在几个月后看自己的代码时快速理解。
而且对其他人也至关重要

English: 
Also built right into the IDE is the ability
to compile and run code.
And if your program crashes, because it’s
still a work in progress, the IDE can take
you back to the line of code where it happened,
and often provide additional information to
help you track down and fix the bug, which
is a process called debugging.
This is important because most programmers
spend 70 to 80% of their time testing and
debugging, not writing new code.
Good tools, contained in IDEs, can go a long
way when it comes to helping programmers prevent
and find errors.
Many computer programmers can be pretty loyal
to their IDEs though - but let’s be honest.
VIM is where it’s at.
Providing you know how to quit.
In addition to coding and debugging, another
important part of a programmer's job is documenting
their code.
This can be done in standalone files called
“read-me’s” which tell other programmers
to read that help file before diving in.
It can also happen right in the code itself
with comments.
These are specially-marked statements that
the program knows to ignore when the code
is compiled.
They exist only to help programmers figure
out what’s what in the source code.
Good documentation helps programmers when
they revisit code they haven’t seen for
awhile, but it’s also crucial for programmers
who are totally new to it.

Korean: 
또한 IDE에 내장 된 기능은 
코드를 컴파일하고 실행합니다.
만약 프로그램이 중단되면,
여전히 진행중인 작업이므로
IDE는 중단이 일어난 코드 줄로 되돌릴 수 있으며
종종 버그를 추적하고 수정하는 데 도움이 되는 추가 정보를 제공합니다. 이것은 디버깅이라는 프로세스입니다.
대부분의 프로그래머가 그들의 시간을 
새로운 코드를 작성하는 데에 쓰지 않고
테스트와 디버깅을 하는데에 70-80 %를 
소비하는 데 쓰기 때문에 매우 중요합니다.
IDE에 포함 된 좋은 도구는 프로그래머가 오류를 방지하고 찾을 수 있도록 도움을 줄 때 매우 유용합니다.
IDE에 포함 된 좋은 도구는 프로그래머가 오류를 방지하고 찾을 수 있도록 도움을 줄 때 매우 유용합니다.
많은 컴퓨터 프로그래머가 꽤 IDE에 충실 할 수 있습니다. 그러나 더 솔직히 말하면,
VIM 이있는 곳입니다.
그만 두는 법을 알려줍니다.
코딩 및 디버깅 외에도 다른 프로그래머의 업무에서 중요한 부분은 그들의 코드를 문서화 하는 것입니다.
코딩 및 디버깅 외에도 다른 프로그래머의 업무에서 중요한 부분은 그들의 코드를 문서화 하는 것입니다.
이것은 "read-me 's"라고 부르는 독립 실행 형 파일에서 수행 할 수 있습니다.
다른 프로그래머에게 실행하기 전에 도움말 파일을 
읽도록 지시합니다.
주석을 사용하여 코드 자체에서 
바로 발생시킬 수도 있습니다.
이들은(/*,\*) 코드가 컴파일될 때 프로그램이 무시하도록 특별히 표기된 문장입니다.
이들은(/*,\*) 코드가 컴파일될 때 프로그램이 무시하도록 특별히 표기된 문장입니다.
그들은 프로그래머가 소스 코드에서 무엇이 무엇인지 
알아낼 수 있도록 하기 위해서만 존재합니다.
좋은 문서는 프로그래머가 그들은 잠시 보지 못했던 
코드를 재 방문할 때 도움이 되지만,
완전히 그것이 새로운 프로그래머에게도 중요합니다.

Portuguese: 
Também integrada diretamente na IDE está a habilidade de compilar e executar código.
E se o seu programa falha por que ele ainda é um trabalho em progresso, a IDE pode levá-lo
de volta para a linha de código onde isso aconteceu, e muitas vezes fornecer informações adicionais para
te ajudar a rastrear e concertar o erro, que é um processo chamado de debuggar [debugging].
Isso é importante pois a maioria dos programadores gastam de 70 a 80% do seu tempo testando e
debuggando e não escrevendo código novo.
Boas ferramentas contidas nas IDEs, podem ir muito além quando elas são usadas para ajudar programadores a evitar
e encontrar erros.
Muito programadores de computador podem ser bastante leais a suas IDEs entretanto - vamos ser honestos.
Por isso VIM está onde está.
Deixando você saber quando sair.
Além de codificar e debuggar, outra importante parte do trabalho de um programador é documentar seu código.
Isso pode ser feito em arquivos avulso chamados "leia-me" que dizem para outros programadores
lerem esse arquivo antes de mergulhar no código.
Isso também pode acontecer no próprio código com comentários.
Eles são declarações com marcações especiais que o programa sabe como ignorar quando o código é compilado.
Eles existem apensa para ajudar programadores a descobrirem o que está acontecendo no código.
Uma boa documentação ajuda programadores quando eles revisitam códigos que eles não viram por
um tempo, mas isso também é crucial para programadores que são totalmente novos com ele.

Korean: 
저는 잠깐 여기서 더 기다리다가 누군가가 
아무런 증거가 없고, 주석처리 되지 않은 코드를
여러분의 컴퓨터에 투하시킨다면 그것이 "최악"이라는 것을 반복하고 싶습니다.
그리고 여러분은 문자적으로 코드가 무엇인지 이해하기 위해 한 줄씩 해석해야 할 것입니다.
정말, 부탁합니다.
그런 사람이 되지 마십시오.
설명서는 또한 코드 재사용을 촉진 합니다.
따라서 프로그래머는 끊임없이 
똑같은 일을 계속해서 반복해서 쓰는 대신,
그들이 해야 할 일을 할 수 있는 
다른 사람의 코드를 색출해냅니다.
그리고 설명서 덕분에, 코드를 읽을 필요 없이 
프로그램에서 작업할 수 있습니다.
그리고 설명서 덕분에, 코드를 읽을 필요 없이 
프로그램에서 작업할 수 있습니다.
그들이 말하는 것처럼 "문서를 읽으세요."
IDE 외에도 큰 팀이 대형 코딩 프로젝트에서 공동 작업하는 것을 돕는 또다른 중요한 소프트웨어를
소스 컨트롤, 버전 컨트롤 또는 
리비전 컨트롤이라고도 부릅니다.
대부분의 경우, Apple 또는 Microsoft와 같이 큰 소프트웨어 회사에서 프로젝트를 위한 코드는
중앙 집중화 된 서버, 코드 저장소라고 
불리는 곳에 저장됩니다.
프로그래머가 코드 부분 작업을 원할 때
코드의 내용을 확인할 수 있습니다.
도서관에서 책을 확인하는 것처럼요.
종종 이것은 IDE 안에서 바로 수행 할 수 있습니다.
그런 다음 개인용 컴퓨터에서 원하는 모든 코드를 
수정하고, 새로운 기능 추가하고,
작동하는지 테스트 할 수 있습니다.

Portuguese: 
Eu só quero tomar um segundo aqui e reiterar que é a PIOR COISA DO MUNDO quando alguém joga no seu colo
um monte de códigos não comentado e não documentado, e você literalmente tem que ir
linha por linha para entender o que o código está fazendo.
De verdade.
Não seja essa pessoa.
Documentação também ajuda no reuso de código.
Então, ao invés de ter programadores constantemente escrevendo as mesmas coisas de novo e de novo, eles
podem encontrar o código de outra que faz o que eles precisam.
Então, graças a documentação, eles podem colocar isso para funcionar em seus programas sem nem mesmo
ter que ler o código todo.
"Leia os documentos" como eles dizem.
Além das IDEs, outro importante componente de software que ajuda grandes equipes a trabalhar colaborativamente
em grandes projetos de código, é chamado Source Control [controle de fonte], também conhecido como controle de versão ou controle de revisão.
Muitas vezes, em grandes companhias de software como a Apple ou a Microsoft os códigos para os projetos são armazenados
em servidores centralizados chamados de repositório de código.
Quando um programados quer trabalhar em um pedaço de código, ele pode escolhe-lo,  como se estivesse
escolhendo um livro em uma biblioteca.
Muitas vezes, isso pode ser feito diretamente em uma IDE.
Então, eles podem editar este código todo que eles querem nos seus computadores pessoais, adicionando novos recursos
e testando se eles funcionam.

Chinese: 
我想花一秒重申一件很糟糕的事
就是别人给了你一大段代码，但没有任何注释或文档
结果你得逐行读代码，理解到底是干嘛的
我是认真的
别做那种人
文档也可以提高代码复用性
与其让程序员一遍遍地写同样的东西
他们可以直接用别人写好的代码来解决问题。
只要读文档，无需通读代码，开发者就可以达到想要的效果
"怎么用这个程序做到X"   “读文档啊”
除了 IDE，还有一个很重要的软件可以帮助团队协作大项目
“源代码管理”
也叫“版本控制”
在苹果或微软这样的大型软件公司
会把代码集中放到服务器上
叫“代码仓库”
当程序员想修改一段代码时
他们可以 check out
有点像从图书馆借书
一般这种操作可以直接在 IDE 里完成
接着，开发者可以在自己的电脑上编辑这段代码
添加新功能，测试功能是否正常

English: 
I just want to take a second here and reiterate
that it’s THE WORST when someone parachutes
a load of uncommented and undocumented code
into your lap, and you literally have to go
line by line to understand what the code is
doing.
Seriously.
Don’t be that person.
Documentation also promotes code reuse.
So, instead of having programmers constantly
write the same things over and over, they
can track down someone else’s code that
does what they need.
Then, thanks to documentation, they can put
it to work in their program, without ever
having to read through the code.
“Read the docs” as they say.
In addition to IDEs, another important piece
of software that helps big teams work collaboratively
on big coding projects is called Source Control, also known as version control or revision control.
Most often, at a big software company like
Apple or Microsoft, code for projects is stored
on centralized servers, called a code repository.
When a programmer wants to work on a piece
of code, they can check it out, sort of like
checking out a book out from a library.
Often, this can be done right in an IDE.
Then, they can edit this code all they want
on their personal computer, adding new features
and testing if they work.

Portuguese: 
Quando o programado está confiante de que suas modificações estão funcionando e não há pontas soltas, eles
podem colocar o código de volta no repositório, conhecido como "committing code", para todos os outros usá-lo.
Enquanto um pedaço do código é retirado, e presumivelmente atualizado ou modificado, outros
programadores não mexem nele.
Isso evita conflitos estranhos e trabalho duplicado.
Dessa forma, centenas de programadores podem estar simultaneamente retirando e colocando de volta pedaços
de código, de forma iterativa construindo grandes sistemas.
De forma nenhuma, você quer alguém enviando código com bugs, porque outras pessoas e equipes
podem estar contando com ele.
O código deles poderia falhar, criando confusão e perda de tempo.
A versão mestra do código, armazenada no servidor, deve sempre compilar sem
erros e executar com o mínimo de bugs.
Mas algumas vezes bugs persistem.
Felizmente, o software de controle do código fonte mantem um rastro de todas as mudanças, e se um bug for encontrado,
todo o código, ou apenas uma parte, pode ser restabelecida para uma versão anterior, umas versão estável.
Ele também rastreia quem fez essa mudança, então os colegas de trabalho podem enviar e-mails desagradáveis, digo, e-mails prestativos
e encorajadores para a pessoa ofendida.
O processo de debuggar anda de mãos dados com o processo de escrever o código, e na maioria das vezes é feito por um único indivíduo
ou uma equipe pequena.
O grande panorama do processo de debuggar é o teste de qualidade de qualidade [Quality Assurance testing], ou QA

Korean: 
프로그래머가 변경 사항을 확인하고, 
설명되지 않는 부분이 없다고 확신하면
코드를 커밋코드라고 하는 저장소로 다시 체크하여 
다른 모든 사람들이 사용할 수 있게 합니다.
코드를 커밋코드라고 하는 저장소로 다시 체크하여 
다른 모든 사람들이 사용할 수 있게 합니다.
한 조각의 코드가 확인되고,  업데이트되거나 수정 될 것으로 예상되는 동안 프로그래머는 그것을 내버려 둡니다.
한 조각의 코드가 확인되고,  업데이트되거나 수정 될 것으로 예상되는 동안 프로그래머는 그것을 내버려 둡니다.
이것은 이상한 갈등과 중복된 작업을 방지합니다.
이 방법으로 수백 명의 프로그래머가 
동시에 코드를 체크 인 및 체크 아웃을 할 수 있습니다.
반복적으로 거대한 시스템을 구축합니다.
비판적으로,  여러분은 다른 사람이 버그가 있는 코드를 작성하는것을 원치 않습니다.
다른 사람이나 팀이 그 정보에 의존할 수 있기 때문이죠.
그들의 코드가 충돌하여 혼란을 일으키고 
시간을 낭비할 수 있습니다.
서버에 저장된 코드의 마스터 버전은 항상 오류 없이 
컴파일하고 최소한의 버그로 실행해야 합니다.
서버에 저장된 코드의 마스터 버전은 항상 오류 없이 
컴파일하고 최소한의 버그로 실행해야 합니다.
하지만 때로는 버그가 슬며시 기어들어 옵니다.
다행히 소스 제어 소프트웨어는
모든 변경 사항을 추적하고, 만약 버그가 발견되면
전체 코드 또는 하나의 코드 조각을 초기의 또는 안정적인 버전으로 되돌릴 수 있습니다.
또한 각 변경 사항을 누가 작성했는지 추적하므로 
동료들이 불쾌감을 줄 수도 있습니다. 그럴 때는,
문제가 있는 사람에게 도움이 되거나 격려할 수 있는 이메일을 보낼 수도 있습니다.
디버깅은 코드 작성과 함께 진행되며,
개인이나 소규모 팀이 가장 자주 하는 일입니다.
디버깅은 코드 작성과 함께 진행되며,
개인이나 소규모 팀이 가장 자주 하는 일입니다.
디버깅의 큰 그림 버전은 품질 보증 테스트, 
또는 QA입니다.

Chinese: 
当开发者觉得代码能正确运行了，所有测试都通过了
他们可以将代码放回“代码仓库”
叫做“提交代码”（commit），以供其他人使用
当一段代码被 check out
并可能正在被优化或改动，
其他开发者就不会去动这一段代码
以此来预防代码冲突 以及重复劳动
这样，多名程序员可以同时编写代码
来建立庞大的系统
重要的是，你不希望有人提交错误的代码
因为其他人和团队可能依赖这些代码
导致他们的代码崩溃，造成混乱并浪费时间
存在服务器上的代码"主版本"
编译不应该出错，并且应该尽可能没有 bug
但有时 bug 会悄悄潜入
幸运的是，“源代码管理”软件可以跟踪所有的变化
如果发现 bug
全部或一部分代码
可以“回滚”到更早的稳定版本
"源代码管理" 也会记录是谁修改了哪些代码
所以同事可以给你发 讨厌的
我的意思是“有帮助的”
邮件告诉那个人
写代码和测代码密不可分
一般由个人或小团队完成
更全面的“调试”叫“质量保证测试”，简称“QA”

English: 
When the programmer is confident their changes
are working and there are no loose ends, they
can check the code back into the repository,
known as committing code, for everyone else
to use.
While a piece of code is checked out, and
presumably getting updated or modified, other
programmers leave it alone.
This prevents weird conflicts and duplicated
work.
In this way, hundreds of programmers can be
simultaneously checking in and out pieces
of code, iteratively building up huge systems.
Critically, you don’t want someone committing
buggy code, because other people and teams
may rely on it.
Their code could crash, creating confusion
and lost time.
The master version of the code, stored on
the server, should always compile without
errors and run with minimal bugs.
But sometimes bugs creep in.
Fortunately, source control software keeps
track of all changes, and if a bug is found,
the whole code, or just a piece, can be rolled
back to an earlier, stable version.
It also keeps track of who made each change,
so coworkers can send nasty, I mean, helpful
and encouraging emails to the offending person.
Debugging goes hand in hand with writing code,
and it’s most often done by an individual
or small team.
The big picture version of debugging is Quality
Assurance testing, or QA.

Portuguese: 
Isto é onde uma equipe testa rigorosamente uma parte do software, tentando criar
condições não esperadas que poderiam faze-lo travar.
basicamente, eles descobrem bugs.
Descobrir todas as nuâncias é um grande esforço mas vital para ter certeza que o software funciona
como o esperado para o maior número de usuários e situações que foram imaginadas antes de ele ser disponibilizado.
Você provavelmente ouviu sobre um software beta.
Esta é uma versão do software que está completa na sua maior parte,
mas não foi 100% testado.
Companhias algumas vezes lançam versões beta para o publico para ajuda-los a identificar problemas,
É essencialmente como ter um equipe QA de graça.
O que você não costuma ouvir muito a respeito é sobre a versão que vem antes da beta: a versão alfa.
Ela é normalmente tão grosseira e bugada, que é apenas testada internamente.
Então, isso é apenas a ponta do iceberg quando se trata de ferramentas, truques e técnicas que permitem
que os engenheiros de software construam as grandes partes de software que conhecemos e amamos hoje, como
YouTube, Grand Theft Auto 5 e Powerpoint.
Como você deve esperar, todos essas milhões de linhas de códigos precisam de um grande poder
de processamento para executar em velocidade suficiente, então no próximo episódio nós vamos falar sobre como os computadores ficaram tão incrivelmente rápidos.
Vejo vocês então.

Chinese: 
这个流程里会严格测试软件的各个方面
模拟各种可能的情况，看软件会不会崩溃
基本上就是找出 bug
去除大小错误需要花费巨大努力
但对确保软件的工作至关重要
让软件在各种情况下按预期运行。
你可能听过 "beta 版" 软件
意思是软件接近完成
但不是 100％ 完全测试过
公司有时会向公众发布 beta 版，以帮助发现问题
用户就像免费的 QA 团队
你听过比较少的是
beta 版之前的版本：alpha 版本
alpha 版一般非常粗糙和充满错误，所以只在公司内部测试
以上只是软件工程师用的工具和技巧的冰山一角
它们帮助软件工程师制作我们喜爱的大量软件
如 YouTube，GTA5 和 PPT 等等
正如你所料
这些代码需要强大的处理能力才能以有用的速度运行
所以下一集我们将讨论，计算机是怎么演变成如今这么快的
回头见

Korean: 
이곳은 팀이 엄격하게 소프트웨어를 테스트하는 곳입니다.
실수를 불러일으킬 수 도 있는, 예기치 않은 상황을 만들어내어 소프트웨어를 작동시킬 수 있습니다.
기본적으로 이들은 버그를 이끌어냅니다.
모든 주름을 제거하는 것은 엄청난 노력이지만, 소프트웨어가 출하되기 전에 상상할 수 있는 많은 상황에서
여러 사용자들을 대상으로 소프트웨어가 작동하는 지 
확인하는 데 중요합니다.
베타 소프트웨어에 대해 들어 보셨을 것입니다. 이것은 대부분 완성 된 소프트웨어 버전입니다.
하지만 100 % 완벽하게 테스트 한 것은 아닙니다.
회사는 종종 문제를 식별할 수 있도록 
베타 버전을 공개합니다.
그것은 기본적으로 무료 품질 보증을 받는것과 같습니다.
베타 이전의 버전인 알파버전은 베타 버전 만큼은 많이 들어보진 못했을 것 입니다.
이것은 일반적으로 매우 거칠고 버그가 있으며,
 내부적으로만 테스트됩니다.
그래서, 그것은 도구, 트릭 및 기술에 관한 용어로썬 
빙산의 일각입니다.
오늘날 우리가 알고 있고 사랑하는 유튜브, Grand Theft Auto 5, 파워포인처럼 거대한 소프트웨어의 구성에서요.
오늘날 우리가 알고 있고 사랑하는 유튜브, Grand Theft Auto 5, 파워포인처럼 거대한 소프트웨어의 구성에서요.
예상대로, 수백만 줄의 코드는 유용한 속도로 실행되기 
위해 만만치 않은 처리 능력이 필요합니다.
그래서 다음 강의에서 우리는 컴퓨터가 어떻게 그렇게 놀랍도록 빨라 졌는지 에 대해 이야기할 것입니다.
그때 만나요~

English: 
This is where a team rigorously tests out
a piece of software, attempting to create
unforeseen conditions that might trip it up.
Basically, they elicit bugs.
Getting all the wrinkles out is a huge effort,
but vital in making sure the software works
as intended for as many users in as many situations
as imaginable before it ships.
You’ve probably heard of beta software This
is a version of software that’s mostly complete,
but not 100% fully tested.
Companies will sometimes release beta versions
to the public to help them identify issues,
it’s essentially like getting a free QA
team.
What you don’t hear about as much is the version that comes before the beta: the alpha version.
This is usually so rough and buggy, it’s
only tested internally.
So, that’s the tip of the iceberg in terms
of the tools, tricks and techniques that allow
software engineers to construct the huge pieces
of software that we know and love today, like
YouTube, Grand Theft Auto 5, and Powerpoint.
As you might expect, all those millions of
lines of code needs some serious processing
power to run at useful speeds, so next episode we’ll be talking about how computers got so incredibly fast.
See you then.
