큰 프로그램을 작은 함수들로 쪼개면 사람들은 동시에 일할 수 있다.
전체에 대해 신경 쓰지 않고 개인이 작업하고 있는 함수에만 집중한다.
하지만 코드를 함수로 묶는 것만으로는 충분하지 않다.
Microsoft처럼 수십만개의 함수를 가지고 있다면 여전히 한 사람, 한 팀이 관리하기에는 너무 많다.
=> 함수를 Hierarchy로 패키지화하여 관련된 코드를 객체로 모으자!

객체 지향 프로그래밍(Object Oriented Programming)

ex. 자동차의 소프트웨어에 cruise control과 관련된 여러 기능이 있다고 하자.

Object CruiseControl
   Function setCruiseSpeed(value) //👈🏻
   Function nudgeSpeedUp()
   Function nudgeSpeedDown()
   Function stopCruiseControl()
End Object

CruiseControl이라는 객체로 크루즈 컨트롤 관련 기능 함수들을 한 데 모아 묶을 수 있다.

크루즈 컨트롤 역시 엔진 소프트웨어의 한 부분일 뿐이다.

Object Engine
     Object CruiseControl //👈🏻
     Object IgnitionControl
     Object FuelPump
     Object Radiator
     ...
End Object

부모 Engine 객체를 만들어 자식 객체를 포함시킬 수 있다.

일반적으로 객체는 다른 객체와 함수 및 변수를 포함할 수 있다.

Object Engine
     Object CruiseControl
     Object IgnitionControl
     Object FuelPump
     Object Radiator
     ...
     Function startEngine()
     Function stopEngine()
     Function checkOilLevel()
     ...
     Variable odometer
     Variable engineTemp
     ...
End Object

변속기, 바퀴, 문, 창문 등도 자동차의 일부분이다.

Object Car
      Object Engine //👈🏻
      Object Transmission
      Object Wheels
      Object Doors
      Object Windows
      Object FuelTank
      ...
      Variable vinNumber
      Variable yearBuilt
      ...
End Object

이제 크루즈 컨트롤을 설정하고 싶다면 가장 바깥쪽 객체에서 더 깊숙히 중첩된 객체 계층까지 탐색한다.

Car.Engine.CruiseControl.setCruiseSpeed(55)

이처럼 기능 단위를 중첩된 객체로 묶는 것을 객체 지향 프로그래밍(Object Oriented Programming)이라 한다.
고차원 구성 요소에 하위 수준의 세부 정보를 캡슐화하여 복잡성을 숨긴다.

이처럼 큰 프로그램을 기능 단위로 분해하면 팀으로 작업하기에 좋다.
각 팀은 서로 다른 파트에서 각자의 기술을 활용하여 동시에 작업한다.

위의 예제에서 크루즈 컨트롤 팀이 있고, '자동차를 일정 속도로 유지하는 것'은 크루즈 컨트롤 팀이 아닌 다른 팀에서 작성된 코드라고 해보자.
크루즈 컨트롤 팀은 다른 팀에서 작성된 코드 내에서 각 코드의 기능이 무엇인지 알기 위해, API(응용 프로그램 인터페이스)를 필요로할 것이다.
API는 프로그래머가 코드의 다양한 부분에서 공동 작업하는 방식이라고 할 수 있다.

API를 사용하면 함수와 데이터에 대한 적절한 접근 권한을 얻을 수 있다.
예를 들어 IgnitionControl이라는 객체가 있다고 해보자.
객체지향 프로그래밍 언어는 함수의 공개/비공개 여부를 지정할 수 있게 한다.

Object IgnitionControl
  Public Function setRPM(value)
  Public Function getSparkVoltage()
  Private Function fireSparkPlug1()
  Private Function fireSparkPlug2()
  Private Function fireSparkPlug3()
  Private Function fireSparkPlug4()
  ...
End Object

함수가 Private(비공개)으로 지정된 경우 IgnitionControl 객체 내부의 함수(예컨대 setRPM(value))만 Private함수를 호출할 수 있다.
한편, setRPM함수는 Public(공개)으로 표시되어있기 때문에
크루즈 컨트롤 팀이 CruiseControl과 같은 다른 객체에서 setRPM함수를 호출할 수 있게 된다.

Object Engine
      Object CruiseControl // 여기서
      Object IgnitionControl  // 이 객체 내부의 함수(setRPM(value))를 호출
      Object FuelPump
      Object Radiator
      ...
End Object

이처럼 복잡성을 숨기고 선택적으로 드러내는 능력은 객체지향 프로그래밍의 본질이다. 이는 크고 복잡한 프로그램을 만드는 강력하고 대중적인 방법이다.

