Software Engineering: Crash Course Computer Science #16

Summary

在这个视频脚本中，Carrie Anne带领观众深入了解了计算机科学中的软件工程概念。她首先指出，尽管排序算法可能只有几行代码，但大型程序如微软Office却包含约4000万行代码，这需要一套工具和实践来构建。软件工程这个术语由工程师Margaret Hamilton创造，她帮助NASA在阿波罗登月任务中预防了严重问题。视频强调了将大型程序分解为更小的函数，允许多人同时工作的重要性，并介绍了对象导向编程（OOP）的概念，即将相关函数打包成对象，形成层次结构。Carrie Anne解释了如何通过对象层次结构导航以执行特定功能，以及如何使用公有和私有函数来隐藏复杂性并选择性地揭示它。此外，视频还讨论了集成开发环境（IDE）的重要性，它们为编写、组织、编译和测试代码提供了有用的工具。最后，脚本提到了代码文档、源代码控制和质量保证测试的重要性，这些都是构建大型软件项目的关键组成部分。

Takeaways

• 📚 软件工程是构建大型程序的学科，由工程师玛格丽特·汉密尔顿命名，她帮助NASA在阿波罗登月任务中预防了严重问题。
• 🔍 将大型程序分解为更小的函数允许多人同时工作，而不必关心整个程序，只需关注他们正在工作的函数。
• 🧩 通过将函数打包成层次结构，并将相关的代码聚集到“对象”中，可以更有效地管理大量函数。
• 🚗 面向对象编程（OOP）通过将功能单元打包到嵌套的对象中来隐藏复杂性，并通过封装来简化软件构建。
• 🔑 应用程序编程接口（API）允许程序员在代码的不同部分之间进行协作，定义了不同团队编写的代码如何交互。
• 🔒 在OOP语言中，可以通过将函数指定为“公共”或“私有”来控制函数的访问权限，以此来隐藏复杂性和选择性地揭示它。
• 🛠️ 集成开发环境（IDE）为程序员提供了编写、组织、编译和测试代码的多种有用工具。
• 🔍 调试是编程中的重要部分，大多数程序员花费70%到80%的时间在测试和调试上，而不是编写新代码。
• ✍️ 文档化对于帮助程序员理解他们一段时间没有看过的代码至关重要，也促进了代码的重用。
• 🔄 源代码控制（版本控制或修订控制）是大型团队协作开发大型编程项目的重要软件，允许程序员在中央服务器上存储和管理项目代码。
• 🔍 质量保证（QA）测试是团队对软件进行严格测试的过程，目的是发现可能导致软件出错的未预见条件。
• 📈 构建像YouTube、《侠盗猎车手5》和PowerPoint这样的大型软件需要强大的处理能力，以确保代码能够以有用的速度运行。

Q & A

为什么单个程序员编写排序算法可能不需要特殊工具？

单个程序员编写排序算法通常只需要十行左右的代码，这样的代码长度足够短，使得程序员可以直接使用简单的文本编辑器如Notepad来编写，而不需要复杂的开发工具。

软件工程这个术语是由谁提出的？

软件工程这个术语是由工程师玛格丽特·汉密尔顿提出的，她帮助NASA在阿波罗登月任务中预防了严重的软件问题。

将大型程序分解为更小的函数有什么好处？

将大型程序分解为更小的函数可以让多个人同时工作，他们不需要担心整个程序，只需要关注他们正在工作的那部分函数，这样可以提高开发效率和可管理性。

对象（Object）在面向对象编程中是如何帮助组织代码的？

在面向对象编程中，对象可以将相关的函数和变量打包在一起，形成层次结构。这样，程序员可以通过导航对象层次结构来触发特定的功能，从而更好地管理和调用代码。

什么是API，它在编程中扮演什么角色？

