Software Engineering: Crash Course Computer Science #16

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.

100 thoughts on “Software Engineering: Crash Course Computer Science #16

  1. Why aqubytebazzar is best?
     Selected and best products among all websites.
     Ranking products.
     Get additional discounted for every shopping.
     We serve smart and hygienic products.
     We care and need about the dear customers.
     24X7 hours Supports.

  2. you are talking about software engineering like it is just developing code -.-' you totally ignored the designe and analyze of the requirements

  3. Can my head explode now?.. My neurons are not firing fast enough to comprehend all these data. This is too much objects and fuctions for my functionless brain.. Good God, I will leave it for the savants aka Nerdist

  4. An awesome video. It explains the concept of OOPs very well. It helps a lot for beginners in OOPs. CC you have done very well just keep it up.

  5. In a large company, even when split into smaller teams, you can seldom assume that only you are editing a certain file. Merge conflicts are a commen and natural occurence.

  6. "Huge pieces of software, that we know and love today… Powerpoint."
    In my best and loudest Dwight voice…. "FALSE!"

    LOVING this series XD

  7. This video should be called object-oriented software design… there are many valid (and better) approaches to software engineering!

  8. Nobody writes a sort, they use a function to sort that has already made. I have made most of my own tools for 40 years and wrote my sort routine by using heap sort defined by Knuth’s books in 1979.

    You don’t actually seem to have an real experience writing software. Why do you think you should be teaching others?

  9. I'm Turkish But not best speak and write English. Very very bad status. Can yours help me ? I like science computer. Please Help Me ! I like learnig English and I Like computer.

  10. I enjoyed the programming humour in this episode. 🙂

    Carrie Anne making it clear she's a vim advocate, and makes a fair point that it's not bad as long as you know how to quit, hehe…

  11. It is insane that the comments have not gone into uber flame wars over editors. Also, VIM, really. Just use VI. Real programmers use butterflies. EMACs has a command for that.

  12. "For God so loved the world, that he gave his only begotten Son, that whosoever believeth in him should not perish, but have everlasting life." John 3:16

    Only Jesus Christ is the way to Heaven and be saved from hell.

    "But God commendeth his love toward us, in that, while we were yet sinners, Christ died for us."

    Romans 5:8

    "Jesus saith unto him, I am the way, the truth, and the life: no man cometh unto the Father, but by me." John 14:6

    Have you believed in your heart that Jesus Christ died on the cross for your sins, was buried, and rose from the grave? You must believe that Jesus is the one who paid for your sins and rose again to be saved from eternal damnation and instead go to heaven

    "That if thou shalt confess with thy mouth the Lord Jesus, and shalt believe in thine heart that God hath raised him from the dead, thou shalt be saved." Romans 10:9

    "For there are three that bear record in heaven, the Father, the Word, and the Holy Ghost: and these three are one." 1 John 5:7

  13. Notepad is fine but NO you do not want to use a word processor to write code. Formatting codes most of which are hidden would mess up the ability to Compile the code.

  14. Too bad this did not exist when I started my study. Would have helped me so much to understand basic principles.

  15. 6:12
    Yes! Anyone new to programming should know that having lots of bugs to fix doesn't mean you're not learning anything, and in fact, helps a lot with the learning experience.

  16. I learnt so much in about 10 minutes. these series is recommendable to people who is new to cs

  17. Just realized this should become "Crash Course Computer Engineering", or, "Crash Course Computer Programming", because most of this isn't actually computer science. I've only seen three episodes so far that actually were computer science.

  18. Awesome its indeed a very good Software Engineering Crash Course, really good and easy to understand by us beginners, and it really helped me to learn a lot about software engineering, here I would also like to add that I regularly follow official blogs of worlds best software development firms like DCS, GoodCore Software and others because such official blogs are very latest and really insightful according to current ongoing software Industry developments, and do really help me to maintain an edge and standout.

  19. This series is really interesting for a total noob like me 😀 Being a little bit into audio and music production, I can't help but notice that computing processes in general are very similar to inventing, producing, mixing and mastering music. All the charts and wiring diagrams remind me very much of a mix template in a DAW, parallel and serial processes feeding into each other and adding up at busses. It's exactly the same: Trying to manage countless layers of abstraction, from a single audio sample to hundreds of tracks coming together at the final stage… That's really encouraging for me to get into it, should've been smart enough to realize that years ago 8)

Leave a Reply

Your email address will not be published. Required fields are marked *