4장 - 구현 시 결정해야 할 핵심 사항

Edited by / (frog-slayer)

4.1. Choice of Programming Language

프로그래밍 언어를 선택하는 것도 생산성과 코드 퀄리티에 영향을 준다.

• 익숙한 언어를 쓰는 것이 생산성 향상에 도움이 된다.
• 고수준 언어를 쓰는 프로그래머가 저수준 언어를 쓰는 프로그래머보다 높은 생산성, 코드 퀄리티를 보인다.
  • 고수준 언어는 저수준 언어보다 표현력이 좋다. 짧은 라인으로 더 많은 작업을 할 수 있다.
  • 아래의 표는 C언어 대비, 같은 줄 수의 코드로 얼마나 많이 표현할 수 있는지를 나타낸다.
• 어떤 언어는 다른 언어들보다 프로그래밍 개념을 더 잘 표현하기도 한다.
• 프로그래머도 자신이 쓰는 프로그래밍 언어에 영향을 받곤 한다.

Language Descriptions

• Ada: Pascal 기반 범용 고수준 프로그래밍 언어.
  • 군사, 우주, 항공 시스템 등, 실시간 임베디드 시스템에서 사용.
  • 데이터 추상화 및 정보 은닉을 강조하고, 각 클래스 및 패키지를 public과 private으로 구분.
• Assembly Language: 각 문장(statement)이 하나의 기계어와 대응하는 저수준 언어.
  • 각 문장이 기계어와 대응하므로, 사용하는 프로세서의 종류에 따라 달라짐.
  • 실행 시간이나 코드 사이즈를 극한으로 줄여야하는 경우가 아니라면 직접 사용하는 경우는 거의 없음.
• C: 범용 중간수준 언어.
  • UNIX OS
  • 고수준 언어의 특징도 가지고 있지만, 포인터와 주소를 직접 다룰 수 있는 등 저수준 언어의 특징도 가지고 있음.
• C++: C 기반 객체 지향 언어.
  • C와 호환 가능하면서, 클래스, 다형성, 예외 처리, 템플릿 등의 기능을 제공.
  • 다양하고 강력한 표준 라이브러리를 제공.
• C#: 마이크로소프트에서 개발한 범용 객체 지향 언어이자, 프로그래밍 환경.
  • C, C++, Java와 유사한 문법을 가지고 있음.
  • 마이크로소프트 플랫폼에서의 개발에 유용한 다양한 도구들을 제공
• Cobol: 영어와 유사한 프로그래밍 언어로 사무용 애플리케이션에서 사용하기 위해 설계됨.
  • 수학 함수 및 객체 지향 기능이 업데이트 됨.
• Fortran: 함수, 고수준 루프 개념을 도입한 첫 번째 고수준 컴퓨터 언어.
  • 1950년대에 처음 개발되어 여러 버전을 거쳐 발전했음.
• Java: C, C++과 비슷한 문법을 가지고 있는 객체 지향 언어
  • Java 소스 코드를 각 플랫폼의 가상 머신에서 돌아가는 byte code로 변환해 실행.
  • 웹 애플리케이션 프로래밍에서 많이 사용.
• JavaScript: 인터프리터 스크립트 언어.
  • 주로 웹 페이지에 간단한 함수를 추가하거나 온라인 애플리케이션의 클라이언트 쪽을 만들 때 사용.
• Perl: C와 UNIX의 기능들을 이용한 문자열 처리 언어.
  • 시스템 관리 업무에서 주로 사용하며, 웹 애플리케이션 개발에서 사용하기도 함.
• PHP: 간단한 문법을 사용하는 오픈 소스 스크립트 언어.
  • 많은 웹 사이트들에서 사용함.
• Python: 객체 지향 인터프리터 언어.
  • 스크립트 작성 및 작은 웹 애플리케이션에서 주로 사용하지만, 큰 프로그램을 만들 때에도 쓰임.
• SQL: RDB 쿼리, 업데이트, 관리를 위한 표준 언어
• Visual Basic: 1960년대 만들어진 고수준 언어인 Basic을 Windows 애플리케이션을 만들기 위해 개량한 언어. 고수준, 객체 지향, 비주얼 프로그래밍 버전.