API（应用程序编程接口）是一组预定义的函数，它允许不同的代码部分相互交互。API定义了哪些函数是公共的（可以被外部对象调用），哪些是私有的（只能在定义它的对象内部调用），有助于维护代码的封装性和安全性。

为什么几乎所有的软件和游戏都是用面向对象编程语言编写的？

面向对象编程语言提供了强大的工具来隐藏复杂性，并通过封装、继承和多态性等特性来构建大型和复杂的程序。这些语言的普及和强大功能使得它们成为构建现代软件和游戏的首选。

代码在被编译之前是什么形式？

代码在被编译之前只是文本。程序员可以使用任何文本编辑器，如记事本，来编写代码。

集成开发环境（IDE）是什么，它为程序员提供了哪些功能？

集成开发环境（IDE）是一种特殊用途的应用程序，它集成了多种有用的工具，用于编写、组织、编译和测试代码。IDE提供了文本编辑器、代码颜色编码、语法错误检查、代码导航、编译运行功能以及调试支持。

为什么代码文档化对于程序员很重要？

代码文档化有助于程序员在一段时间后重新访问代码时理解代码的功能，对于新接触代码的程序员也至关重要。良好的文档化促进了代码的重用，使得程序员可以快速理解并应用他人编写的代码。

源代码控制（Source Control）在团队协作中有什么作用？

源代码控制允许大型团队在大型编码项目上进行协作。它通过版本控制或修订控制，使得程序员可以检查代码、进行修改，并在准备好后将代码提交回代码库，从而避免代码冲突和重复工作。

软件发布前的质量保证（QA）测试是什么？

质量保证（QA）测试是由一个团队进行的，他们对软件进行严格的测试，尝试创建未预见的条件以发现软件中的错误。这是确保软件在尽可能多的用户和场景中按预期工作的重要步骤。

什么是beta软件和alpha版本？

Beta软件是几乎完成但尚未完全测试的软件版本，公司有时会将其发布给公众以帮助识别问题。Alpha版本是软件的早期阶段，通常存在较多问题，只限于内部测试。

Outlines

00:00

🎓 软件工程与面向对象编程

Carrie Anne 在视频中介绍了软件工程的概念，强调了它在构建大型程序中的重要性。她提到了软件工程这个术语是由帮助NASA避免阿波罗登月任务中严重问题的工程师Margaret Hamilton提出的。视频讲解了如何将大型程序分解为更小的函数，以便多人同时工作，并且每个程序员只需要关注他们正在工作的那部分。此外，还介绍了对象导向编程（Object Oriented Programming, OOP），这是一种将功能单元打包到嵌套对象中的思想，类似于之前在电子电路中将晶体管电路打包成更高级别的布尔门。Carrie Anne 通过汽车的软件来说明如何将相关的函数打包成对象，并创建对象之间的层次结构。她还讨论了公共（public）和私有（private）函数的概念，以及它们如何帮助隐藏复杂性并选择性地揭示它。

05:03

🛠️ 集成开发环境与源代码控制

在第二段中，Carrie Anne 讨论了现代软件开发中使用的工具，特别是集成开发环境（IDEs）。她解释了IDEs如何提供文本编辑器、代码颜色编码、语法错误检查、代码组织和导航、编译和运行代码的能力，以及调试支持。她还强调了文档在软件开发中的重要性，包括使用注释和独立文档来帮助其他程序员理解代码。此外，视频还介绍了源代码控制的概念，包括代码仓库、检出和提交代码的过程，以及如何通过版本控制来避免代码冲突和重复工作。最后，她提到了软件测试的重要性，包括个人或小团队进行的调试和更大的质量保证（QA）测试，以及软件发布前的alpha和beta版本。

Keywords

💡排序算法

排序算法是一种计算机程序用来对数据项进行排序的算法。在视频中，它被用来说明即使是简单的任务，如排序，也是大型软件工程的一部分。排序算法在视频中被提及，以展示即使是小的编程任务，也可能是更大型程序的组成部分。

💡软件工程