컴퓨터나 콘솔에서 실행되는 게임의 거의 모든 부분은 객체지향 프로그래밍 언어인 C++, C#, 또는 Objective-C와 같은 것들을 사용하여 작성되었다.
그 외에 객체지향 프로그래밍 언어로는 Python과 Java도 있다.

IDE(Integrated Development Environment)

요즘 소프트웨어 개발자들은 코드를 쓰고, 조직하고, 편집하고, 테스트할 수 있는 많은 유용한 도구들을 통합한 특수 목적 응용 프로그램을 사용한다. 프로그래머들이 필요로 하는 모든 것을 하나에 넣기 때문에 통합 개발환경 (IDE : integrated development environment)라고 불리기도 한다.

모든 IDE는 작문을 위한 텍스트 편집기, 가독성을 향상시키는 자동 컬러 코딩과 같이 종종 유용한 기능을 포함한다. 코드의 맞춤법 검사와 같이, 입력하는 동안 구문 오류가 있는지도 확인할 수 있다.
또한 IDE에 내장된 기능은 코드를 컴파일하고 실행한다. 만약 프로그램이 crash되면, IDE는 crash되기 전의 코드로 되돌릴 수 있으며, 디버깅에 도움이되는 추가 정보도 제공한다. 대부분의 프로그래머는 새로운 코드를 쓰기 보다는 70~80%의 시간을 테스트와 디버깅에 쓰기 때문에 이러한 기능은 매우 중요하다.

코드의 문서화(Documenting)

코드 문서화는 read-me라고 부르는 독립 실행형 파일에서 수행할 수 있다.
다른 프로그래머에게 실행하기 전에 도움말 파일을 읽도록 지시한다.

주석을 사용하여 코드 자체에서 도움말을 쓸 수도 있다.
/**/를 사용하여 소스 코드에서 뭐가 뭔지 알아낼 수 있도록 도움을 준다.

/* This function sets the speed of the engine in revolutions
per minute (RPM). A single integer value is passed in,
which must be a number between 1000 ans 6000. 
Any value outside of this range will be considered an error and ignored. 
No value is returned. */
Public Function setRPM(value)

제대로 된 documentation은 본 지 오래된 코드를 다시 볼 때에도 도움이 되지만, 해당 코드를 생전 처음 보는 프로그래머에게도 중요하다.

주석도 없고 문서화되지도 않은 코드는 최악이다!
코드가 무슨 뜻인지 한 줄 한 줄 뜯어봐야하기 때문이다.

documentation은 코드 재사용을 촉진하기도 한다.
코드를 매번 작성하는 대신, 설명서를 읽고 다른 사람의 코드를 가져와서 해야할 일을 할 수도 있다.

source control( 또는 version control)

Apple 또는 Microsoft와 같이 큰 소프트웨어 회사에서 프로젝트를 위한 코드는 중앙 집중화된 서버(repository)에 저장된다.
프로그래머가 코드 부분 작업을 할 때 코드의 내용을 확인할 수 있다.
IDE에서 원하는 코드 수정, 새로운 기능 추가, 작동 여부 테스트를 할 수 있다. 코드의 일부가 업데이트되는 동안 다른 프로그래머들은 이를 가만히 둬야 한다(conflict과 중복된 작업 방지).
최종적으로 변경 사항을 확인하고 설명되지 않는 부분이 없다고 확신한다면 committing code라는 저장소에 올려놓아 다른 사람들이 사용할 수 있도록 한다.
이러한 방법으로 수백명의 프로그래머가 동시에 코드 check in, check out을 할 수 있다.

서버에 저장된 코드의 마스터 버전은 항상 오류 없이 컴파일하고 최소한의 버그로 실행해야 한다.
다행히도 소스 제어 소프트웨어는 모든 변경 사항을 추적하고, 만약 버그가 발견되면 코드를 초기 또는 안정적인 버전으로 되돌릴 수 있다(rolled back).

QA(Quality assurance test)

디버깅은 소규모로 진행되지만, big picture 버전은 품질 보증 테스트, 또는 QA(Quality assurance test)이다.
이 곳은 팀이 엄격하게 소프트웨어를 테스트하는 곳이다.
예기치 못한 상황을 만들어내어 소프트웨어를 작동시켜볼 수 있다.
소프트웨어가 출하되기 전에 상상할 수 있는 많은 상황 속에서 많은 유저들을 대상으로 소프트웨어가 작동하는지 확인해보아야 한다.

알파 버전 : 러프하고 버그가 있으며 내부적으로만 테스트되는 버전
베타 버전 : 100%는 아니지만 대부분 완성된 소프트웨어 버전
기업들은 종종 문제가 있는지 식별하기 위해 베타 버전을 공개한다.
무료 품질 보증을 받는 것과 같다!