4.2. Programming Conventions

고품질 소프트웨어에서는 아키텍처의 개념적 무결성과 그 저수준 구현 사이의 관계를 확인할 수 있다. 구현은 아키텍처와의 일관성을 유지해야하고, 내부적으로도 일관성이 있어야 한다. 변수명, 클래스명, 함수명 등의 프로그래밍 컨벤션은 이러한 일관성을 제공하는 가이드라인이다.

각 세부 부분은 아키텍처가 가지고 있는 함의를 잘 보여주는 것이 좋다. 만약 가이드라인이 없으면, 프로그램이 복잡해질수록 여러 스타일의 코드들이 뒤섞여 버리게 될 것이고, 서로 다른 스타일이 섞여 있는 코드를 읽는 일은 불필요한 부담이 된다.

나중에 컨벤션 및 규칙을 바꾸는 일은 거의 불가능하므로, 구현에 들어가기 전에 컨벤션과 규칙을 제대로 정해놓아야 한다.

4.3. Your Location on the Technology Wave

기술 흐름의 어디에 위치해 있는지에 따라 프로그래밍 실천 규칙은 달라진다. 웹 프로그래밍을 예로 생각해보자.

2000년대 중반의 충분히 성숙한 웹 프로그래밍 기술 환경에는 프로그래밍 언어도 다양하게 선택할 수 있고, 좋은 디버깅 툴들도 있고, 성능 최적화도 자동으로 할 수 있다. 컨파일러에는 버그가 거의 없고, 도구들에 대한 문서화도 잘 되어 있다. 문제가 발생했을 때에도 그에 대한 질의응답을 쉽게 찾을 수 있다.

1990년대 중반의 초기 기술 환경에서는 정반대다. 언어에는 선택지도 많지 않고, 버그도 많고, 문서화도 잘 되어 있지 않았다. 프로그래머들은 코드로 자기가 생각하는 것을 표현하기 보다, 그 언어가 어떻게 동작하는지 이해하기 위해 더 많은 시간을 쏟아야 했다. 성숙한 기술 환경에서 주어지는 여러 도구들도 존재하지 않기 때문에, 프로그래머들은 그런 도구나 라이브러리도 직접 개발해야 했다. 문제가 발생하는 경우, 웹에서 레퍼런스 문서를 찾을 수는 있었지만 믿을 만한 것은 아니었다.

중요한 것은, 자신이 기술 흐름의 어디에 위치해 있는지를 파악하는 것이다. 만약 자신이 흐름의 끝자락에, 즉 충분히 성숙한 기술 환경에 위치해있다면, 새로운 기능을 개발하기 위해 많은 시간을 쏟을 것이다. 반대의 경우에는 프로그래밍 언어에 있는, 문서화 되지 않은 특징들을 파악하거나, 라이브러리 코드에 있는 결함들을 디버깅하는 등의 활동들에 시간을 쏟게 될 것이다.

• Programming “in” a language
  • 사용하는 “언어”를 바탕으로 생각하는 것.
• Programming “into” a language
  • “자신이 생각하는 것”을 프로그래밍 언어로 표현하는 것
  • 프로그래밍 원칙들의 대부분은 특정 언어에만 국한된 것이 아니고, 그것을 어떻게 사용하는지에 대한 것.
  • 원하는 기능이 언어에 없다면, 스스로의 코딩 컨벤션, 표준, 클래스 라이브러리 등을 만들면서, 어떻게 이를 보충하고 개선할지 생각해보자.

4.4. Selection of Major Construction Practices

소프트웨어 구현 준비를 위한 단계에서 할 일 중 하나는, 여러 좋은 실천 규칙들 중 어느 것을 강조할지를 정하는 일이다. 예를 들어 페어 프로그래밍을 할지, 혼자서 개발을 할지, 혹은 이를 조합할지 등을 정하는 것이다.

아래는 어떤 실천 규칙을 정할 것인지에 도움이 될 체크리스트다. 자세한 실천 규칙은 나중에 다루게 될 것.