软件工程是一门学科，它涉及使用系统化的方法来开发和维护软件。视频中提到，软件工程包括一系列工具和实践，帮助程序员构建像微软Office这样拥有4000万行代码的庞大程序。

💡面向对象编程

面向对象编程（OOP）是一种程序设计范式，它使用“对象”来表示数据和方法。在视频中，OOP被用来解释如何通过将功能单元打包成嵌套对象来隐藏复杂性，并通过封装低级细节来提高抽象层次。

💡集成开发环境（IDE）

集成开发环境（IDE）是一种软件应用程序，它为编写、组织、编译和测试代码提供了多种有用的工具。视频中提到，IDE提供了文本编辑器、语法检查、代码导航和调试等功能，帮助程序员更高效地工作。

💡API（应用程序编程接口）

API是一组预定义的函数，它允许不同的软件组件相互通信。视频中解释了API的重要性，它允许程序员在不同代码部分之间进行交互，同时控制对特定功能的访问。

💡版本控制

版本控制是一种软件工具，它帮助程序员管理和跟踪代码的变更历史。在视频中，版本控制允许多个程序员同时在大型项目上工作，而不会相互干扰，并且可以在发现错误时回滚到之前的稳定版本。

💡调试

调试是软件开发过程中识别和修复错误的过程。视频中提到，大多数程序员花费70%到80%的时间在测试和调试上，而不是编写新代码，这强调了调试在软件开发中的重要性。

💡文档

文档是编写代码时的重要部分，它帮助其他程序员理解代码的功能和用途。视频中强调了良好文档的重要性，它不仅帮助程序员在回顾旧代码时更快地理解，还促进了代码的重用。

💡函数

函数是一段执行特定任务的代码块，它可以被重复调用以完成相同的任务。视频中提到，将代码打包成函数是简化大型程序管理的一种方法，每个函数负责一个特定的子任务。

💡对象

对象是面向对象编程中的一个基本概念，它包含数据和可以操作这些数据的方法。视频中通过汽车软件的例子解释了对象的概念，如将与巡航控制相关的所有功能打包成一个对象。

💡编译

编译是将源代码转换成机器可执行代码的过程。视频中提到，尽管在编写时代码只是文本，但为了运行程序，必须通过编译器将其编译成机器代码。

Highlights

讨论了排序算法在大型程序中的使用，以及如何通过软件工程的方法来构建和管理大型程序。

提到了微软Office拥有约4000万行代码，展示了大型程序的复杂性。

软件工程是由工程师Margaret Hamilton提出的，她帮助NASA在阿波罗登月任务中预防了严重问题。

将大型程序分解为更小的函数，允许多人同时工作，而不必关注整个程序。

介绍了面向对象编程（OOP），这是一种通过将功能单元打包成嵌套对象的方法来隐藏复杂性的方法。

解释了如何通过对象层次结构来组织代码，例如汽车软件中的巡航控制和引擎控制。

讨论了API（应用程序编程接口）的重要性，它是不同代码部分之间协作程序员交互的方式。

强调了代码文档的重要性，它有助于其他程序员理解和重用代码。

介绍了集成开发环境（IDE）的概念，它们提供了编写、组织、编译和测试代码的多种工具。

讨论了源代码控制（版本控制或修订控制）在大型团队协作中的作用。

解释了如何通过源代码控制软件跟踪所有更改，并在发现错误时回滚到早期稳定版本。

质量保证（QA）测试是软件发布前的重要环节，它通过模拟各种条件来发现和修复软件中的错误。

讨论了软件发布过程中的alpha和beta版本，以及它们在测试和发现问题中的作用。

强调了软件工程中使用的工具、技巧和技术对于构建我们今天所熟知的大型软件的重要性。

预告了下一集将要讨论的主题：计算机如何变得如此之快。

Transcripts

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.”

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.

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.

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.

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

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.

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.

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.

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.

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.